技术Leader一定要懂所有业务细节吗？

点击蓝色“陈树义”关注我哟

前几天在脉脉职言看到这样一个提问：带团队的人，你们是怎么了解业务细节的？如果不了解，怎么懂的比实际干活的多的？

从技术管理的角度来看，这个问题可以很典型地反映出研发岗与技术管理岗的差异。今天我们就来聊一聊这个事情。

技术管理的思维

从提问者的文字描述来看，我们大致可以推断出他的想法：Leader 肯定要比员工懂得更多的技术细节，不然怎么做 Leader 呢！站在技术 Leader 的角度，这句话其实对错分半。对的地方在于技术 Leader 确实懂的比员工多，但不是细节，而是全局。错的地方在于技术 Leader 并不需要懂所有细节。

当你从一个员工变成了 Leader 的时候，你的职责不再是做完这个需求就完事，而是对这个团队的产出负责。这个时候你个人是否实际去做事，是否了解具体的细节，其实变得不再重要了。你关注的重点应该是整个团队，你应该去做哪些对整个团队有益的事情。

之前你能很好地完成一个需求，并且能非常出色地完成。但即使你再怎么努力，你最多也就影响这一个需求而已。但如果你是一个团队的 Leader，那么你做的事情就可以影响整个团队，此时你的产出就是这件事乘以所有人。从这个角度来说，你此时考虑的应该是整个团队，而不是具体某个需求。

关注团队的整体产出，而不是自己具体做了多少需求，是成为技术管理者的思维转变第一步。

现实情况不允许

为什么说技术 Leader 不需要懂所有业务细节？

这是因为现实情况不允许！因为这是一个不可能完成的任务！

当团队只有两三个人的时候，技术 Leader 确实是可以亲力亲为，什么事情都自己干，任何一个业务细节都摸透了，遇到线上问题自己冲在前面。但是当你的团队变成 8 个人了呢？当你的团队变成 20 个人了呢？你的团队变成了 100 个人了呢？你还能了解所有细节，你还能所有问题都自己解决吗？

想必对于这个问题的答案，大家都清楚，答案肯定是不可能！那么既然不可能，那么我们有什么办法去解决「大团队」的工作协作问题呢？此时这个问题就不再是技术问题，而是一个具体的学科问题，我想这或许是组织管理、领导力的概念了。这块我也不是很懂，所以这里就不展开了。下面我结合我的实际经验，聊聊十几个人的团队怎么做组织管理和分工协作。

团队达到十几个人，我们需要有授权的概念。授权的意思是我把一部分权利分给员工，员工可以在权利范围内自行决定，不需要经过 Leader 的同意。通过这种方式，来提高事情的处理效率。但授权同时也伴随着责任，这就像法律的义务与权利一样。

授权讲得直白点就是：这块业务给你搞了，这块业务上发生的任何事情，你都需要关注，包括线上问题、系统优化等等。你可以自行决定需求的技术方案以及优化改进措施（权利）。你是这块业务的直接负责人，业务有什么问题你就是第一责任人（责任）。

经过授权之后，一般十几个人的团队会拆分成 3-5 个人一组的小组，单独负责 1-3 个系统。这时候这几个小组是一个独立的单元，可以高效地自行运转，不需要你做太多的干预。这时候很多业务细节，其实并不需要你去干预。你只需要在关键时刻给予支持和辅导就可以了。

那么是不是 Leader 就完全不需要懂这块业务的内容了？那肯定不是，技术 Leader 只需要了解个大概，知道这个东西大致是什么，业务细节可以等到具体需要的时候再了解。

如何总览全局？

那对于技术 Leader 来说，怎么样快速了解一个系统？又怎样在需要的时候可以快速上手了解业务细节呢？对于我来说，了解一个系统最重要的其实就是两个东西：数据库 ER 图、系统架构图。

数据库 ER 图，其实就是业务模型。 所有的系统到最后其实就是数据，如果你弄懂了数据库 ER 图，明白了实体与实体之间的关系，那其实你就弄懂了这个业务。在你遇到问题的时候，你就知道怎么去找关联关系，怎么去排查问题。所以弄懂数据库 ER 图是很重要的。

系统架构图，其实就是系统的具体实现结构。 如果说 ER 让你弄懂了业务模型，那系统架构图就是让你明白系统是如何运作的！你弄懂了业务模型，但你不懂系统运作的原理，那你还是无法入手去排查问题、去写代码。但如果你弄懂了系统架构图，那你就知道系统数据流是如何走的，问题可能出现在哪里，我这个需求需要改动到哪些地方。

ER 图和系统架构图，基本上是我了解一个系统的关键。在实际工作中，我也是只了解这两个东西，再加上一些需求的大方向。而具体的细节，恕我直言，真的太多了，无法一一了解。如果真的到了那种需要技术 Leader 自己动手排查问题、自己动手写需求代码，那这个团队真的离崩塌不远了，所以这个问题其实可以忽略。

或许下次可以写一个：为什么技术 Leader 自己写代码、排查问题，这个团队就离崩塌不远了？

他山之石

上面就是我对这个问题的一些只言片语，说得有点乱，没啥太多的逻辑，但思想是对的。这个问题下也有不少热心的网友写了很不错的回答。这里也摘录一些。

诸葛瑾推荐了三本管理相关的书：

1. 拉姆查兰《领导梯队》，管理领域的经典力作，详细阐述了从基层 leader 到 CEO 各个层级的能力要求和工作方法。2. 陈春花《管理的常识》，顾名思义这本书是讲管理的基础概念，越是基础越需要理解，每次读都有不一样的收获。3. 前美军特种作战司令斯坦利麦克里斯特尔《赋能》，阐述的是如何像园丁一样通过给团队赋能，最大限度发挥团队成员的主观能动性，打造应对不确定性嗯敏捷团队，这本书对于如何对自己不擅长的专业领域进行有效管理非常有启发（这也是高层级管理者需要具备的可迁移的通用能力）

诸葛瑾聊了聊他的一些想法：

带团队重要的是如何带领团队形成合力创造更大的价值，并走向一个更好的未来。如果还一直在关注当下很多细节，说明团队没有成长起来，下面的人还不能独挡一面，或者内部外部的协同有问题。大概可以从以下几个方面思考：1. 定目标，短期与长期，个人与团队；2. 划边界，团队內与外；3. 追过程，关键节点；4. 拿结果，保质保量拿到目标结果；5. 建团队，选用育留开人；每个方面要做好都要花很多心思。一个优秀的管理者应该是这个团队有他没他都能运转的很好，这样才能更好地往下一个层级发展。

华山弟子举了一个很形象的例子：

如果你管理的团队，还要靠你来主力输出的时候，就需要考虑自己的问题在哪里了。这就好比京东物流，每天东哥送货量占比 50% 以上，这是什么画面。

腾讯员工聊了聊他的想法：

肯定不了解业务细节啊… 带领着一帮人做成一些事，才是 team leader 的职责，至于这些事需不需要他自己来做，根本无所谓，要的是结果。最基本的，一个项目扔给你们团队，能否保质保量按时交付。重要的是交付，而不是 leader 和大家一起写代码。更进一步，团队是否有战斗力，比如能否交付有难度的项目。这取决于团队成员的技术能力和协作能力，技术大佬可以是但没必要是组长。组长最重要的还是协调组织能力。如果自己不在一线，那就要想办法给一线兄弟们带去更多利益，不然谁跟着你干？楼主：也许我的思维还没转变，总想让别人知道自己干了多少事。回复楼主：干了多少事很简单啊，哪些活是你接过来的？这些活的意义你有没有了解清楚，价值是什么？怎么拆解给兄弟们的，怎么管理研发进度的？作为一个 tl 对整体项目负责，你做了哪些去负责？比如服务挂了你是不是不知道？为了监控到可能的问题，有没有做详细的监控方案，有没有兜底方案？这些事情你想到了，可以交给组员来实施，什么进度了你有没有跟进？为了提高迭代速度，你做了哪些研发流程的管控，从而提高组员的工作效率和需求响应时间？最终通过你的组织协调甚至直接参与架构和代码设计，团队做出了哪些成绩。

名草求主的回答也有不少人赞同：

不要想着带人的了解系列比底下人多，否则你就是不合格的主管，了解个大概，知道对方在做什么，给方向争取资源利益才是你该做的，否则就是不懂瞎指挥，做主管的自以为比别人懂导致实质意义的瞎指挥的真不少。

小结

回归到这个问题：技术 Leader 是怎么了解业务细节的？

我的答案是：不需要了解太多的业务细节！作为技术 Leader 只需要大致了解业务模型、系统架构就可以，细节问题交给手下的弟兄们。作为技术 Leader 的你还有更多、更重要的事情去做！

大家是否有类似的经历？是否也曾吐槽过自己的 Leader 啥都不懂瞎指挥？是否不理解为啥啥都不懂还能做 Leader？是否也曾陷入到业务细节的坑里面，无法自拔？留言区留下你的脚印吧～