欢迎阅读新一期的数据库内核杂谈。这期是一期番外篇，主题和数据库无关，源自我最近的一次技术分享：成为技术管理者后，如何保持技术敏感。我把分享的文稿整理成了这篇博文。

作为技术管理者，为什么还需要保持技术敏感？

在讨论如何做之前，我们应该先讨论一下为什么。成为技术管理者(engineering manager)后，在很多公司，包括 Facebook，首要职责不再是技术输出，而是如何带领团队去做事(deliver)，如何提高团队凝聚力，如何做好团队成员管理（让成员 feel happy, feel motivated，帮助她/他们成长）。技术管理者的 OKR 或者 KPI 肯定不是参与系统设计，或者是开发代码，甚至不是 code review。相反，在绩效考评的时候，大家可能会质疑作为管理者，为什么还在做 IC 做的事，你是否把时间都花在了刀刃上。诚然，有些公司还是保留了 TLM(tech-lead manager)的职位，但是 TLM 的第一职责依然是团队管理。我觉得 TLM 是比较矛盾的职位，一方面，TLM 需要贡献相应的技术输出，但同时，应该引导团队成员成长和贡献。有点，既当裁判员，又当运动员的意思。我自己不成熟的总结是技术管理者应该时刻去关注这三个关键：团队成员(team)，愿景和方向(direction)，有效机制(process)：团队是否在做正确的事；是否有有效机制来协助团队做事；团队成员是否合理和高效，成员是不是有效激励且有归属感，是否在成长。做好这些事，似乎并不需要技术上保持敏感？

我认为，保持技术敏感，绝不是要让管理者继续深入参与系统设计，参与写代码。更不应该是，以技术服人（国内的一些技术公司是希望管理者可以以技术服人，比如，会晋升原先技术最强的人来做管理者。这个，和北美很多技术公司是相反的策略）。你希望团队可以不断招到技术更牛的人，而不是让管理者成为整个团队的技术瓶颈。那保持技术敏感，有哪些好处呢？ 我认为有下面这些好处。

1）更高效地管理团队：技术敏感的管理者在和团队沟通（特别是和 senior engineers 或者 TL 时），理解系统架构甚至技术细节时会更高效。虽然管理者不需要参与代码开发，但是，依然需要了解团队如何开发系统来支持业务，技术路线是什么。你在向上汇报的时候，也会需要这些信息。而获取这些信息，主要是通过沟通来完成的。比较深厚的技术积累和技术敏感，可以让管理者在和组里 TL 沟通更高效。毕竟，作为管理者，我们不希望 TL 在和你交流的时候，觉得“对牛弹琴”，想着这个 manager 怎么啥都不懂。

2）更好地影响团队技术路线和 direction。规划正确的技术路线对于团队成功至关重要。我觉得，这个重任不能只落在 TL 的肩上。因为，管理者最终应该对团队是否能够 deliver 负责，如果技术路线规划错误，导致团队不能 deliver，最终责任在管理者。技术敏感的管理者就可以更好地参与规划。我不鼓励，管理者直接制定技术路线，但应该去评审，和影响最终决定。对于管理者对于技术路线的影响，一个脑洞比较大的类比就是比特币区块的验证，管理者可能并不是 power 最强的节点来计算出新区块的 hash，但应该具备验证这个 hash 正确性的能力。

3）英雄惜英雄 - 更容易吸引技术能力强的候选人加入团队。技术牛人是容易抱团的，毕竟大家都希望能够更高效地合作来做事。这点，我自己深有体会。因为我现在还积极参与系统设计面试，如果遇到优秀的候选人，作为面试官，你是可以近水楼台先得月来抛出橄榄枝。

4）作为发展最迅猛的 IT 领域，我认为，必须不断去学习，来跟上整个行业的发展。技术敏感和积累深厚的管理者可以在学习上事半功倍，效率更高。

难点和挑战

作为管理者，保持技术敏感的难点和挑战在哪？

1）首先还是，保持技术敏感不是管理者的 KPI，你不会把重心放在上面（你也不应该）。团队成员和团队是否在 deliver 才是关注的重点。

2）时间不够用。管理者的大部分工作是通过开会来完成的：向上沟通，向下沟通和 XFN 沟通。你很难有大块的时间来阅读技术文档和代码去深入理解系统。

3）拳会离手，曲会离口。管理者不应该直接参与系统设计，这是团队成员应该去做的事。原先积累的经验和技能会慢慢生疏。

4）如果是以管理者加入一家新公司或者新团队，一切都是从零开始。如果你是从原本的团队成长起来成为管理者，大概率你对整个系统，业务是比较熟悉的。对于后续的演进，也更容易更近。但对于新团队或者新公司，一切都重新清零。

保持技术敏感的建议

说完了重要性和难点，终于进入正题，可以开始聊具体的建议了。

Tip 1：心态平和地去接受现实。就像上文描述的，管理者的 KPI 不是代码实现，不是系统设计。管理者也应该理解上述的难点。所以，一定要心态平和地去接受。你不会像在 IC 时那样，对代码和系统如数家珍。我自己在刚作为管理者时，就犯过一个错误：我一直要求自己能够继续 review 大部分的团队成员代码来保证我对系统的理解。每个人的时间是有限的，这就导致我在其他方面做得不好。

Tip 2：在成为管理者之前，打好基础和内功。在还是 IC 的时候，你的主要职责就是代码开发和系统设计。一定要在这个阶段打好基础，做到厚积薄发。IT 已经发展到很难做到在各个细分领域都精进，但我们依然提倡 T 型人才：在自己的领域可以非常深挖，同时，对于其他领域和业务，需要有所涉猎并快速理解。

Tip 3：抓重点，从关键指标来了解系统。作为管理者，你依然需要非常清楚地知道团队构建的系统是用来做什么的：用来支持什么业务，有哪些关键指标， 哪些关键技术细节，如 QPS 是多少？是否需要强一致性？是否是夸区域部署，技术栈，等等。我觉得管理者可以从黑盒角度来认知系统。

Tip 4：参与系统设计面试。这是我最喜欢的 tip，自己也是坚持贯彻执行。参与系统设计面试对于面试官的技术深度非常有考验。大家可能觉得，系统设计的题目是固定的，作为面试官可以提前准备，会从各个角度去参考，好，中，差的设计决定。诚然，比起候选人，面试官是有先发优势的。但在面试的过程中，你永远不知道候选人会提出什么样，天马行空的设计思路，或者问题。这就需要面试官在短时间内针对提出的设计思路和问题来做判断，这非常考验面试官的技术积累。你不希望被候选人套路，同时也不希望给候选人留下“这个面试官好像不太行”的印象。另一个好处就是，你真的可以从有经验，技术背景很强的候选人中学到很多，受益匪浅。最后就是上文提到的，作为面试官，如果你能在面试中也表现出深厚的技术积累，做到让候选人英雄惜英雄。是更容易吸引候选人加入的。

Tip 5：参与事故复盘会议。通常复盘会议是用来讨论严重的用户事故的（比如，欧洲用户无法登录 WhatsApp 或者发送消息）。复盘会议会讨论事故细节，如事故影响，是怎么被发现的，怎么被修复的，更重要的是，怎么能够避免类似事故再次发生。参与复盘会议，类似于从关键维度来了解系统。

Tip 6：持续学习。套用现在时髦的话来说，终生学习。我们很幸运，处在 IT 领域，有幸参与了软件行业改变世界。同时，我们也不那么“幸运”，因为行业发展太快，需要不断去学习新知识，新趋势，区块链，人工智能，IOT。不然，很快就被淘汰了。平时的工作总是有局限性，不能覆盖广度。不过好在，现在有很多其他的途径可以学习。

一是通过 follow 各类 tech blogs。我曾在知识星球上分享过自己 follow 的 tech news 和 blog。贴在这里，和大家一起讨论。

• Airbnb Eng Blog: Airbnb 还是蛮注重开源的，经常有不错的项目分享。另外，如果想去面试，也推荐看看。
• All Things Distributed: 是 Amazon CTO Werner Vogels 的博客
• Cockroach Labs: 另一家目标做成开源 Google Spanner 的数据库公司（对标咱们国内 PingCAP 的 TiDB）。经常分享数据库开发相关的 blog。
• Distributed Systems NewsLetter: 某个热心人维护的 distributed systems 的新闻，有 paper, 业界新闻和 Video talks。不过，5 个月前停更了，因为太忙了。。。
• Dropbox Tech Blog: Dropbox 公司的 tech blog。同 1）
• English(US)：是 Twitter 公司的 tech blog。
• Gates Notes: 这个不算技术博客啦。听听 Gates 大佬的分享，特别有大局观。更重要的是，他会定期推荐他阅读的书籍，非常推荐这个。
• Google AI Blog: 虽然不是 AI 这一领域的，还是应该关注一下业界最新进展。

• Hacker News：HN 就不用多介绍了吧。必须订阅；
• High Scalability: 不需要特别介绍了吧。会定期搜集最新的业界新闻，大佬 tweet, Talk 和 blog。号称面试必看。。。（讲真，作为一个资深面试官，我希望大家是真的吃透，而不是就看几篇 blog，会几个 buzz word 就大谈高可用，高扩展，所以光看 blog 是搞不定面试的）但是感觉现在质量和频率有下降；
• LinkedIn Eng Blog：LinkedIn 也是比较注重开源和分享的；
• Luc Perkin 的个人博客：得知他是从一本书，Seven Databases in Seven Weeks: A guide to modern databases and the NoSQL movement。老哥的更新比较慢，书还是很推荐的： https://7dbs.io/；
• Martin Fowler 老爷子的博客：老爷子也不用多介绍了吧，OODesign，UML Modeling。老爷子的博客会分享些架构啥的，而且还会分享自己拍的照片，挺逗的；
• Martin Kleppmann 的个人博客：得知他也是从一本书，强烈推荐他的 Designing Data-Intensive Applications（这本书是强烈推荐!)；
• Netflix TechBlog: Netflix 也是非常注重开源和微服务，有很多不错的技术分享；
• Reddit Programming：Reddit Programming 板块，内容上可能和 HN 有些重复。

• Slashdot: news for nerds；
• Pinterest Eng Blog：Pinterest engineering blog；
• TechCrunch: 主要是创业公司相关新闻；
• The morning paper（https://blog.acolyer.org/）: 一个叫 Adrian Coyler 的维护的专门介绍计算机 research paper 的网站。这个真的是我自己压箱底的。Adrain 的分享非常深入浅出，读他的 blog 对整篇 paper 就能有个大概了解。前阵子停更了，Adrain 说家里有亲人患上了新冠病毒(Adrain 在英国应该)，好在一切都慢慢恢复了；
• Uber Engineering Blog: Uber 还是很注重开源的，经常分享有意思的项目；
• Solidot：Slashdot 的中文版；
• 爱范儿：主要了解国内资讯。

抛砖引玉，如果大家有好的资讯频道，请留言分享。

二是阅读技术类书籍。这边就不具体推荐某些书籍了，分享一个如何获知最新书籍的方式。HackNews 上会有人不定期写 book review 的帖子，介绍最新技术书籍的。可以帮助你大致了解书籍并决定是否需要深入阅读。

最后一类途径就是知识付费，推荐极客时间。我自己是极客时间的早期和忠实用户。买了蛮多课程，都会去学，即使不是自己领域的。非常感谢所有老师的分享，真的帮助我高效地了解了很多领域。极客时间的编辑也联系过我希望可以参与课程。但我自从自己写博客后，才体会到每个月憋一个 3000 字左右的博客，憋得死去活来的心情。所以真心佩服每个老师的坚持，几乎是每周两到三篇的速度更新。

以上，就是我自己粗浅的对于管理者如何保持技术敏感的建议，感谢阅读。