作者背景
Camille Fournier 从软件工程师一路晋升为电商平台 Rent the Runway 的 CTO，后又担任高盛（Goldman Sachs）的 MD（Managing Director）。这本书正是基于她从 IC（个人贡献者）到高管的完整试错经历写成的。她在书中坦言："我主要靠试错学习"，写这本书的目的就是"让其他工程师的转型之路比我自己的更轻松"。
管理能力有清晰的渐进式职业阶梯，每一级都有特定的方法论
Fournier 将技术管理职业划分为 六个层级，每个层级有明确的能力要求、职责边界和常见陷阱：
| 层级 | 角色 | 核心转变 |
|---|---|---|
| 1 | 导师（Mentor） | 首次接触"帮他人成长"，无正式管理权 |
| 2 | 技术负责人（Tech Lead） | 用影响力而非职权领导，约70%时间写代码 |
| 3 | 工程经理 | 正式管理权：招聘、反馈、项目选择、1:1 |
| 4 | 工程总监 | 管理多个团队，重在培训、系统优化和授权 |
| 5 | 大规模团队管理者 | 管理其他经理，培养下属的管理能力 |
| 6 | CTO / VP | 组织级领导力，核心杠杆是文化、战略和组织设计 |
她认为技术负责人不是"写代码最多的人"，而是"让团队写出更好代码的人"。工程经理的1:1会议则是"管理的基础设施"，议程应由下属主导，经理70%的时间倾听。
一、模式识别：六个层级的共性挑战
Fournier 在书中为每个层级都设立了固定的 "Good Manager, Bad Manager" 和 "Assessing Your Own Experience" 板块，像软件工程中的"设计模式"一样，系统性地识别每个阶段的典型陷阱和成功模式。
第一层：被管理者（Management 101）
角色：即使你还不是经理，理解"被管理"是构建自己管理哲学的基石。
| 模式 | 具体表现 |
|---|---|
| "不敢说"陷阱 | 员工对职业发展有诉求但沉默不语——"当你不开心时要说出来，当你卡住时要求助，当你想晋升时搞清楚需要满足什么条件" |
| "只带问题不带方案"陷阱 | 越是资深的 IC，经理越期待你带着解决方案而非纯问题来沟通 |
| "把讨人喜欢误认为管理能力强" | 一个让你舒服的经理 ≠ 一个强有力的经理。Fournier 指出：好感和能力是两个独立维度，你需要的是一个能在关键时刻为你争取资源的经理，而非一个"朋友" |
| "能量变化未被察觉" | 优秀的经理能感知到你精力的异常变化并主动关心——但现实中多数经理做不到，所以你也要学会主动表达 |
共性规律：从一开始，Fournier 就在灌输一个核心理念——职业生涯的主动权在自己手里，"花时间想清楚你想要什么，然后和你的经理一起想办法得到它"。
第二层：导师（Mentor）
核心转变：第一次从"对自己负责"转向"对他人成长负责"，但没有正式管理权。
| 模式 | 具体表现 |
|---|---|
| "保姆式导师"陷阱 | 替新人做完所有事，而非教会他们如何做。好的导师是"脚手架"——提供支撑但最终要拆除 |
| "只教技术不教文化"陷阱 | 新人需要的不仅是代码规范，更需要理解团队的沟通方式、决策流程和隐性规则 |
| "忽视 onboarding 文档"陷阱 | 让新人一边学一边更新文档——"fresh eyes catch gaps"（新鲜的眼睛能发现文档的缺口） |
共性规律：导师角色的核心能力是 "倾听 + 提问"，而非"告诉答案"。这为后续所有管理层级打下了基础——管理的本质不是命令，而是引导。
第三层：技术负责人（Tech Lead）
核心转变：这是全书公认最难的一次转型——你依然要写代码，但同时要开始"让团队写出更好的代码"。
| 模式 | 具体表现 |
|---|---|
| "阿尔法极客"陷阱 | 升为 Tech Lead 后仍要证明自己是团队里技术最强的人——抢最复杂的任务、在 Code Review 中炫技、无法接受别人的方案比自己好。Fournier 的警告很直接：Tech Lead 不是"写代码最多的人"，而是"让团队写出更好代码的人" |
| "流程控"陷阱 | 过度依赖流程来控制一切——强制执行 Scrum 的每一个仪式、要求所有决策都走正式审批。好的 Tech Lead 只把流程当作"减少重复决策的工具"，而非目的本身 |
| "只做技术不做管理"陷阱 | 认为"管理"是经理的事，自己只需关注架构。但实际上 Tech Lead 的核心挑战恰恰是用影响力而非职权来领导——需要说服、协调、调解冲突 |
| "项目管理盲区"陷阱 | 不懂得拆解任务、估算时间、管理依赖关系。Fournier 给出的铁律：每个工程师每季度只有约 10 周的有效工作时间，所有估算翻倍，留 20% 给测试和技术债 |
共性规律：Tech Lead 是**"无权领导"**的极致练习——你必须学会用信任和信誉（而非头衔）来推动团队。这个阶段失败的人，往往是因为不愿从"做事"转向"使能"。
第四层：工程经理（Managing People）
核心转变：第一次拥有正式管理权——招聘、解雇、绩效评估、职业发展，全部落在你肩上。
| 模式 | 具体表现 |
|---|---|
| "微观管理"陷阱 | 管每一个执行细节而非管方向。Fournier 的诊断标准：如果你在下属的 PR 里逐行修改代码风格，你就是在微观管理 |
| "逃避艰难对话"陷阱 | 推迟负面反馈，期待问题自己消失。Fournier 的警告："唯一比收到行为反馈更糟糕的事，是收不到反馈——或者在年终评估时才第一次听到" |
| "救火队长"陷阱 | 到处亲自灭火而非建立防火机制。每次你冲进去亲自解决，你都剥夺了团队学习和成长的机会 |
| "才华横溢的混蛋"陷阱（Brilliant Jerk） | 全书最著名的反模式之一——容忍一个技术出色但破坏团队文化的明星员工。Fournier 用系统性后果来论证：这个人会赶走优秀的人才、扼杀心理安全感、让你在招聘时被迫降低标准 |
共性规律：工程经理的产出不再是代码，而是团队的产出。衡量标准从"我今天写了多少代码"变为"我的团队这个季度交付了什么价值"。
第五层：工程总监（Managing Multiple Teams）
核心转变：从"管人"到"管管人的人"——你的直接下属是经理，而非一线工程师。
| 模式 | 具体表现 |
|---|---|
| "越级管理"陷阱 | 绕过经理直接指挥一线工程师。这不但削弱了经理的权威，也让你陷入自己不该处理的细节中 |
| "信息瓶颈"陷阱 | 所有信息必须经过你才能流动——你成了系统的单点故障。好的总监建立信息流通机制，让团队之间直接协作 |
| "忽视经理培养"陷阱 | 只关注经理们的交付产出，不关注他们的管理能力成长。Fournier 指出，你的核心职责是"培养下属的管理能力"——他们的失败就是你的失败 |
| "只看短期不看长期"陷阱 | 沉迷于本季度的交付数字，忽视了系统升级、技术债偿还、人才梯队建设等长期投资 |
共性规律：总监的核心能力是 "信任 + 校准"——信任经理们的判断，同时通过机制（而非微观干预）来确保方向对齐。
第六层：高管（VP / CTO）
核心转变：你的杠杆不再是代码，甚至不再是直接管理——而是组织、文化和战略。
| 模式 | 具体表现 |
|---|---|
| "CTO 是技术巅峰"的误解 | CTO 不是技术职涯的顶点，而是角色的彻底重构。Fournier 的定义："CTO 的职责是根据现状帮助团队做出最好的技术决策，并高效地实施这些决策" |
| "脱离技术"vs"沉迷技术"的两难 | 完全脱离技术会让你失去判断力，但继续写生产代码会让你忽略组织级问题。Fournier 的建议：通过 Code Review（作为第二审阅人）、调试、事后复盘来保持技术敏锐度 |
| "言行不一致"陷阱 | 当你说"质量很重要"但每次都在截止日期前让团队砍测试——你的行为定义了真正的文化，而非你的宣言。团队效仿的是你做什么，而非你说什么 |
| "忽视向上管理"陷阱 | 高管也有老板（CEO、董事会）。Fournier 强调：即使到了 CTO，"manage up" 仍然是关键能力——对齐期望、不制造意外（no surprises）、用商业语言翻译技术决策 |
共性规律：高管的终极产品是一个能自我运转的优秀组织——你成功的时候，组织在没有你的情况下依然能做出正确的决策。
贯穿六层的元模式
Fournier 识别出了不随层级变化而消失的深层挑战：
┌─────────────────────────────────────────────────────────┐
│ 每一层的成功秘诀，恰恰是下一层你必须抛弃的东西 │
├─────────────────────────────────────────────────────────┤
│ IC 靠个人能力成功 → Tech Lead 靠影响力而非个人产出 │
│ TL 靠深度参与成功 → Manager 靠授权而非亲力亲为 │
│ Manager 靠直接管理 → Director 靠机制而非直接干预 │
│ Director 靠系统成功 → VP/CTO 靠文化和战略而非系统 │
└─────────────────────────────────────────────────────────┘
"Unlearning"（反学习）是全书贯穿始终的核心命题——每一次晋升，你都需要主动抛弃那些让你在上一级成功的习惯。
二、提炼框架：可执行的工具和方法论
Fournier 不是学院派，她的框架全部来自实战——简明、可操作、拿来即用。
框架一：1:1 会议体系（One-on-One）
这是全书着墨最多、最体系化的工具。
两个核心目的
| 目的 | 说明 |
|---|---|
| 建立人际连接 | 让经理走进你的生活——在高压时期，这种连接让你更容易开口求助。优秀的经理能注意到你精力的异常变化，并在乎到主动询问 |
| 创造私密讨论空间 | 一个定期、可预期的安全空间，讨论任何需要讨论的事。议程由双方共享——不是经理单方面主导 |
五种 1:1 风格
| 风格 | 适用场景 |
|---|---|
| 待办清单型（To-Do List） | 聚焦任务进展、阻塞项——适合项目紧张期 |
| 闲聊型（Catch-up） | 非正式的关系建设——适合建立信任的早期阶段 |
| 反馈型（Feedback） | 专门讨论行为和绩效反馈——应定期出现，不能只在出了问题才用 |
| 进展报告型（Progress Report） | 结构化回顾目标和里程碑——适合季度 OKR 对齐 |
| 深度了解型（Getting to Know You） | 深入探讨动机、职业愿景、个人处境——适合新下属加入或关系需要修复时 |
操作细则
- 频率：每周一次，保持规律，可随需求调整
- 时间：每次 30 分钟，避开周一和周五
- 议程：由下属主导（下属准备话题），经理 70% 时间倾听
- 记录：维护一份持续更新的笔记文档，跟踪每次讨论的要点
- 进阶：管理经理时，Skip-Level 1:1（越过下属经理直接和一线员工沟通）是感知组织真实温度的必要手段
框架二：授权与精力管理
Stop / Start / Delegate 审计
Fournier 建议每个周一早上做一次角色自审：
"对你当前的角色做一次 '停止/开始/授权' 审计，然后写一句话：'在这个层级，我的价值现在来自______。'"
这迫使你持续审视：哪些事你还在做但其实不该做了？哪些事你还没开始做但现在是你的职责？
五条授权实操法则
| 法则 | 说明 |
|---|---|
| 用团队目标决定你深挖哪些细节 | 注意力是稀缺资源——只在你关心的、对目标有影响的领域深入 |
| 先查系统，再找人 | 查看仪表盘、指标、项目追踪工具，再决定是否需要打断团队成员 |
| 根据项目阶段调整参与度 | 早期项目可能需要更多参与，成熟项目应放手 |
| 建立代码和系统的标准 | 清晰的标准减少持续监督的需要——标准本身就是一种授权 |
| 对信息公开分享持中性到正向的态度 | 好消息和坏消息都应被欢迎——创造心理安全，让问题尽早浮出 |
任务分类矩阵
用**"简单/复杂 × 频繁/不频繁"**来分类任务，决定授权策略：
| 简单 | 复杂 | |
|---|---|---|
| 频繁 | 自己做 | 授权但建立流程和标准 |
| 不频繁 | 授权作为练手机会 | 作为培养接班人选的训练机会 |
框架三：反馈方法论
反馈铁律
| 原则 | 具体操作 |
|---|---|
| 表扬当众，批评私下 | 当众表扬有双重效果——既肯定个人，又向全队示范什么行为是被鼓励的 |
| 时效性优先于完美时机 | 快速给出反馈永远比等待"合适时机"更有价值 |
| 永远不要让年终评估成为"第一次" | "唯一比收到行为反馈更糟的事，是从未收到——或在年终评估时才第一次听到" |
| 剥离事实和叙事 | "你必须能够说出残酷的事实，同时不把自己的主观臆测加进去"——只陈述观察到的行为和影响，不编故事 |
反馈在 1:1 中的嵌入
Fournier 反对只在绩效季才给反馈。她主张持续反馈文化——将反馈（无论正向还是纠正性）嵌入每周的 1:1 中，让它像呼吸一样自然，而非像手术一样令人紧张。
框架四：重要/紧急矩阵
Fournier 借用了 Eisenhower 矩阵但加上了自己的诠释：
紧急 不紧急
┌───────────┬───────────┐
重要 │ 立刻做 │ 刻意安排 │──→ 战略工作（需要主动保护时间）
├───────────┼───────────┤
不重要 │ 诱惑陷阱 │ 直接忽略 │
└───────────┴───────────┘
她的核心洞察："紧急感往往比重要性更容易被感知"——管理者倾向于用明显的紧急任务替代真正重要的战略思考。因此，重要但不紧急的象限需要你用意志力去刻意保护。
框架五：30/60/90 天入职计划
当有新下属加入时：
| 阶段 | 焦点 |
|---|---|
| 0-30 天 | 熟悉代码库、团队流程、沟通方式。交代管理风格和期望。让新人一边学一边更新文档——这是发现文档盲区的最佳时机 |
| 30-60 天 | 独立承担小任务，开始理解团队目标和大局。建立和同事的关系 |
| 60-90 天 | 能独立交付有意义的特性，开始贡献自己的见解和改进建议 |
框架六：项目估算规则
Fournier 给出了三条硬规则：
| 规则 | 说明 |
|---|---|
| 每个工程师每季度 ≈ 10 个有效的工程周 | 去掉假期、病假、会议、面试、on-call…实际的编码时间远少于你的直觉 |
| 所有估算翻倍 | 当你被问到某个任务要多久时，先给出直觉估算，然后直接乘以 2 |
| 留 20% 给测试和技术债 | 任何项目计划中，必须划出 20% 的时间预算用于测试、调试、技术债偿还——这不是 buffer，这是真实成本 |
框架七：向上管理（Managing Up）
这是一个容易被忽视但 Fournier 反复强调的框架：
| 原则 | 操作 |
|---|---|
| "不意外"原则（No Surprises） | 绝不让你的上级对任何消息（尤其是坏消息）感到意外——主动、尽早、坦诚沟通 |
| "Yes, and" 技术 | 不对上级说"不"。说："是的，我们可以做，而且我们只需要推迟另一个项目就行"——把拒绝变成资源置换的讨论 |
| 翻译技术为商业 | 向上汇报时，用商业影响说话，而非技术细节 |
框架八：领导力杠杆层级图
Fournier 用一张渐进式杠杆转移图来总结全书框架：
层级 主要杠杆 技术参与形式
─────────────────────────────────────────────────
技术负责人 个人技术 + 影响力 写代码（~70%）
工程经理 团队产出 写代码（偶尔）
总监 多个团队的协调 Code Review
VP 组织架构 + 人才策略 系统设计评审
CTO 文化 + 战略 + 技术愿景 技术决策指导
全书框架的核心设计思想
Fournier 构建这些框架时有一个底层逻辑：
"这些工具单独看都很朴素——1:1、反馈、授权、计划——但当你持续一致地使用它们时，它们的复利效应是巨大的。"
这跟她的论证风格一脉相承：不追求理论的华丽，而追求持续执行带来的复利。框架的价值不在于它的独创性，而在于她把每个框架放在了正确的层级、正确的场景中，并告诉了你在那个场景下最容易犯的错误是什么。
Q：管理的七阶段路径 是什么？
一、《The Manager's Path》的七阶段路径
这本书的完整结构就是按这七个阶段组织的，每章对应一个阶段：
阶段1：Management 101 — 被管理者
对象： 刚入职或还不需要做管理的个人贡献者
核心： 在被管理的过程中学会识别"好的管理"和"不好的管理"
关键能力：
- 学会规划和利用 1:1 会议——agenda 由你掌握，不是等着老板想起你
- 理解 feedback 的流向：公共场合 praise，私下场合 criticism
- 学习"什么值得汇报、怎么汇报"
- 一个好的经理会在你正常能量水平改变时注意到并主动问你
Fournier 的实际建议：
"When a manager notices your normal energy level changes, and will hopefully care enough to ask you about it."
经典案例： 她提到一个情景——当一个工程师开始不说话了、抱怨多了、或者突然效率下降了，好的经理会主动问，而不是等到绩效评估时才提。这一段被无数读者公认"写得太真实了"。
阶段2：Mentoring — 当导师 / 带新人
对象： 开始负责培养其他人的高级工程师
核心： 从"自己做好"到"帮助别人做好"
关键能力：
- 学习型：理解新人的技术背景和能力（Entry level / Senior level）
- 引导式： 不是给答案，而是给方向和方法论
- 渐进式接管： 从完全监督走向完全放手
- 设定清晰的边界： "你的代码我不改，永远。我只给 review 和方向。"
- 关注新人的情绪状态——"新员工第一周最重要"
实际方法论：
- 设定明确的 milestones
- 把越级（asking 解决）变成逐级的
- 让新人有权拒绝你
阶段3：Tech Lead — 技术主管
对象： 被正式定位为技术负责人
核心转变： 从写代码到引导架构决策和团队输出
关键能力：
- 不是完全脱离代码，但必须学会让别人写
- 学会："你不再是一个人写所有的代码"
- 学会制定技术路线、参与架构设计
- 在项目中代理经理做技术决策
Fournier 的重磅论断：
"Many people who are a director of engineering in name are something closer to a tech lead in practice."
- —意味着很多人名义上已经升上去了，但心智和行为还停留在 Tech Lead 阶段。
实际戒律：
- 不要做"瓶颈"——所有决策经过你才通过就是瓶颈
- 学会**写 RFC（Request for Comments）**而不是口头决定——让团队参与技术决策
- 心态转变：项目失败的责任在你，不是"新人写得慢"。
阶段4：Managing the Team — 第一次做管理
对象： 第一次正式带团队，有直接报告
核心： 从"自己动手"到通过他人取得结果
关键能力：
- 授权：授权 = 授权资源 + 授权权力
- 对团队的结果负责——不再是自己做出代码，而是团队交付的项目
- 处理绩效问题、晋升推荐
- 学会招聘和解雇
Fournier 的核心预警：
"You are no longer measured by what you produce. You are measured by what your team produces."
实际建议：
- 要有自己的 1:1 结构来了解团队成员状态
- 设立明确的目标（不是"写好代码"，而是"交付某个 feature"）
- 学习不同的领导风格（coaching / directing / delegating）
阶段5：Managing a Manager — 管理经理
对象： 升级到带 managers 的经理
核心： 从管理单个工程师，到帮助管理者成长，再通过他们管理更大范围
关键能力：
- 无法再直接接触一线的技术和细节——必须接受信息过滤
- 学会通过 manager 来诊断团队问题
- 培养 managers 的独立决策能力
- 管理 managers 的精力分配和成长轨迹
阶段6：Managing a Tech Organization / Director of Engineering
对象： 技术总监级别
核心： 跨团队、跨项目、对齐业务目标
关键能力：
- 在组织层级之上做文化塑造
- 诊断团队间的协调问题
- 设定工程文化和工程标准
- 能够看到"哪里不是代码问题，是组织问题"
阶段7：Senior Leadership / CTO / VP of Engineering
对象： 最高技术领导者
核心： 在组织层级之上做文化塑造与战略
关键能力：
- 制定公司的技术战略和组织设计
- 从运营角色转向战略角色
- 让工程团队真正理解业务目标并主动对齐
二、Fournier 的管理维度
维度1：从"被管理"学会"管理"
"每个人在管理之路的第一站，总是在桌子的另一边，即：被管理者。"
当一个好的被管理者，才能识别欺骗你的经理、识别让你放弃的经理。
维度2：从"做"到"让别人做"——心态转变
"Your job isn't to write the code. It's to make sure the code gets written."
这是整本书最核心的一句话。
维度3：从"直接监督"到"间接管理"
表格
| 阶段 | 管理方式 |
|---|---|
| Tech Lead | 技术监督+指导 |
| Manager | 人员管理+授权 |
| Director | 系统设计+组织设计 |
| CTO | 战略+文化 |
维度4：从"管事"到"管人"
- 初级：关注项目
- 中级：关注人+项目
- 高层：关注组织+方向
扫一扫
456
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
