由于工作关系，我经常有机会和转管理前后的准经理或新经理聊天，并经常会问他们这样一个问题：“经历从工程师到团队 leader 这个转变，你最大的感受是什么？”

有人会一脸无奈地对我说：“管理的事儿太杂，都没时间写代码了，越来越心虚……”

有人语重心长地告诉我：“做管理最大的挑战是，要舍弃技术，特别难。”

有人会抬头反问我：“管理和技术到底该怎么平衡？”

有人会故作轻松地笑道：“突然不写代码了，感觉吃饭的家伙没了，哈哈。”

有人则会满心忧虑：“管理工作太琐碎，感觉离技术越来越远，现在特别担心个人发展。”

甚至，还会有人忿忿地跟我说：“管理是一个有违人性的事情，自己的技术专业性越来越差，但是却要带领整个团队。”

诸如上面种种说法，如果我告诉你，我接触过的上百位技术新经理中，有大约三分之二的人都有类似的担忧和反馈，你会不会大吃一惊？

如果你恰好正在经历这个阶段，你对于个人角色转变的最大感受又是什么？你又如何看待技术和管理间的“冲突”呢？会不会也像我的几位学员那样或忧虑，或愤慨？最后只能无奈地说：“反正想不明白，就多投入一些时间来兼顾技术和管理吧！”

然而，“两者兼顾”并不能真正解决问题，要解决这些问题，我们得首先来看看问题的真正根源是什么，然后才能对症下药。回想一下上面我列举的那些烦恼，它们有什么共同点呢？

我认为大致可以归类为以下三种情况：

  1. 转管理之前没有仔细了解过管理。技术人员，常常会沉浸在代码或者技术细节当中，在职业发展方向的思考上，整体偏被动。他们往往是被领导推到管理岗位上去的，而在此之前对怎么做管理并没有深入了解。因此对很多技术新经理来说，管理几乎是一个全新事物。在全新事物面前，因为无法掌控而感到或恐慌、或焦虑就在所难免了，时不时就会冒出一个念头：万一做不好怎么办？退路在哪里？
  2. 才开始做管理，还无法靠管理“安身立命”。至少在他们自己心中，管理能力并不能让自己安心，更不能让自己依靠，就好像还没有完全驯服的野马，还不确信能骑好，想来这也是人之常情。
  3. 认为技术才是自己的“大本营”。由于技术作为自己依存的资本，在过去的工作中已经得到了很好的证明，因此非常值得信赖。所谓“成功路径依赖”，每个人都大抵如此，尤其是做事特别讲究精确与可靠的技术人，自然在所难免。

以上三个共同点归结到一起，恰好如实反映了新经理此时的状态：“患得”“患失”。当然，这里没有贬义和批评的意思，只是说明一种纠结的心情。“患得患失”出自《论语》，原文是“其未得之也，患不得之；既得之，患失之”，翻译成白话就是“还没有得到的时候，担心得不到；而得到了之后，又担心失去”。

新经理的状态，从对自己安身立命的安全感角度来看，可以说是一种青黄不接的状态。他们对于做管理，还没有摸到门道，不知道该怎么搞定，经常出现一些让自己不知所措的状况，倍感心焦；而之前已经熟练掌握的技术能力，因为在上面花的时间越来越少，感觉正在离自己而去，怎不令人烦恼呢！

既然，我们已经知道了“病根”，那么怎么祛除烦恼呢？我这里有三个药方，每一个都会缓解烦恼，如果三管齐下，应该会神清气爽了吧！

第一个药方，专门针对“患失”来开。

作为一个做过技术 VP 和 CTO 的所谓“过来人”，我可以负责任地说，做技术管理，你并没有放弃技术，而且也不能放弃技术，放弃了技术是做不好技术管理的，你只是在一定程度上，放弃了编码而已。那么，都没时间编码，怎样才能做到不放弃技术呢？

首先，把技术提到更高视角来看待。做技术的时候，把技术做好就是最大的目标；而做了管理之后，你会把技术作为一个手段来看待，看它究竟能为目标带来什么。但这并不意味着你就不再关心技术，只是关心的层次不同了，你开始需要借助每个人的技术能力去做更大的事情了。

这很像在学习组装电脑，即便已经不需要关心主板、内存、CPU 的内部运行逻辑，但你还是要很清楚它们的功能是什么，接口什么样，以及从哪些维度去衡量一个主板的好坏、内存的好坏、CPU 的好坏，也得清楚在整台电脑中，哪个部件可能会是短板，等等。所以，技术转管理并不意味着不关心技术，只是更关心更大的目标和整体结果了。

其次，换一种学习方式来掌握技术。你要深刻地认识到，亲自写代码固然是很好的学习技术的方式，但是作为 leader，你需要快速掌握更多的技术，并且快速判断该如何搭配使用，所以你一定得有更高效的学习方式才行。这里我介绍三个行之有效的做法：

  1. 建立你的学习机制。你可以想想在团队内建立什么样的学习机制，可以帮助你借助团队的力量来提升技术判断力，并结合自己的情况来创建。
  2. 请教专家。在了解某一个领域的情况时，借助你的平台，找你能找到的最厉害的专家高手进行请教，他们之所以成为高手，一般都能给出高屋建瓴、醍醐灌顶的认知。
  3. 共创。在这个知识型工作者的时代，和自己埋头思考相比，共创成果往往会出乎你想象，特别能增长见识，你可以看看在团队中如何建立共创机制。

对于要快速提升技术视野来说，以上三个方式，比看书或写代码都更加高效，你可以选择适合自己的方式。

最后，关于“患失”，还有一个视角，如果你是真心热爱技术，擅长用技术的思路和方案解决问题，你可以做技术型管理者。做管理主要看结果，对于手段并没有一定之规，你完全可以有自己的独特风格。

你是否发现，有的技术管理者已经带几百人的团队了，还是一副技术极客范儿？有的管理者擅长带人，有的管理者则执行力特别强，而有的管理者资源整合能力特别强，等等，不一而同，只要和自己团队的核心职能具有一致性就好。如果技术本身就是你的优势，你完全可以结合自己的兴趣和优势，打造出自己的管理风格。

以上就是我开出的第一个药方：无论从哪个方面讲，你都并没有放弃技术，只是换了一种方式去学习和运用技术。所以，你不会失去什么，也不需要“患失”。

第二个药方，专门针对“患得”开出。

这里的“患得”其实是患“不得”，那么怎样才能不再担心做不好管理呢？

首先，做管理对个人成长和个人发展来说，不会失败。因为管理总体上是一项修炼，只要你持续不断地实践、练习，你的造诣就会越来越高，最后你一定可以胜任某个规模或某个职能的团队。我们通常所谓的“不胜任”，只是说不匹配，而不是说你就完全做不了管理。而且，管理是很个性化的工作，你完全可以使用自己擅长的方式，去达成管理效果。

其次，一线技术管理者，即便“做不好”也并非没有“回头路”。刚刚从工程师岗位转到管理者岗位时，离技术很近，如果尝试下来，感觉管理工作确实不是自己想要的，那么，回过头来继续做工程师，几乎是没有门槛的。所以，如果当下不知道自己适不适合做管理，不如全力以赴去尝试一段时间，你其实还有充足的时间来慢慢做这个决定，不需要有后顾之忧。

最后，做管理所积累的能力，完全可以迁移到做“技术带头人”或“技术 leader”这个角色上。所以，你都不用担心管理的工作会白做，或者本来可以做技术的时间被耽误了。因为，即便你再回头去做工程师，也需要练习去做高级工程师或架构师，需要尝试去负责一个完整的技术方向，此时，你做管理时锻炼的全局视野、规划能力、结果导向意识、项目管理方法、沟通协调能力等等，都会派上用场。

所以，我开出的第二个药方就是：你一定会有所得，会在做管理过程中有丰富的收获，既然一定能“得到”，所以不需要去“患得”。

第三个药方，有点猛，叫做“认清现实”。

如果你把“编码时间减少”叫做放弃技术，那我得告诉你一个残酷的现实，无论你做不做管理，这事都不可避免。现实是，你要么做技术管理，用更高的视角来看待技术；要么你继续做工程师，也要用更高的视角去看待技术。

俗话说：“人穷则反本”，当人们遇到困难和挫折的时候，就想回到老路上去，这是人之常情。只是，你不得不面对的一个现实就是，即便回头去继续做技术，也不再是原来那个听指挥听安排就好、做好执行就 OK 的一线工程师，工作“升维”已不可避免。一方面，每个人的内心都有成长的诉求；另外一方面，公司和团队也需要你承担更复杂、更具挑战性的任务。

所以，无论是做技术管理，还是做技术架构师，开启一条技术升维之路，都在所难免。即便不做技术管理者，要做好一位技术带头人或架构师，工作视角也要做如下的升级：

  • 首先，从目标出发去看待技术。只有目标明确，才能选择最佳的技术方案，做出最好的技术决策。
  • 其次，从评估的角度去看待技术。做工程师的时候，把一个技术方案设计好、实现出来就好了，而做了架构师之后，你需要非常清楚一个技术方案是通过哪些维度来评估其好坏优劣的。并且，当一个技术问题暴露出来之后，得迅速判断会造成什么影响，损失的边界在哪里，有多紧急，以决定要不要放下手头的项目去立一个紧急项目。
  • 最后，从借助自己的技术到借助大家的技术。做技术的时候，了解自己能做什么就好了。但是无论是做管理者还是架构师，你都需要带人做事了，这个时候你就需要熟悉团队里每个人的技术情况，知道谁能胜任做什么事情，适合做什么事，然后借助大家的技术去做事。

综上你可以看到，即使是放弃管理继续做技术，从工程师进阶到架构师，也一样有很多的视角需要转换，有很多的能力需要锻炼。

所以，第三个药方就是：既然你避无可避，不如奋力向前。你要做的并不是要免除“后顾之忧”，而是需要意识到，你已经没有机会“后顾”了。

总之，技术转管理的纠结，归根结底是“对管理的患得和对技术的患失”。既然你已经看到，做管理不会让你“患得”，也不会让你“患失”，那么你是不是可以安心了呢？

向前冲吧，皮卡丘！

也欢迎给我留言，我们一起分享和探讨。