工程师转管理：五个坑与五项基本功

从 tech lead 到 engineering manager 不是晋升，是换职业。最大的坑是继续用写代码的方式做管理：亲手修关键路径、用代码评审代替反馈、把 1:1 当站会开。

五个坑 → 五项基本功

1. 1:1 当站会开（或一忙就取消）

坑：一对一变成项目进度同步会，或者忙起来第一个被牺牲。

基本功：1:1 是下属的会，不是你的会。议程由对方主导，谈障碍、成长、困扰；项目同步用别的方式。固定节奏不取消——连续取消传递的信号是"你不重要"。

来源：Andy Grove《高产出管理》；Camille Fournier《The Manager's Path》

2. 反馈绕弯子（或只给技术意见）

坑：怕伤人，反馈裹三层棉花；或者只谈代码不谈行为。

基本功：开口先标明"这是反馈"。及时、具体、针对行为而非人格。绩效面谈的原则是 no surprises——如果下属在正式面谈第一次听到负面评价，是日常反馈的失职，不是面谈的问题。

来源：Kim Scott《Radical Candor》（彻底坦率）；First Round Review 述及的业界实践

3. 名义授权，实际逐行改

坑：任务交出去了，代码评审时还是按自己的实现逐行纠正；关键路径忍不住自己写。

基本功：授权交出的是结果与边界（做成什么样、哪些不能碰），不是实现步骤。按任务成熟度收放：新人给结构化指导，资深人给目标和自由度。转管理后要有意识退出关键路径代码——你的可支配时间碎成了 30 分钟粒度，写关键路径代码是给团队埋雷。

来源：Grove《高产出管理》任务相关成熟度；Charity Majors "The Engineer/Manager Pendulum"

4. 排期落后就加人、自己下场救火

坑：进度告急时的两个本能反应都是错的。

基本功：先诊断再开药——落后原因是估算乐观？依赖阻塞？还是团队状态（士气/缺人/被打断）？布鲁克斯《人月神话》的核心教训仍然成立：向已延迟的项目加人会先更慢（培训与沟通成本）。向上沟通时说清取舍（"要如期交付可以，砍 X 或加 Y 的缓冲"），而不是承诺一个自己不信的日期。

来源：Fred Brooks《人月神话》；Will Larson《An Elegant Puzzle》

5. 向上只报喜（或等被问）

坑：坏消息捂到捂不住；好消息不主动说，指望老板自己看见。

基本功：向上管理的本质是对齐期望与管理信息流。坏消息早报（带着分析和你建议的应对，而不是只丢问题）；好消息结构化地报（成果 + 可复制的原因）。定期让老板知道你在推进什么，避免"消失三个月然后惊吓"。

来源：Gabarro & Kotter《Managing Your Boss》（HBR 经典）

证伪清单：被放弃的流行实践

这些管理实践曾被广泛推崇，一线实践已证伪或大量放弃——别把"流行"当"正确"：

实践	证伪证据
强制排名 / 活力曲线	微软 2013 年放弃 stack ranking（被广泛归因为内部协作毒性），GE 也已放弃活力曲线；把同事变成对手
开放办公室	哈佛 2018 年实地研究：开放式工位后面对面互动反而下降约 70%
Holacracy（合弄制）	Medium 等公司公开放弃；用治理仪式替代一线管理，抽象层级没有消失只是换了名字
长期 player-coach	长期同时做 IC 和 manager 两份全职工作，实践共识是不可持续；要么阶段性切换（pendulum），要么承认是两份工作
用公开站会/永远开门代替 1:1	群体场合下属不会暴露真实障碍；1:1 的私密性是功能不是形式

给自己的锚点

• 转管理后的第一个月：把关键路径代码移交给具体的人（写进移交清单）
• 1:1 备一个共享文档，对方填议程；连续两次空议程本身就是信号
• 每次反馈后自问：这算"彻底坦率"还是"虚假善意"？

来源

• 著作：Grove《高产出管理》、Fournier《The Manager's Path》、Scott《Radical Candor》、Brooks《人月神话》、Larson《An Elegant Puzzle》
• 文章：Kotter & Gabarro《Managing Your Boss》(HBR)、Charity Majors 博客
• 证伪清单经 L3 检索交叉验证（2026-09），标注为业界共识级线索