FDE Times 数据在招 FDE 职位 862▼55 近 7 天在招职位数的变化(同口径比较):不计入本周新开始追踪的公司的职位近 7 天新增 70在招公司 180支持远程 24%美国薪资中位数 $200k招聘最多 Palantir 95
ENVI

前线部署工程师(FDE)的专业媒体

书籍与课程

团队越大越慢?新晋 FDE 负责人该读这本书

Will Larson 的《An Elegant Puzzle》不给现成配方,而是教新负责人把团队当作系统来画、量、修。

封面: An Elegant Puzzle: Systems of Engineering Management
An Elegant Puzzle: Systems of Engineering Management · Will Larson · 封面图片:Open Library
分享微博

要点速览

  • Will Larson 著,2019 年由 Stripe Press 出版,面向已有一定带队经验的人,而非完全的新手。
  • 核心是系统思维:把团队看作存量与流量,把结构化原则与对人的关注结合起来。
  • 内容密度高,更适合大型组织;按问题查阅,不必从头读到尾。
一个三人 FDE 团队的斜率图。调整前:每周进来 6 个需求、关闭 5 个,十周后积压增加 10 项。在需求调研阶段筛选后:每周进来 4 个需求,仍关闭 5 个,积压每周减少 1 项。
流入从 6 降到 4、流出保持 5 时,积压开始减少,无需任何人加班。来源:文中示例,基于 Will Larson 在《An Elegant Puzzle》中的存量流量思维。

优秀的 FDE 常常会得到一种很少有人提前准备的“奖励”:更多的人。昨天你还在亲手为客户写数据管道,今天你手下有三名工程师、两个并行的项目,还有一个任何技术文档都回答不了的问题:为什么团队越大,干活反而越慢?

Will Larson 的《An Elegant Puzzle: Systems of Engineering Management》没有为这个问题提供现成公式。它给的是一种思考方式,让你自己找到答案。这本书 2019 年由 Stripe Press 出版,Larson 曾表示,整理成书花了他大约一年时间。

对即将成为负责人的前线部署工程师(FDE)来说,这本书的价值不在管理技巧,而在于把“团队超负荷了”这类模糊的抱怨,变成一个可以画出来、量出来、修得好的系统。

这本书到底讲什么?

Stripe Press 将这本书定位为对工程管理典型问题的回答:如何处理技术债,如何确保团队里每位工程师以合适的节奏成长。出版方认为,Larson 的方法在结构化原则与以人为本的思考之间取得了平衡。

根据 Gergely Orosz 在 The Pragmatic Engineer 上的书评,全书分为六部分:Organizations、Tools、Approaches、Culture、Careers 和 Appendix。其中 Appendix 提供了在三个层级管理组织的工具:一线经理、中层经理和管理者的管理者。

Orosz 称,对已有一定经验的工程领导者而言,这是他所知最好的资料。值得留意的是这句话的后半句。如果你从没带过人,也从没为别人的结果负过责,很多章节读起来会像纯理论。

观点一:团队是由存量和流量构成的系统

Refactoring 通讯的作者 Luca Rossi 认为,系统思维是这本书的核心:把每个系统都看作存量与流量。存量是不断累积的东西,流量是它流入或流出的速率。

设想一个三人的 FDE 团队。存量是等待处理的客户集成需求清单。每周新进 6 个需求,团队关闭 5 个。没人偷懒,也没人能力不足,但十周后积压多了 10 项,客户开始抱怨。

刚晋升的负责人,第一反应通常是陪团队一起加班。系统思维逼你换个问题:是该减少流入(在客户需求调研阶段筛掉一部分需求),还是该增加流出(把集成中重复的部分自动化)?

算一算。假设在需求调研阶段,你能从每周 6 个需求中筛掉 2 个与客户目标无关的需求。流入降到 4,流出仍是 5,积压每周减少 1 项,十周就能清掉多出的 10 项,而且没人需要加班。

最常见的错误是只盯着存量。负责人汇报“积压有 10 项”,却不知道每周进多少、出多少,因此说不出情况何时会好转。积压数量只告诉你现在在哪里,两个流量数字才告诉你正往哪里去。

到客户现场后的第一件事,是先统计过去四周的这两个数字,再决定是否承诺更多。

观点二:技术债与人的成长是同一个问题

Stripe Press 用来介绍这本书的两个问题,技术债和每位工程师的成长节奏,听上去是两个话题。对 FDE 来说,二者紧密相连:在客户现场仓促写下的代码会产生技术债,而总在修这些债的工程师会停止学习。

从 Larson 将结构化原则与对人的关注并列的思路中,新负责人可以得出一个简单习惯:每次分配工作时,问一问它是在偿还技术债、为客户创造新价值,还是在帮助接手的人成长。

好的任务分配至少应满足其中两项。如果某位工程师连续三个月只拿到修 bug 的活,“他是否以合适的节奏成长”这个问题,你已经有答案了。

观点三:招聘、评估和留人都是需要学习的技能

书中的 Careers 部分涵盖招聘、绩效评估、晋升和留人。对习惯用交付的代码和满意的客户来衡量自己的 FDE 来说,这些全是新任务,而且没有一项能单靠技术能力做好。

从职业发展看,这也是你能脱颖而出的地方。阅读 FDE lead 或 engagement lead 岗位的招聘信息时,留意“mentor”“hiring”“grow the team”这类字眼。简历上写“带教 2 名工程师,六个月后两人均能独立负责项目”,远比“领导力强”更有说服力。

谁该读,按什么顺序读?

Rossi 指出,这本书对大型组织中的经理和技术负责人最有用,小团队可能会发现并非每一章都适用。他还提到,内容极为密集丰富,更适合作为参考书,而不是一口气读完。

由此得出的建议相当明确。如果你在一家创业公司,带着五人的 FDE 团队,先读 Careers 部分和存量流量思维,Organizations 和 Appendix 留到团队扩大后再看。如果你在大型组织,Appendix 及其三个管理层级能帮你理解你上级的上级在担心什么。

如果暂时不想买书,Orosz 提到,Larson 在写作期间把各章草稿发在了他的 Irrational Exuberance 博客上。针对你正卡住的问题读一篇文章,是判断这本书是否适合你的最低成本方式。

“为什么团队越大越慢?”这个问题会在职业阶梯的每一级重新出现。一个疲惫不堪的负责人和一个从容的负责人,区别往往在于谁在问题压到头上之前,就练过把系统画出来。

这篇文章对你有帮助吗?

4 个信源
路线图上的下一篇 · 阶段 7: 项目主导项目已经延期,再加两名工程师只会更晚按《人月神话》中 Fred Brooks 的算法,团队从四人增至六人,沟通渠道从 6 条增至 15 条。