欢迎阅读新一期的数据库内核杂谈。这期是一期番外篇，主题和数据库无关，源自我最近的一次技术分享：成为技术管理者后，如何保持技术敏感。我把分享的文稿整理成了这篇博文。
作为技术管理者，为什么还需要保持技术敏感？
在讨论如何做之前，我们应该先讨论一下为什么。成为技术管理者(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 字左右的博客，憋得死去活来的心情。所以真心敬佩每个老师的坚持，几乎是每周两到三篇的速度更新。
以上，就是我自己粗浅的对于管理者如何保持技术敏感的建议，感谢阅读。 |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
