技术管理
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 的观点非常有道理，团队达到一定规模后，管理者还去写代码，就是给团队添麻烦。长期不练手的你，编程能力已经不足以保证你的代码质量了；另一方面，投入精力写代码之后，其他需要你做的事情必然会被耽搁下来。
管理者不应该是职级层面的上级，而应该是分工层面的决策和协调者。
觉得不写代码会心慌的人，说明你把太多精力花在理事上了，谋略给丢了。实际上，在技术架构满足不了业务增长需求的时候，是需要你（和你的架构师一起）去拿出新的架构的；组员讨论几个方案拿不定主意的时候，也是需要你去做决策的。这些都是需要你平时花时间去不断丰富和充实你的技术的。否则一定是一将无能累死三军。
你并不应该陷入与人沟通和处理杂事的漩涡中，而是应该抽时间出来保持自己的技术敏感度。管理者和普通员工在技术上的区别，在于和技术打交道的方式变了。普通员工是写代码，技术管理者应该是学习技术和思考架构。
相关阅读
供应链管理系统是最早期面向企业的软件解决方案之一，供应商管理又是供应链链条中的上游部分。正值To B话题的热点，本文跟大家分享一
并发可管理工作队列的出现慢工作机制 为什么说是“提供过内核中还曾短暂出现过慢工作机制 (slow work mechanism)”，原因是在 main
软件评测师是“全国计算机技术与软件专业技术资格”中级认证，于2018年11月10号考试。 软件评测师教程有近700页。主要分为三大部分
首先，用过数据库
随着项目的积累，我们的文件目录会变得十分的盘大，如果不好好管理，将会变得一团糟，有时会影响到我们工作的效率与心情，好的文档管理方式