走向管理岗的 FDE，先记住这条 30% 法则

每个想往上走的 FDE，都该在显示器上贴一个数字：30%。Camille Fournier 在《The Manager’s Path》中引用了 Patrick Kua 对技术负责人的定义：至少把 30% 的时间用于和团队一起写代码。这是最低要求，不是上限。

假设你是团队里技术最强的开发者，刚被安排在一个客户部署项目上带三个人。这个数字并不妨碍你写更多代码。但 Fournier 说得很清楚：技术负责人真正的工作，是知道什么时候该离开代码，去处理整个团队的需要。这正是这本书值得早读的原因。

一本按阶梯编排的书

《The Manager’s Path》副标题为 A Guide for Tech Leaders Navigating Growth and Change，由 O’Reilly Media 于 2017 年出版，共 244 页（ISBN-13：9781491973899）。它好用，在于编排方式：每章对应工程管理的一个层级，从最简单的形式“带新人”，一直到 CTO。

因此，这本书可以当地图用，不必从头读到尾。先判断自己处在哪一级，读那一章，再读上一级，了解下一份工作会对你提出什么要求。

对前线部署工程师（FDE）来说，这张地图尤其有用，因为 FDE 的晋升路径往往不清晰。今天你可能是某个客户那里唯一写集成的人，半年后也许就要带一个小组，同时给几个客户做部署。这本书并非为 FDE 而写，但书中描述的层级与这段历程高度吻合。

30% 是下限，不是上限

Kua 的基准让技术负责人始终贴近代码。对 FDE 而言，它比许多其他岗位更重要，因为客户想知道某件事技术上能不能做时，第一个问的通常就是你。

一个完全不再写代码的 FDE 技术负责人，很难有把握地回答“两周内能做完吗？”

设想你在一家物流客户那里带三个人的第一周：40 小时。

一种合理的分配：12 小时和团队一起写代码，承担数据管道中最难的部分，或与卡住的同事结对；8 小时做代码评审、帮人解决阻塞；8 小时和一线操作人员在一起，了解他们的流程、做演示；6 小时做架构决策和规划；6 小时用于一对一沟通和指导。40 小时里的 12 小时，正好是 30%。

反过来：你自己写了 30 小时的数据管道。纸面上仍高于 Kua 的标准，但其他所有事只剩 10 小时。评审越积越多，没人和操作人员沟通，两个队友干等着。

这就是 Fournier 警告的失败：不肯离开代码，无法在自己的技术投入和团队需求之间取得平衡。

最难的技能是放下代码

Fournier 写道，一个高效的技术负责人必须愿意离开代码，设法平衡自己的技术投入与团队的需求。这是最难的心态转变，因为让你得到这份工作的技能，恰恰是你现在要少用的技能。

在 FDE 工作中，这种诱惑更强。客户催得紧，截止日期临近，而你知道自己修 bug 比谁都快。

但每次你亲自上阵，队友就少了一次学习的机会，你也失去了一小时本该用于只有你能做的事：帮卡住的人解决阻塞，和客户商定哪些先做、哪些可以等。

一个实用建议：为 FDE 负责人岗位写简历或准备面试时，不要只讲你做了什么。准备好一个故事：你曾有意把一项难活交给别人，你如何支持对方，结果怎样。这个故事说明你已经开始了 Fournier 所说的转变。

该细读哪几章，取决于你所处的位置

2017 年 8 月，一位从业者在书评中称，这是一本讲软件工程领域特有领导问题的好书。这位评论者还认为，本书最大的价值在于管理一个团队和管理多个团队的章节，建议略读前几章。

这条建议适合已经带过团队的人。但如果你从未正式担任过技术负责人，前面关于带新人和技术负责人的章节，讲的正是你即将要做的事。要细读，不要略过。

在管理多个团队这一级，书中描述的经理不再日常编写生产代码，而是通过代码评审保持技术判断力。设想你同时负责两个客户那里的两个 FDE 小组。你的工作变成帮助下面每位技术负责人跟上节奏，并分清哪些事重要、哪些只是紧急。

书末的 CTO 一级离你更远，等接近那一步时再重读最合适。

谁应该先读这本书

这本书最适合三类人：刚被安排在客户那里带小组的 FDE；在个人贡献者路线和管理路线之间权衡的资深工程师；以及为 FDE 负责人岗位招聘或面试、希望有一套共同语言来评估候选人的人。

最有效的读法是对照自己的实际日程。每读一章，就把书中描述和过去一周作比较：写了多少小时代码，交出去多少工作，团队里有没有人从你身上学到东西。

一本 244 页的书不会让你变成领导者。但它让你提前看清下一级台阶的样子，也让你明白：往上走，通常从放手一部分你最擅长的工作开始。