大多数程序员都在纠结的问题：我要不要转回去做技术呢？从工程师到团队领导的相互转换

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

• 有人会一脸无奈地对我说：“管理的事儿太杂，都没时间写代码了，越来越心虚……”
• 有人语重心长地告诉我：“做管理最大的挑战是，要舍弃技术，特别难。”
• 有人会抬头反问我：“管理和技术到底该怎么平衡？”
• 有人会故作轻松地笑道：“突然不写代码了，感觉吃饭的家伙没了，哈哈。”
• 有人则会满心忧虑：“管理工作太琐碎，感觉离技术越来越远，现在特别担心个人发展。”
• 甚至还有人忿忿地跟我说：“管理是一个有违人性的事情，自己的技术越来越差，但是却要带领整个技术团队。”

诸如上面种种说法，如果我告诉你，我访谈过的上百位技术新经理中，大约三分之二的人都有类似的担忧和反馈，你会作何感想？如果你恰好正在经历这个阶段，你对于这个角色转变的最大感受又是什么？你又如何看待技术和管理间的“冲突”呢？会不会也像上述说法或忧虑，或愤慨？最后只能无奈地说：“反正也想不明白，就多投入一些时间来兼顾技术和管理吧！”

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

大致可以归类为以下三种情况。

1. 转管理之前没有仔细了解过管理。技术人员常常会沉浸在代码或某些技术细节当中，对于职业发展方向的思考整体偏被动。大多数的技术管理者是被领导“推到”管理岗位上去的，而在此之前对于怎么做管理并没有深入了解。不夸张地说，对很多技术新经理来说，管理几乎是一个全新事物。在全新事物面前，因为无法掌控而感到惶恐或焦虑就在所难免了。所以才会时不时冒出一个念头：万一做不好怎么办？退路在哪里？

2. 刚开始做管理，还无法靠管理“安身立命”。在技术新经理的心目中，管理能力并不能让自己安心，更不能让自己依靠，心的家园依然是过去这些年积累的技术能力。而管理就好像是还没有驯服的野马，虽然有时觉得挺新鲜挺刺激，但终究不确信能够骑好，所以不可依赖。在一个未掌控的新事物面前，想来这种心理也是人之常情。

3. 认为技术才是自己的“大本营”。技术作为自己生存的资本，在过去的工作中已经得到了很好的证明，因此非常值得信赖。这就是所谓的“成功路径依赖”，每个人都大抵如此。对于凡事讲究精确与可靠的技术人来说，尤其如此。所以，一遇到令人不爽的问题，还是希望回到自己的“大本营”——回去做技术工作。

把上面这三点放到一起看，恰好生动地反映出新经理此时的心态：“患得”“患失”。当然，这里没有贬义和批评的意思，只是描述一种纠结的心情。

“患得患失”出自《论语》，原文是“其未得之也，患不得之；既得之，患失之”，翻译成白话就是“还没有得到的时候，担心得不到；而得到了之后，又担心失去”。新经理的状态，从对自己安身立命的安全感角度来看，可谓正处在一种“青黄不接”的状态。

• 做管理还没有摸到门道，很多事不知道该怎么着手，经常会出现一些让自己不知所措的状况，倍感焦虑；
• 之前已经熟练掌握的技术能力，由于在上面花的时间越来越少，感觉正在离自己而去，倍感失落。

如此，“患得”的焦虑和“患失”的失落交织在一起，怎不令人烦恼呢！

 

解决办法：

一：“患失”

做技术管理，并不会放弃技术，而且也不能放弃技术，放弃了技术是做不好技术管理的。你只是在一定程度上，放弃了编码而已。那么，没时间编码，怎样才能做到不放弃技术呢？

首先，把技术提到更高视角来看待。

做技术的时候，把技术做好就是最大的目标。而做了管理之后，需要把技术作为一个手段来看待，看它究竟能为目标带来什么。显然这不意味着你就不需要再关心技术，只是关心的层次不同了：从研究怎么实现到研究怎么应用了，而且，你开始需要借助每个人的技术能力去做更大的事情了。

这很像在组装计算机，我们现在DIY一台计算机，已经不需要关心主板、内存、CPU的内部运行逻辑了，但还是要很清楚它们的功能是什么，接口什么样，以及从哪些维度、用哪些指标去衡量每个组件的优劣，也得清楚在整台计算机中，哪个组件可能会是性能瓶颈等等。所以，技术转管理并不意味着不关心技术，只是从关心技术实现，到关心更大的目标和整体结果了。

其次，换一种学习方式来掌握技术。

亲自写代码固然是很好的学习技术的方式，但是作为管理者，你需要快速掌握更多的技术，并快速判断该如何搭配使用，所以你一定得有更高效的学习方式才行。建立你的学习机制。你可以想想在团队内建立什么样的学习机制，可以帮助你借助团队的力量来提升技术判断力，并结合自己的情况来创建。

1. 请教专家。在了解某一个领域的情况时，借助你的平台，找你能找到的最厉害的专家高手进行请教。他们之所以能成为某个领域的高手，都是有着深厚的积累，并且能够用简单精准的语言给出高屋建瓴的关键意见，几句话就会令你有醍醐灌顶的感觉。

2. 共创。对于知识型工作者来说，和大家共创所收获的成功，往往比自己埋头思考要高效得多。你可以看看在团队中如何建立共创机制。

对于要快速提升技术视野来说，以上三个方式，比看书或写代码都更加高效，你可以选择适合自己的方式。具体的做法和建议，我们在后面对应的章节中介绍。

最后，还有一个做法：如果你是真心热爱技术，擅长用技术的思路和方案解决问题，你可以考虑做“技术型”管理者，让“技术范儿”成为你的管理风格。

做管理主要看结果和成效，对于手段并没有一定之规，有的管理者擅长带人，有的管理者则执行力特别强，有的管理者资源整合能力特别强等，不尽相同，你完全可以有自己的独特风格。身边是有这样的成功案例的，有的技术管理者已经带几百人的团队了，都做到技术VP了，还是一副“技术极客范儿”，这并不会成为他做好管理的障碍。总之，如果技术本身就是你的优势，你也可以结合自己的兴趣和优势，把它打造成自己的管理风格。

二：“患得”

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

首先，做管理对个人成长和个人发展来说，不会失败。

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

其次，对于技术新经理来说，即便“做不好”也并非没有“回头路”。

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

最后，做管理所积累的能力完全可以迁移到做“技术带头人”这个角色上。

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

三：“认清现实”

如果你把“编码时间减少”叫作放弃技术，那我不得不告诉你一个残酷的事实：无论你做不做管理，这事都不可避免——做技术管理，需要用更高的视角来看待技术；继续做工程师，也需要用更高的视角去看待技术。因此，对于大部分技术人来说，编码时间会越来越被其他工作所挤占，很难避免。

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

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

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

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