35岁的程序员，真的要转管理吗？

Posted 2021-07-29 大数据v

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了35岁的程序员，真的要转管理吗？相关的知识，希望对你有一定的参考价值。

导读：做技术开发的人的职业规划通常有两个方向：一个是持续做技术，成为技术专家、架构师；一个是转管理，带领技术团队做开发。

开发团队需要管理者，开发出身的工程师做管理也是顺理成章的事。看起来不错，但有那么容易吗？

作者：李智慧

来源：大数据DT（ID：hzdashuju）

过去十几年，很多优秀的工程师成功转为技术管理人员，成功转岗的比例似乎比成长为技术专家的比例还要高一些。这也给了更多工程师转管理的信心，似乎技术转管理是一件相对容易的事。

事实上，过去十几年，技术人员之所以能够容易地转为管理人员，根本原因在于开发行业的快速扩张。随着互联网的快速发展，软件开发的从业人员数量大概增长了几十倍，开发团队规模迅速扩张，因此必须要有技术人员成为管理者，以管理越来越庞大的技术团队。

如果一个人在技术部门只有十来个人的时候加入公司，经过几年发展，公司技术部门有百余人，需要将其划分为十多个开发小组，每个小组需要一个技术主管，因此就需要十多个技术管理者，所以在公司早期加入的这些开发人员，如果能够胜任工作，跟着公司一起成长，大概率会被任命为技术主管。

如果公司继续发展，技术部门达到千余人，那么，百余人时加入公司的技术人员也有很大概率会被任命为技术主管，如果这个人在管理方面表现得足够好，则有可能会被继续提拔，成为经理、总监、CTO，在管理的道路上越来越成功。

看起来，技术转管理这条路似乎很光明，是软件技术人员一条不错的职业发展之路。

但是，这条光明的道路其实隐藏了一个非常重要的前提，那就是技术团队规模必须呈指数级增长，这样才能产生足够数量的管理岗位空缺，才会让后来的人跟前面加入公司的人一样有机会成功转型管理。

事实上，过去十几年中，整个行业的软件开发从业人员确实是指数级增长的；而最近几年，这一增长势头已经明显变慢；未来会怎么样，相信不用我说你也能做出判断。

如果整个行业的软件开发人员数量从现在开始不再增加，那么现在的工程师转管理的难度将比自己的前辈难一个数量级。

如果你觉得你的主管、经理的管理水平不过如此，你做管理不比他们做的差，这并不足以支持你成功转型管理。因为从时间上来说他们转管理的难度要远低于你现在转管理的难度，如果你的规划是将来几年转管理，那么局面会更加悲观。

我并不是在这里给你打退堂鼓，劝你放弃转管理。我们现在正在进行产业升级，各行各业都需要在科技水平和管理水平上进行升级，以应对更加激烈的全球竞争。这也许就是你的机会。

想要把握住机会，就不能仅仅以你的前辈作为榜样和基准，而是要进行更科学的管理方面的学习和训练。这里，我分享几个关于管理的基本原理和概念。

01 彼得定律

彼得在20世纪70年代研究了美国数千个组织，包括政府部门、学校、企业等，发现在一个成熟有效的组织中，当一个员工在其岗位能够出色完成工作时就会得到晋升，被提拔到更高一级职位。如果在这个职位，他能够继续出色地完成工作，就会继续得到晋升，直到他晋升到某个职位以后无法出色完成工作为止。

这是职场晋升的一般规则，看起来似乎没什么，但是彼得在对这些得到晋升的人进行各种观察以后，得出一个结论：在一个层级组织中，每个员工都会趋向于晋升到他所不能胜任的职位。这就是彼得定律。

事实上，根据晋升的一般规则也能推导出这个定律。利用这个定律做进一步的推导，还能得到一个彼得定律的推论：在一个成熟的组织中，所有的职位都被不能够胜任它的人承担着。

这个推论也很好理解，每个人都会晋升到他不能胜任的职位，那么稳定下来以后，所有的职位都会被不能胜任的人承担。不得不说这个结论实在让人有点吃惊，但是却很好地解释了组织中的各种奇怪现象。

彼得进一步对这些不能胜任自己职位的人进行观察，发现当一个人位于他不能胜任的职位时，他必须投入全部的精力才能有效完成工作，这个职位也被称作这个人的彼得高地。一个处于彼得高地的人，精疲力尽于他手头的工作，无法再进行更进一步的思考和学习，他的个人能力提升和职业进步都将止步于此。

所以，一个人在其职业生涯中能够晋升的最高职位，能够在专业技能上进化的最高阶段，依赖于他的专业能力和综合素养，依赖于他拥有的持续学习和专业训练的条件与环境，这和他晋升的速度无关。

对公司而言，真正有价值的是你为公司解决了多少问题，而不是完成了多少工作，工作本身没有意义，解决问题才有意义。对于你自己而言，真正有价值的不是你获得了多快的晋升、多高的加薪，而是你获得了多少持续高强度训练的机会。而这两者本质上是统一的。

所以，对自己的未来有更多期待、更有进取心的工程师，应该将精力更多地放在发现企业的各种问题并致力于解决问题，在这个过程中，你将同步收获职场晋升和个人能力提升。

02 用目标驱动

在技术管理领域，常见的管理方式有两种：一种是问题驱动型管理，一种是流程驱动型管理。

问题驱动型管理着眼于问题，每天关注最新的问题是什么，然后解决问题。流程驱动型管理着眼于流程，关注事情的进展是否符合流程规范，是否在有序的规章制度下行事，看起来像监工。

老实说，这两种都不是高效的管理方法。对于技术管理而言，更高效的管理方式是目标型管理。

目标驱动的管理者关注的是目标。公司的目标是什么？部门的目标是什么？团队的目标是什么？我的目标是什么？我和我的团队做这些事情的价值和意义是什么？不断问自己：我如何做才能为公司、为客户创造价值？

目标驱动的管理者并不特别关注问题，他更关注解决方案。当系统出现故障的时候，他不会关注是谁导致的Bug，而是更关注谁可以解决这个Bug。当项目进展缓慢的时候，他并不关注是谁导致了拖延，而是更关注我们如何做才能赶上进度。

他不问为什么出现问题，因为他知道，所有的问题最后都是人的问题，而纠结于人的问题只能导致人们彼此推诿。

目标驱动的管理者其实并不是不关注问题，他只是不用问题进行管理，不让团队纠结于问题之中，而是着眼于未来和解决方案本身。管理者自身其实对问题非常清楚，但是他把问题转化为目标，引导团队前行。

OKR这个词最近两年风靡于互联网企业。OKR其实就是目标（Object）与关键结果（Key Result），即通过对团队和个人制定有挑战性的目标和可量化的结果标准进行管理，可以说是目标驱动管理的一种落地实践方案。

通常在一个OKR周期开始的时候，每个团队和个人都会制定自己的OKR：我的目标是什么？达成目标后产生的关键结果是什么？所有的OKR都需要公开，通过阅读自己合作伙伴和上级部门的OKR，了解自己的目标在组织中的作用，自己工作的结果对组织的价值，从而了解自己在组织中的位置，使自己的工作成为组织战略的一部分。

在工作过程中，根据目标不断调整自己的工作方式，期间需要定期进行评审（Review）：到目前为止，我产出的成果有哪些？距离我们的目标是更近了还是更远了？我们还需要做哪些工作才能达成期望的结果？

需要注意的是，OKR并不是用来考核的，不应该以目标是否达成作为考核的依据，否则每个人都倾向于给自己制定最简单的结果和目标。

OKR是一种管理手段，通过对目标的制定和对结果的审核，将团队和员工的奋斗目标与公司的战略目标统一起来，使每个人都能理解自己工作的目标是什么，在整个公司战略中的地位如何，进而使每个人成为公司整体中重要的一部分。

03 小结

管理学作为一个学科已经出现了上百年，它有自己的专业工具和方法，也有自己的客观规律。技术做得好并不能保证管理做得好，想转管理的技术人应该专门学习一下管理学的基础知识，而不是仅仅看两篇公众号，觉得自己技术不错还擅长沟通就要转管理。

关于作者：李智慧，资深架构专家，同程旅行交通首席架构师，曾在NEC、阿里巴巴、Intel等知名企业担任架构师，也曾在WiFi万能钥匙等企业担任CTO。长期从事大数据、大型网站的架构和研发工作，领导设计过多个日活用户在千万级以上的互联网系统架构，实战经验丰富。曾设计、开发过 Web 服务器防火墙、分布式NoSQL 系统、大数据仓库引擎、反应式编程框架等各种类型的软件系统。

本文摘编自《架构师的自我修炼：技术、架构和未来》，经出版方授权发布。