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