从技术转管理的困惑(转)

 

具备扎实的技术能力和良好的协作能力的人，在成长的过程中，往往会被推向技术管理的位置，成为一个团队的 Leader。成为 Leader 之后，困惑也会接踵而至：你最引以为豪的技术能力可能不再是团队里最强的了，你没有了那么多时间编写代码，你要处理各种复杂的流程和关系，部门内协作，多部门协作，你会感到恐慌、焦虑，并认为自己不是这块料。

还不如踏踏实实自己编程呢！这是很多技术人员在转变初期和我说的最多的一句话。

进入技术领域，上升通道差不多就两条，成为某个领域的技术专家，或者成为一个「Tech Leader」。如果你选择了后者，就意味着你不仅要面对计算机和代码，还要和人、流程和协作打交道。

我在洪恩写代码的时候，池宇峰常常在各个楼层间溜达，有一次站在我身后说：

小池，你大学毕业的时候编程水平咋样？
菜鸟一枚！
哦……根据我的经验，大学毕业还没成为程序高手的，一辈子也没法抵达编程的最高境界。
这么说我练不成九阴真经了呗？
嗯，最多也就形意八卦拳神马的……

我的人生观崩溃了，和另一个菜鸟抱头痛哭，问，那怎么办？池宇峰诡秘的一笑，我们可以领导他们！

后来我才知道，池宇峰大学时学化学的，对技术和编程一窍不通。

可能是因为性格原因，我在一个团队里干着干着就会被提为 Leader，从2001年开始带团队，差不多有十几年的时间。从技术到管理到产品，什么杂事都干过，我经历的这些阶段，写出来供大家把玩一下。

1、野蛮生长

刚开始带团队，规模都很小，几个人一个小组。我虽然是组长，但 80% 的精力仍旧放在编程上面，代码贡献在团队里数一数二。编程之余，我会帮助其他组员解决问题，并承担一些培训新人、跨部门协作的事务。问题不大，我在掌控一切。

2、分组而治

团队规模慢慢增长到了十几个人，人多了事情也成倍增长，制定计划、协作、Code Review、培训新人占掉了我大部分时间。编程时间越来越少，这时候我采取的措施是分组而治。我把十几个人分成了两组，自己带一组，在另一组内提拔了一个组长。这样我每周的工作就变成了编程、处理本组的事务，定期和第二组的组长交流，确认部门的整体方向没有偏离目标。

3、救火队员

团队规模继续增长，我把团队拆成了几个组，自己仍然带一个组，编程，协作，规划，最终发现自己的时间和精力已经不允许我再独立带一个组，并参与更多的编程工作，那样做我会成为最大的瓶颈。于是我把自己带的组也划了出去，开始直接面对各个组的组长，帮助他们解决问题。在这个阶段，我仍然是对整个部门技术体系最为熟悉的那个人，于是我成了一名救火队员。

每个组出了问题，我就会冲上去帮他们搞定，无论是线上还是线下。经常有人问做了管理还要不要兼顾技术，当然要，否则你会专注崩溃三十年。当一个问题无法解决的时候，当所有眼睛都在看着你的时候，你需要拿出勇气和耐力，抽丝剥茧的把问题解决，而不是不负责任的扔给别人，何况也没别人。

4、无为而治

团队规模继续扩大，这个时候我差不多已经能够接受自己的技术不能 Cover 整个部门的技术体系这个事实了。很多小伙伴在各个领域的技术都突破了我的界线。我则转身离去，开始关注更大的战略、产品和技术的未来。这个阶段我要做的事情就是制定出规则、领域和方向，找到合适的人，让他们尽情发挥自己的聪明才智。

好的领导者，不是大包大揽，也不是让下属去完成领导部署的任务，而是让他们做自己真正想做的工作。好的领导者不应该总是去试图领导别人，他们要及时反思，修正自己的思路和决策，听取别人的意见，并把一些决策权交给他人。

如果你未来成长为公司的领军人物，常常要反思的不是「我是不是做的太少了」，而是「我是不是管的太多了」。让每个人都能充分的去做正确的事情，事情差不多就能做成了。

看了这些普通人的个人经验，如果你觉得不够，再看看 Google 的工程师 Leader Matt Welsh 是怎么说的：

团队中的大部分人都是比我更强的技术人员，我完全要依靠他们的努力工作来开发出强壮、稳定的软件。我的工作是保护团队中的这些工程师不被打扰，在各方面给他们支持，帮助他们能顺利完成任务。

我大概要花50%的时间来写代码。我真的需要每天有一些固定的时间编写代码，这样能让我安静下来，清醒头脑。不像团队中的其他人，我很难有长时间不被打扰的时间段，所以我主要开发一些比较简单的任务，比如写MapReduce代码来分析服务日志，并生成性能报告。我真的非常喜欢做这样的事情，这种任务能让我接触到海量数据，用各种有趣的方式来拆解、汇总它们。因为我不需要通过展示高超的编程技艺来获取晋升机会，所以，那些非常惹眼的新功能都让团队中比我强的人去做。

我在团队软件开发大方向上会输出重要的影响，包括设计和架构方面。很大程度上是因为，相比起团队中的那些小伙伴，我在系统设计方面有更多的经验，当然，在某些我不熟悉的细节问题上，我需要听从那些实际编码人的意见。我的很大一部分工作是设置优先级，当在解决某个特殊问题，需要在几个都不怎么样的解决方案间做选择时，我来拍板（这也意味着，如果决策是错误的，我来承担责任）。

成长的轨迹变化无常，但世界上总会存在一些规则和痕迹可以遵循和参考。这些文字，如果能够让你有一点思考，就算价值。

越过淡雅如金童玉女的分割线，下面是问答部分：

问：做技术，核心竞争力就是技术强，简单明了。做管理感觉就没那么明了，哪些是管理的核心竞争力？对系统的整体理解，组织协调能力，视野，人脉，心胸，运气，还是位置本身？从职业发展速度等角度看，管理职位应该是一个更难胜任的职位才对。技术弱化带来的危机感（不安）的本质原因是什么呢？

答：我从下面几点说说。

1、从技术人员和技术领导的分布上来说，管理职位应该是个更难胜任的。当然，从分工上看，也不可能有那么多管理者，还要不要干活了……

2、管理者的核心竞争力包括并不限于：对事情整体的理解，能找到正确的方向，影响力，凝聚力，对人性的理解，资源。

3、技术弱化带来的危机感是因为人们总觉得要有一技之长才会比较安全，但是优秀的管理者会超越这些东西，他们关注的内容不再是某个具体的技术和实现，而是事情。让正确的事情，持续发生才是最重要的。在这个过程中，这些 Stakeholder 会不断提升自己各个方面的能力，并积累大量的资源。在未来，技术对他们来说已经不是最重要的东西了，虽然他们依然能够编写代码。

最后说一下，无论你干什么，运气这个东西都非常重要，但又可遇而不可求。我们只能说，强者运强！

问：能否推荐几本技术管理的书籍。

答：可以。

1、如果你刚刚开始承担一些管理职责，建议阅读《技术领导之路》

2、如果你已经有一定的管理经验了，建议阅读《极客与团队》和《重新定义公司》

3、如果你觉得自己在管理方面已经游刃有余了，建议阅读《格鲁夫给经理人的第一课》