技术管理到底管什么 - 好文

https://mp.weixin.qq.com/s/QN1OKEFT3DiA82-OAp858Q
<https://mp.weixin.qq.com/s/QN1OKEFT3DiA82-OAp858Q>

前些天从湾区日报上看到美国一家叫 Gusto 的公司 CTO 的文章，他 6 年前开始创业，一开始他是唯一的工程师，几乎 100% 时间都在写代码；后来
2-10 个工程师的时候，40% 的时间花在招人上；11-50 个工程师的时候，自己若写代码就是给团队添麻烦；51-100个工程师时，60% 时间管人，40%
时间招人。

国内也大同小异，管的人越多的时候，写的代码就越少，到最后一行代码都不写。这是典型的技术管理路线，当然，还有另一条技术专家的路线，不在今天说的主题范围内。

那到底技术管理要管什么呢？开头那个 CTO 最后的工作变成 60% 管人，40% 招人，招人来还是要管，好像最后技术管理就等于管人了。真是这样吗？

哪怕技术管理真的就等于管人，那管人又管什么呢，或者说怎么管呢？

无论是春秋战国时候的丞相，还是三国时候的谋士们，技能大概分成两种：谋略和理事。谋略重在想办法，理事重在做事情。但凡有名的丞相谋士至少有一样特长，两者兼顾的自然是不世功勋唾手而来。

丞相和谋士就是管理者，并且有别于将军们，他们是技术管理者。

现代的技术管理者需要的核心技能仍然是这两样，只不过体现形式有些变化。

*
谋略：技术架构搭建、新技术演进选型等，解决该做什么和怎么做的问题。

*
理事：任务和人员协调、分配等，解决谁来做、哪件事先做的问题。

所有技术管理，或者管人，都是很抽象的说法，听着好像对极了，真做的好的屈指可数，很大程度上是因为很多人根本没搞清楚技术管理到底该管什么。

把握好谋略和理事这两条，技术管理才能真正落地，团队战斗力才能真正体现出来。

这篇文章其实到这里就可以结束了，点到即止。

但是有两个典型的问题还是有必要顺便探讨下。

第一个问题，虽说技术管理不能直接等价于管人，但实际上管理者大部分时间还是要和人打交道。那怎么处理人的问题呢？

我的经验是，我们的目的应该是把事情做好，管人只是一种方式而已。以代码规范为例，最好的方式是，通过技术手段去保证，不按照规范去做的代码没法提交成功；次好的方式是，建立规范准则，要求大家去遵守；最坏的方式是，质问和批评为什么不这么做。

不要轻易尝试去改变一个人，哪怕你是为他好，哪怕改的是缺点对他也有好处。作为管理者，你没有权利也没有义务去改变你的组员。当然，你有让他们进步的义务。健康的团队不应该过度依赖任何人（包括管理者本身），保持一定的离职率才能有机会引入新鲜血液。从这个角度看，也没有必要非得去改变谁。当然，重点对象还是可以尝试多去培养下的。

第二个问题，技术管理者不写代码好心慌。

开头那个 CTO
的观点非常有道理，团队达到一定规模后，管理者还去写代码，就是给团队添麻烦。长期不练手的你，编程能力已经不足以保证你的代码质量了；另一方面，投入精力写代码之后，其他需要你做的事情必然会被耽搁下来。

管理者不应该是职级层面的上级，而应该是分工层面的决策和协调者。

觉得不写代码会心慌的人，说明你把太多精力花在理事上了，谋略给丢了。实际上，在技术架构满足不了业务增长需求的时候，是需要你（和你的架构师一起）去拿出新的架构的；组员讨论几个方案拿不定主意的时候，也是需要你去做决策的。这些都是需要你平时花时间去不断丰富和充实你的技术的。否则一定是一将无能累死三军。

你并不应该陷入与人沟通和处理杂事的漩涡中，而是应该抽时间出来保持自己的技术敏感度。管理者和普通员工在技术上的区别，在于和技术打交道的方式变了。普通员工是写代码，技术管理者应该是学习技术和思考架构。

热门工具换一换