|
|
# 38丨技术管理之道：你真的要转管理吗？
|
|
|
|
|
|
做技术开发同学的职业规划通常有两个方向：一个是持续做技术，成为技术专家、架构师；一个是转管理，带领技术团队做开发。开发团队需要管理者，那么开发出身的工程师做管理者也是顺理成章的事。过去十几年，很多优秀的工程师成功转为技术管理人员，成功的比例似乎比成长为技术专家的比例还要高一些。这也给了更多工程师转管理的信心，似乎技术转管理是一件相对比较容易的事。
|
|
|
|
|
|
事实上，过去十几年技术人员之所以能够更容易转为管理人员，根本原因在于开发行业的快速扩张，过去十几年，随着互联网的快速发展，从事软件开发的从业人员数量大概增长了几十倍，开发团队规模迅速扩张。必须要有技术人员成为管理者，以管理越来越庞大的技术团队。
|
|
|
|
|
|
如果一个人在技术部门只有十来个人的时候加入公司，经过几年发展，公司现在技术部门有100多人，组织上差不多需要划分为十多个开发小组，每个小组需要一个技术主管，那么就需要10多个技术管理者，所以在公司早期加入的这个开发人员，如果能够胜任工作，跟着公司一起成长，那么大概率地会被任命为技术主管。
|
|
|
|
|
|
如果公司继续发展，技术部门达到1000多人，那么100多人的时候加入公司的技术人员也有很大概率会被任命为技术主管，如果这个人在管理方面表现得足够好，那么他可能会被继续提拔，成为经理、总监、CTO，在管理的道路上越来越成功。
|
|
|
|
|
|
看起来，技术转管理这条路似乎很光明，是软件技术人员一条不错的职业发展之路。
|
|
|
|
|
|
但是，这条光明的道路其实隐藏了一个非常重要的前提，那就是技术团队规模必须指数级增长，才能不断产生足够数量的管理岗位空缺，才会让后来的人跟前面加入公司的人一样有机会成功转型管理。
|
|
|
|
|
|
事实上，过去十几年中，整个行业的软件开发从业人员确实是指数级增长的，但是最近几年，这个增长势头已经明显变慢，未来会怎么样，相信不用我说，你也能做出判断。
|
|
|
|
|
|
如果整个行业的软件开发人员数量从现在开始不再增加，那么现在的工程师转管理的难度将比自己的前辈难一个数量级。所以，如果你觉得你的主管、经理的管理水平不过如此，你做管理不比他们做的差，这是远远不够的，这并不能够支持你成功转型管理。这是因为他们转管理的时候，难度要远低于你现在转管理的难度，如果你的规划是将来几年转管理，那么局面会更加悲观。
|
|
|
|
|
|
但是，我并不是在这里给你打退堂鼓，劝你放弃转管理。我们的国家现在正在进行产业升级，各行各业都需要在科技水平和管理水平上进行升级，以应对更加激烈的全球竞争局面。软件开发也不例外，虽然我们的互联网产业、软件产业看起来和国际接轨，水平还可以，事实上，我们的软件从业人员，不管是技术水平还是管理能力，和发达国家相比还是有较大差距。
|
|
|
|
|
|
最近几年，就我所见，开发人员的技术水平是在快速提升的，从我们这个专栏得到的反馈也确实如此。但是，技术管理者的管理水平却似乎并没有太多的进步，我想，这也许就是你的机会。
|
|
|
|
|
|
但是，你想把握住机会，就不能仅仅以你的前辈作为榜样和基准，而是要进行更科学的管理方面的学习和训练。这里，我跟你分享几个关于管理的基本原理和概念。
|
|
|
|
|
|
## 彼得定律
|
|
|
|
|
|
彼得在20世纪70年代，研究了美国数千个组织，包括政府部门、学校、企业等各种类型的组织后，发现，在一个成熟有效的组织中，当一个员工在其岗位能够出色完成工作，就会得到晋升，被提拔到更高一级职位。如果在这个职位，他能够继续出色完成工作，就会继续得到晋升，直到他晋升到某个职位以后，无法出色完成工作为止。
|
|
|
|
|
|
这是职场晋升的一般规则，看起来似乎也没什么，但是彼得在对这些得到晋升的人进行各种观察以后，得到一个结论：**在一个层级组织中，每个员工都会趋向于晋升到他所不能胜任的职位。**这就是彼得定律，事实上，我们根据晋升的一般规则，也能推导出这个定律。利用这个定律做进一步的推导，还能得到一个彼得定律的推论：**一个成熟的组织中，所有的职位都被不能够胜任它的人承担着。**这个推论也很好理解，每个人都会晋升到他不能胜任的职位，那么稳定下来以后，所有的职位都被不能胜任的人承担。不得不说这个结论实在是让人有点吃惊，但是却很好地解释了组织中的各种奇怪现象。
|
|
|
|
|
|
彼得进一步对这些不能胜任自己职位的人进行观察，发现当一个人位于他不能胜任的职位上时，他必须投入全部的精力才能有效完成工作，这个职位也被称作这个人的**彼得高地**。一个处于彼得高地的人，精疲力尽于他手头的工作，就无法再进行更进一步的思考和学习，他的个人能力提升和职业进步都将止步于此。
|
|
|
|
|
|
所以，一个人在其职业生涯中能够晋升的最高职位，能够在专业技能上进化的最高阶段，依赖于他的专业能力和综合素养，依赖于他拥有的持续学习和专业训练的条件与环境。和他晋升的速度无关，有时候也许恰恰相反。
|
|
|
|
|
|
对公司而言，真正有价值的是你为公司解决了多少问题，而不是完成了多少工作，工作本身没有意义，解决问题才有意义。对于你自己而言，真正有价值的不是你获得了多快的晋升，多高的加薪，而是你获得了多少持续高强度训练的机会。而这两者，本质上是统一的。
|
|
|
|
|
|
所以，对自己未来有更多期待，更有进取心的工程师们，应该将精力更多放在发现企业中的各种问题并致力于去解决问题，在这个过程中，你将同步收获职场晋升和个人能力提升。
|
|
|
|
|
|
## 用目标驱动
|
|
|
|
|
|
在技术管理领域，常见的管理方式有两种，一种是问题驱动型管理，一种是流程驱动型管理。
|
|
|
|
|
|
问题驱动型管理着眼于问题，每天关注最新的问题是什么，然后解决问题。流程驱动型管理着眼于流程，关注事情的进展是否符合流程规范，是否在有序的规章制度下行事，看起来像监工。
|
|
|
|
|
|
老实说，这两种都不是高效的管理方法。对于技术管理而言，更高效的管理方式是目标型管理。
|
|
|
|
|
|
目标驱动的管理者关注的是目标，公司的目标是什么？部门的目标是什么？团队的目标是什么？我的目标是什么？我和我的团队做这些事情的价值和意义是什么？不断问自己：我如何做才能为公司，为客户创造价值？
|
|
|
|
|
|
目标驱动的管理者并不特别关注问题，他更关注解决方案。当系统出现故障的时候，他不会关注是谁导致的bug，他更关注谁可以解决这个bug。当项目进展缓慢，他并不关注是谁导致了拖延，他更关注我们如何做才能赶上进度。他不问问题为什么出现，因为他知道，所有的问题最后都是人的问题，而纠结于人的问题，只能导致人和人的扯皮。
|
|
|
|
|
|
目标驱动的管理者其实并不是不关注问题，他只是不用问题进行管理，不让团队纠结于问题之中，而是去着眼于未来和解决方案本身。管理者自身其实对问题非常清楚，但是他把问题转化为目标，引导团队前行。
|
|
|
|
|
|
OKR这个词最近两年在互联网企业很风靡，OKR就是Object目标与Key Result关键结果。通过对团队和个人制定有挑战性的目标和可量化的结果标准进行管理。可以说是目标驱动管理的一种落地实践方案。
|
|
|
|
|
|
通常的做法是在一个OKR周期开始的时候，每个团队和个人制定**自己的**OKR：我目标是什么，达成目标后产生的关键结果是什么。所有的OKR都需要公开，通过阅读自己合作伙伴和上级部门的OKR，了解自己的目标在组织中的作用，自己工作的结果对组织的价值，从而了解自己在组织中的位置，使自己的工作成为组织战略的一部分。
|
|
|
|
|
|
在工作过程中，根据目标不断调整自己的工作方式，期间需要定期进行review：到目前为止，我产出的成果有哪些，距离我们的目标是更近了还是更远了，我们还需要做哪些工作才能达成我们的结果。
|
|
|
|
|
|
需要注意的是，OKR并不是用来考核的，不应该以目标是否达成作为考核的依据，否则每个人都倾向给自己制定最简单的结果和目标。OKR是一种管理手段，通过对目标的制定和对结果的审核，将团队和员工的奋斗目标和公司的战略目标统一起来，使每个人都能理解自己工作的目标是什么，在整个公司战略中的地位是什么，使个人更加成为公司整体的一部分。
|
|
|
|
|
|
## 小结
|
|
|
|
|
|
管理学作为一个学科已经出现了上百年的时间，它有自己的专业工具和方法，有自己的客观规律。仅仅技术做得好并不能保证可以好管理，想转管理的同学应该专门学习一下管理学的基础知识，而不是仅仅看了两篇管理文章，觉得自己技术不错还擅长沟通就转管理了。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
最后，我问你一个问题吧，也是人们常见的疑惑，OKR和KPI的关系到底是什么？
|
|
|
|
|
|
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
|
|
|
|