吃老本

前一篇聊了成为技术管理者后，不免会在技术上有所退步，我们首先要接受这个事实。那接受后是不是就可以安心地吃老本呢，当然不是。在现金这个社会，只需要一两年，甚至更短的时间内技术就会迭代，一年前火热的框架，可能在今年就会被另一套技术或是框架所替代。作为技术管理者，除非你在成为技术管理者前已经有大量的沉淀，对各种技术融汇贯通，否则老本真没几年好吃。

Why/How/What

那既然技术迭代得那么快，而管理者又不可能完全专注于技术上，那么就要着眼于顶层的架构，能够对自己领域内的系统的不同设计回答why, how和what。why其实是最重要的，核心是回答一个系统服务于解决一个什么现实中的问题，就比如消息队列是一种服务间的异步通讯方式，主要解决不需要同步（即时性）的操作的请求和应答。how是回答为了实现这个功能，从meta层面如何设计这个系统，这儿有一个比较好用的判断标准，你能不能在10分钟（甚至5分钟）就把这个系统的设计思路给一个有一定技术背景但没有结束过你的系统的人讲清楚系统是怎么运作的，并谈谈其关键指标，不同设计的优劣与分别适用于怎么样的场景、需求。这儿还是以消息队列来举例，最经典的kafka的模型，producer -> broker/queue -> consumer，一个或多个producer发送消息到broker的某个topic，一个或多个consumer可以订阅broker的topic来获得更新，这就是最基础的how。what注重于细节设计，注重一个系统里每个子系统的设计与实现，了解的深度可以更加因地制宜，但一些关键点还是需要知道的。比如消息队列中broker的persistent策略，consumer如何确保不会漏消系，遇到重复的消息应该怎么处理等等。

Priority

一个技术型公司当技术团队超过50人后一线技术管理者需要更了解how和what，而更高层级的管理者的应该更偏重why和how，放手what。这儿举个WhatsApp的例子，当WhatsApp在被FB收购前还只有10~30人左右的工程师团队时，每个人都非常hands on，也没有什么一线技术管理，只有工程师，一个工程师负责一大块的功能。当被收购后慢慢团队到了50-100人，就开始出现技术管理，这个阶段没有太多的层级，所以每个manager其实也还是输出一定代码的。后期发展到几百人的团队，不同的国家都有团队时，一线manager就不会再输出太多代码了（偶尔会有一些，因人而异），而senior manager及以上更多地就会注重why，how并且challenge手下一些what的问题，来获得二手的信息。