![不想当"资源"，他离开 Yelp 转而培训工程师经理](https://wuaishare-1300215870.file.myqcloud.com/wp-content/uploads/2026/07/20260731011126846.jpg!wuaishare "不想当"资源"，他离开 Yelp 转而培训工程师经理插图")
你是否曾被上级称为"优秀资源"？这个措辞让 Ryan Murphy 很不舒服，却困扰了他很久。正是这个契机，促使他辞去 Yelp 工程经理的职位，转而创办了 EM Accelerator——一个专门培训工程师经理的项目。
Ryan 的经历背景： 在创办 EM Accelerator 之前，他在 Yelp 担任工程经理五年，负责 owned purchasing infrastructure（采购基础设施）团队。这些系统直接处理客户付款，并同步向华尔街报告财务数据。回顾整个职业生涯，Ryan 自述"命运注定我要带领他人"——早在他第一次管理一个人的时候，那便是他每周最享受的事。
他创办 EM Accelerator 的核心理由很简单：从未见过有人在公司 HR 内部课程之外接受过真正意义上的管理培训。 但我们却不断将他人职业发展的直接控制权交给一批批从未受过训练的人，团队为此付出的代价，就是这种教育的缺失。
1. 工程师最常高估什么？
Ryan 在职业生涯中花大量时间打磨技术能力，一度渴望成为技术负责人（Tech Lead），认为只要证明自己是团队中技术最强的工程师，下次晋升机会就非自己莫属。
现实是： 到了高级 IC 层级，技术能力只是默认前提。真正决定你能否晋升的，是以下三点：
- 赋能力度：你能让周围多少人变得更强？
- 杠杆效应：你是一名称职的执行者，还是能够放大团队产出的人？
- 高期望 + 低权威 的平衡力：你能否在正式权力有限的情况下，仍驾驭高期待？
2. 管理者实际如何评价工程师？
Ryan 直言，评价维度因级别而异，并非只看技术产出。
各层级工程师的考察重点：
| 层级 | 管理者真正想看到的 |
|---|---|
| 初级（Junior） | 对学习和成长的主动性——不是被逼着进步，而是自己驱动自己 |
| 中级（Mid-weight） | 主动识别项目潜在障碍，以及成为他人的教练和导师 |
| 高级（Senior） | 超越自身角色的视野——不是冲在最难的任务前线，而是能领导其他 TL 推进这些任务 |
关于直属上级的一点坦诚： Ryan 承认，管理者本身的能力差异也会极大影响评估结果。他曾遇到管理者"只要我的想法和做法与他们不一致，就什么都不对"。反过来，如果遇到真正关心你成长的上级，主动让他们知道你在充分利用这段关系——"他们会非常欣赏这一点"。
![不想当"资源"，他离开 Yelp 转而培训工程师经理-图片1](https://wuaishare-1300215870.file.myqcloud.com/wp-content/uploads/2026/07/20260731011851569.jpg!wuaishare "不想当"资源"，他离开 Yelp 转而培训工程师经理插图1")
3. 管理改变了对"好工程"的定义吗？
这个问题常常让听到的人感到不适，因为答案相当直接：
没有人是在为你的完美重构函数付钱。他们付的是你帮他们节省了多少秒客服通话时间。
Ryan 的观点很明确：从 IC 到管理者的视角转换，核心在于从"代码质量"转向"业务结果"。架构漂亮、生产环境运行良好、但用户感知不到价值——这在管理层眼里，不是好工程。
4. 哪种工程师最容易获得晋升？
Ryan 观察到，那些快速晋升的工程师有三个共同特征：
- 沟通风格自适应：能够根据受众调整表达方式，面对工程团队讲架构逻辑，面对业务方讲商业价值，从不只用一种语言对待所有人
- 把干系人更新当调试一样严肃对待：不是被动等待被问，而是主动、定期、清晰地同步进展
- 故障期间是团队的定海神针：关键时刻能稳住节奏、传递准确信息的工程师，管理者会看在眼里
5. 送给中级的自己的一句话
Ryan 对过去的自己只说了一句建议，却相当具体：
去跟销售坐三天，去跟客服坐两天。
一位 CTO 曾将这条写进自己的职位描述，彻底改变了他的职业生涯。理解销售怎么思考、客服听到什么，能让工程师对"代码最终服务谁"这件事建立真正的体感。
6. 管理者最常见的失误
Ryan 毫不客气地指出：
很多 PIP（绩效改进计划）实际上是由无法及时给出反馈的管理者制造出来的。
典型模式是：硬对话被推迟两周 → 两月 → 最终变成一纸 PIP。"把难开口的对话往后拖"看似保护了关系，实则剥夺了工程师及时调整的机会，最终积重难返。
7. 如何判断管理是否适合你
Ryan 的建议非常实际：先去试试 Tech Lead。 这是技术行业中最难的角色之一——没有正式授权，却要推动结果；之前帮你爬上来的那些技术能力，在新岗位上的直接作用极为有限。如果做 TL 时你感到痛苦，那管理者岗位大概率不会让你更快乐。
8. 为什么离开 Yelp
Ryan 透露，离开 Yelp 时正值他母亲去世不久，这段丧亲之痛反而给了他"押注自己"的勇气。
贯穿他整个职业生涯，始终有三件事让他困扰：
- 管理者从未受训
- 职业发展停滞
- 团队缺乏心理安全感
这些问题促使他最终决定，既然行业不解决，就自己动手。
工程师的终极命题：交付业务价值
行业残酷的真相是：你的存在就是为了交付业务价值，这是底线，高于一切。没人关心你是否把一个庞大的功能打磨成完美的工程杰作；他们关心的是这是否让客服团队将平均等待时间缩短了 40 秒，从而提升客户满意度，并为一个客户的生命周期价值增加 450 美元。这里我刻意表述得有些直白，目的是强调一个观点：优秀的专业软件工程师能够长期平衡业务需求与技术要求，不会把摊子留给后面的开发者时比接手时更烂。
9. 在 Yelp 负责可靠采购团队：直接金钱损失的教训教会了你什么？
我们团队负责的基础设施不仅要处理资金流转，还要及时、准确地向华尔街汇报。一旦出错，真的——毫不夸张——可以在一夜之间毁掉一家公司。因此这是一个极其严肃的领域。
"交付工完作"（"我机器上能跑就行"）与"对结果负责"（"将产品 X 采购的 MTTR 降低 12%，以达成 Y 结果"）之间存在巨大差距。
但问题并不全在工程师身上——环境塑造人。一个工程师可能处于这样的团队：工单上只写着"通过创建索引来加速数据库写入，blabla"，他们没有太多话语权，也不够安全到能获得更多自主权。而另一个极端的团队收到的信息是："产品 X 的 MTTR 为 Y，这给某类客户群造成了 Z 问题"。然后由团队自己迭代解决方案——从小的代码优化到事件驱动的架构重写，再到增设可用区。
10. 团队里哪种工程师最容易在晋升和校准讨论中获批？他们做对了什么？
我团队中最容易获得晋升的工程师，是那些懂得如何沟通进展的人。他们深谙如何针对不同受众调整信息——改变消息本身、详略程度，以及需要额外补充的上下文，并把"保持相关方更新"这件事看得与"发现下一个技术执行障碍"同等重要。
此外，是那些在危机时刻展现出领导力的人。比如遇到高优先级故障时：他们的响应让所有人保持信息同步、任务流向正确的人——这有多可见？
11. 如果穿越回中级工程师阶段，你会给当时的自己发一条什么消息？
去其他部门花点时间。我曾有一位 CTO，直到我成为高级工程师才有机会与他共事。他以前真的把"跨部门工作"变成员工工作的一部分——不是兼职，而是专门的职责。比如，我必须去销售部门待 3 天，了解我们使用的客户声音；必须去客服部门待 2 天，了解客户痛点。从那以后，无论在哪里工作，我都尽量坚持这样做。这是被低估但真正能让人快速成长的建议之一。你获得了曝光度，但更重要的是，你获得了那些整天埋头技术的人永远不会得到的领域知识。这让你价值提升 10 倍。
12. 你希望让工程领导更有思辨性、更有温度。管理者最常在哪里辜负工程师？
管理者最普遍的失职在于：不及时给予反馈，回避艰难的对话。他们对自己说："我再等两周，会自己好转的。"然后一拖就是两个月。到那时候问题已经严重得多。如果一出现信号就开口谈话，对工程师来说纠正起来要容易得多，而不是拖到两个月后。你不找他谈话不是对他好，而是在害他。我见过的 PIP（绩效改进计划）中，很大一部分源于管理者薄弱的反馈技巧。
![不想当"资源"，他离开 Yelp 转而培训工程师经理-图片2](https://wuaishare-1300215870.file.myqcloud.com/wp-content/uploads/2026/07/20260731011859946.jpg!wuaishare "不想当"资源"，他离开 Yelp 转而培训工程师经理插图2")
13. 很多工程师转管理是因为觉得这是唯一的晋升路径。应该如何诚实检验自己是否适合？哪些人应该远离？
第一点需要明白的是：进入工程管理不是晋升，而是转行。如果你想往上走，可以走技术负责人、Staff 工程师、Principal、Distinguished 工程师等路径。不应该因为觉得管理是"更进一步"而去做管理者——这是最快后悔人生选择的方式。这是转行，你学到的技能相当于从头再来、全新的学习曲线，你没法再依赖那些帮你走到今天的技能。
我判断一个人是否适合的真实测试是：先去体验技术负责人这个角色。这个角色，在我看来，是科技行业最难的岗位之一。期望极高，却没有正式授权。工程管理者同样面临高期望，但他们至少有权威做后盾。先练习做一个好的技术负责人：赋能他人、认识到你本人无法 scale、团队才能 scale、永不动 mentee 的键盘等。
新晋技术管理者的困境：为什么"晋升"反而成了团队的负担
问题根源：管理者在工作中学习，团队首当其冲
刚晋升的管理者往往缺乏必要的培训，团队为此付出的代价最为直接。以下是几种典型场景：
- 技术 leader 放不下 IC 角色：管理者紧握"关键路径"上的任务不放，团队成员困在执行层，职业发展受阻。
- 心理安全感缺失：新晋管理者误以为"职位"等同于"领导力"，但团队继续配合仅仅是因为你的头衔，而非真正的信任。
- 工程师成为"资源"而非人：曾有工程师在入职第一天就被管理者直言"永远记住，你在这里是一种资源"——这种工具化的定位，从一开始就为后续的管理失当埋下隐患。
一本写给所有工程师的"避坑手册"
《软件工程法则》（The Laws of Software Engineering）正是为了解决这个信息断层而诞生的。作者在科技行业从业超过 20 年，反复观察到同样的问题在不同技术栈和团队中反复出现，于是开始系统记录这些规律。
书的结构：
- 共 56 条法则，涵盖架构（Architecture）、人员（People）、时间（Time）、质量（Quality）、规模（Scale）、代码（Code）与决策（Decision-making）七大维度。
- 每章围绕一条法则展开，说明其含义、出处、适用场景以及在实际项目中的具体表现。
- 部分章节还关联了其他经典管理概念，如"双披萨规则"（The Two-Pizza Rule）、"眼镜蛇效应"（The Cobra Effect）和"冒名顶替综合征"（Impostor Syndrome）。
该书由 Thoughtworks 前 CTO Dr. Rebecca Parsons 与 Google Cloud AI 工程总监 Addy Osmani 撰写序言，另有 20 位来自 Google、Amazon、Uber、Oracle、Yelp、Nutanix、CodeScene 等公司的工程师和领导者参与审校。
适合放在工位旁随时查阅——当项目遇阻或团队出现摩擦时，对照目录查阅对应法则，往往能快速定位问题根因。
工程管理是一次职业转型，而非一次晋升
这是本书专访嘉宾 Ryan Murphy 在访谈中传递的核心观点。他指出：大多数工程师得不到晋升，不是因为技术不够强，而是因为没有遇到懂得为其发声的 manager。反馈被延迟、被稀释，甚至被忽略——这对工程师的成长而言是一种慢性伤害。
而那位在他入职第一天就告诉他"你是一种资源"的 manager，恰恰印证了他后来在 EM Accelerator 中试图解决的问题：不应让团队来承担管理者"在工作中学习"的代价。
评论