欢迎来到新一期的数据库内核八卦。本期是小说，主题与数据库无关，来源于我最近的技术分享：成为技术mhdxte后如何保持技术敏感。我把分享的稿件整理成了这篇博文。
作为技术mhdxte，为什么还需要保持技术敏感？
在讨论如何做之前，我们应该讨论一下为什么。成为技术mhdxte(工程经理)后，在包括脸书在内的很多公司，首要职责不再是技术输出，而是如何带领团队交付，如何提高团队凝聚力，如何管理好团队成员(让成员感到快乐，感到有动力，帮助她/他们成长)。mhdxte的OKR或KPI肯定不参与系统设计，或开发代码，甚至代码审查。相反，在绩效考核过程中，人们可能会质疑为什么mhdxte还在做IC正在做的事情，你是否把所有的时间都花在了前沿。诚然，一些公司保留了TLM(技术主管)的职位，但TLM的首要职责仍然是团队管理。我认为TLM是一个矛盾的立场。一方面，TLM需要贡献相应的技术输出，但同时也要引导团队成员成长和贡献。有一点，意味着既是裁判又是运动员。我不成熟的结论是，科技mhdxte要时刻关注这三个关键：团队成员、愿景和方向、有效机制：团队是否在做正确的事情；是否有有效的机制协助团队做事；团队成员是否合理高效，成员是否有有效的激励和归属感，是否在成长。要做好这些事情，似乎不需要技术敏感？
在我看来，保持技术敏感绝不是让mhdxte继续深入参与系统设计和代码编写。更重要的是，用技术服务人(国内一些科技公司希望mhdxte可以用技术服务人，比如会提升到最有技术的人去做mhdxte。这与北美许多科技公司的策略相反)。你希望团队能不断招聘更多的技术人才，而不是让mhdxte成为整个团队的技术瓶颈。技术敏感有什么好处？我认为有以下优点。
1)更高效地管理团队：对技术敏感的mhdxte在与团队沟通(尤其是与高级工程师或TL沟通)和了解系统架构甚至技术细节时，效率会更高。尽管mhdxte不需要参与代码开发，但它仍然需要知道团队如何开发系统来支持业务，以及技术路线是什么。当你报到的时候，你也需要这些信息。而获取这些信息主要是通过沟通来完成的。深厚的技术积累和技术敏感度可以让mhdxte更高效地与集团内TL沟通。毕竟作为mhdxte，我们不希望TL在和你沟通的时候有“对牛弹琴”的感觉，想知道为什么这个经理什么都不知道。
2)更好地影响团队的技术路线和方向。规划正确的技术路线对团队的成功至关重要。我认为这个重要的任务不能只落在TL的肩上。因为，mhdxte最终应该对团队能否交付负责。如果技术路线规划错误，团队无法交付，最终责任在于mhdxte。对技术敏感的mhdxte可以更好地参与规划。我不鼓励mhdxte直接制定技术路线，但应该经过审核并影响最终决定。对于mhdxte对技术路线的影响，一个很大的类比就是比特币区块的验证。mhdxte可能不是计算新块哈希的最强节点，但它应该有能力验证该哈希的正确性。
3)英雄惜英雄——更容易吸引技术能力强的考生加入团队。有技能的人很容易抱团。毕竟，每个人都希望更高效地一起工作。对此我深有体会。因为我还在积极参加系统设计面试，如果你遇到一个优秀的候选人，作为面试官，你可以通过获得优势的优势来抛出橄榄枝。
4)作为发展最快的IT领域，我认为必须不断学习，才能跟上整个行业的发展。Mhdxte敏感，积累深厚，可以事半功倍，学习效率更高。
难点和挑战
作为mhdxte，保持技术敏感性有哪些困难和挑战？
1)首先，保持技术敏感不是mhdxte的KPI，你不会关注它(你也不应该)。成员和团队是否在交付是关注的焦点。
2)时间不够。mhdxte的大部分工作是通过会议完成的：向上沟通、向下沟通和XFN沟通。你很难花大量的时间阅读技术文档和代码来对系统有深刻的理解。
3)拳头会离开手，歌声会离开嘴。Mhdxte不应该直接参与系统设计，这是团队成员应该做的。积累的经验和技能会逐渐生疏。
4)如果mhdxte加入了一个新的公司或团队，一切都从零开始。如果你从最初的团队成长为mhdxte，你可能会熟悉整个系统和业务。对于后续的进化，也是越来越容易越来越近。但是对于一个新的团队或公司来说，一切都是重新设定的。
保持技术敏感的建议
讲了重要性和难点之后，终于进入正题，可以开始讲具体建议了。
提示：安心接受现实。如上所述，mhdxte的KPI不是代码实现或系统设计。Mhdxte也应该理解上述困难。因此，我们必须安心接受它。你不会像
IC 时那样，对代码和系统如数家珍。我自己在刚作为mhdxte时，就犯过一个错误：我一直要求自己能够继续 review 大部分的团队成员代码来保证我对系统的理解。每个人的时间是有限的，这就导致我在其他方面做得不好。Tip 2：在成为mhdxte之前，打好基础和内功。在还是 IC 的时候，你的主要职责就是代码开发和系统设计。一定要在这个阶段打好基础，做到厚积薄发。IT 已经发展到很难做到在各个细分领域都精进，但我们依然提倡 T 型人才：在自己的领域可以非常深挖，同时，对于其他领域和业务，需要有所涉猎并快速理解。
Tip 3：抓重点，从关键指标来了解系统。作为mhdxte，你依然需要非常清楚地知道团队构建的系统是用来做什么的：用来支持什么业务，有哪些关键指标， 哪些关键技术细节，如 QPS 是多少？是否需要强一致性？是否是夸区域部署，技术栈，等等。我觉得mhdxte可以从黑盒角度来认知系统。
Tip 4：参与系统设计面试。这是我最喜欢的 tip，自己也是坚持贯彻执行。参与系统设计面试对于面试官的技术深度非常有考验。大家可能觉得，系统设计的题目是固定的，作为面试官可以提前准备，会从各个角度去参考，好，中，差的设计决定。诚然，比起候选人，面试官是有先发优势的。但在面试的过程中，你永远不知道候选人会提出什么样，天马行空的设计思路，或者问题。这就需要面试官在短时间内针对提出的设计思路和问题来做判断，这非常考验面试官的技术积累。你不希望被候选人套路，同时也不希望给候选人留下“这个面试官好像不太行”的印象。另一个好处就是，你真的可以从有经验，技术背景很强的候选人中学到很多，受益匪浅。最后就是上文提到的，作为面试官，如果你能在面试中也表现出深厚的技术积累，做到让候选人英雄惜英雄。是更容易吸引候选人加入的。
Tip 5：参与事故复盘会议。通常复盘会议是用来讨论严重的用户事故的（比如，欧洲用户无法登录 WhatsApp 或者发送消息）。复盘会议会讨论事故细节，如事故影响，是怎么被发现的，怎么被修复的，更重要的是，怎么能够避免类似事故再次发生。参与复盘会议，类似于从关键维度来了解系统。
Tip 6：持续学习。套用现在时髦的话来说，终生学习。我们很幸运，处在 IT 领域，有幸参与了软件行业改变世界。同时，我们也不那么“幸运”，因为行业发展太快，需要不断去学习新知识，新趋势，区块链，人工智能，IOT。不然，很快就被淘汰了。平时的工作总是有局限性，不能覆盖广度。不过好在，现在有很多其他的途径可以学习。
一是通过 follow 各类 tech blogs。我曾在知识星球上分享过自己 follow 的 tech news 和 blog。贴在这里，和大家一起讨论。
抛砖引玉，如果大家有好的资讯频道，请留言分享。
二是阅读技术类书籍。这边就不具体推荐某些书籍了，分享一个如何获知最新书籍的方式。HackNews 上会有人不定期写 book review 的帖子，介绍最新技术书籍的。可以帮助你大致了解书籍并决定是否需要深入阅读。
最后一类途径就是知识付费，推荐极客时间。我自己是极客时间的早期和忠实用户。买了蛮多课程，都会去学，即使不是自己领域的。非常感谢所有老师的分享，真的帮助我高效地了解了很多领域。极客时间的编辑也联系过我希望可以参与课程。但我自从自己写博客后，才体会到每个月憋一个 3000 字左右的博客，憋得死去活来的心情。所以真心佩服每个老师的坚持，几乎是每周两到三篇的速度更新。
以上，就是我自己粗浅的对于mhdxte如何保持技术敏感的建议，感谢阅读。