---
name: grove-style-leverage-audit
description: 对照安迪·格鲁夫（Andy Grove）在《High Output Management》（中文版《格鲁夫给经理人的第一课》）中提出的以产出衡量管理的观点，审视一位经理一周的时间怎么花：经理的产出等于自己团队的产出，加上受其影响的相邻团队的产出。做法是把每项活动对应到它提升了谁的产出，把绩效差距分成需要培训还是需要激励，按每个人对这项任务的经验决定管得多细，并检查团队的关键结果衡量的是不是产出。经理觉得很忙但团队结果没有起色、自己陷在个人执行工作里、问时间该花在哪里、想审视自己的日程，或者问到管理杠杆、High Output Management、任务相关成熟度（task-relevant maturity）时使用。
---

# 借鉴格鲁夫的管理杠杆审查

以下是安迪·格鲁夫在其著作《High Output Management》中公开阐述的原则，依据本·霍洛维茨（Ben Horowitz）为该书 2015 年版所写序言中的引用和概述，以及约翰·杜尔（John Doerr）的 What Matters 网站对格鲁夫在英特尔推行 OKR 的介绍。本技能与安迪·格鲁夫及其公司无关联，也未获得其认可或背书。这个技能拿一位经理实际的一周，指出哪些活动提升了团队产出、哪些没有，以及最先该改什么。

## 基本规则

- 不得把引用的原话或观点归于安迪·格鲁夫，除非出自所列来源。
- 不得扮演、模仿安迪·格鲁夫，也不得用他的口吻写作；只用下面的原则审视用户的材料。
- 引用格鲁夫的话，只能按所列来源（该序言和 What Matters）的引用方式来引。下列来源里没有的、关于这本书的内容一律不写，不去猜。
- 依据经理真实的日程，或一份写明小时数的活动清单。绝不编造小时数或结果；缺的写 [待确认：……]。
- 谈工作和流程，不谈一个人的品格。“不会做”和“不愿做”是要在谈话中核实的假设，不是标签。
- 下面对活动的分类（团队产出、相邻团队产出、自己干活）是本技能应用这些原则的方法，不是书里的清单。

## 原则

1. **经理的产出就是团队的产出。** 霍洛维茨在序言中说，这本书用一个等式引出管理：“经理的产出 = 他所领导的组织的产出 + 受他影响的相邻组织的产出。”（原文：“A manager's output = the output of his organization + the output of the neighboring organizations under his influence.”）霍洛维茨的解读是：经理的技能和知识，只有在从团队那里获得更大杠杆时才有价值。来源：霍洛维茨，《High Output Management》序言（a16z，2015 年）。
2. **一个人没做好工作的两个原因。** 序言引用格鲁夫的话：一个人没做好工作，要么是不会做，要么是不愿做，所以经理提升个人产出的两种办法就是培训和激励。来源：同一篇序言。
3. **按任务相关成熟度来管理。** 该亲自上手还是放手，取决于这个人在这项具体任务上的成熟度：对新手要手把手培训，对有经验的人要授权。序言引用了格鲁夫的提醒：不要让下属靠犯错来学习，而让客户为这些错误买单。来源：同一篇序言。
4. **培训是上司的工作。** 书的最后一章题为“Why Training Is the Boss's Job”（为什么培训是上司的工作）；序言概括说，不做培训的经理，等于放弃了自己能为产出做的事情的一半。来源：同一篇序言。
5. **一对一面谈是核心工具。** 书中讲会议的部分，从怎样进行一对一面谈开始。霍洛维茨补充了他自己的看法：一对一面谈可能是经理了解组织的最佳信息来源。来源：同一篇序言。
6. **为未来的差距做计划，而不是只盯着今天的。** 序言引用格鲁夫的话：“今天的差距，代表的是过去某个时候计划的失败。”（原文：“today's gap represents a failure of planning sometime in the past.”）来源：同一篇序言。
7. **衡量产出，按季度，与薪酬分开。** What Matters 介绍，格鲁夫在英特尔推行的 OKR 按季度而不是按年度设定，与薪酬分开，只简单评为达成或未达成；格鲁夫最初在英特尔推行 OKR 时，只有挑战型 OKR；网站引用格鲁夫的话：“强调产出，是提高生产率的关键。”（原文：“Stressing output is the key to increasing productivity.”）来源：What Matters，“OKR meaning”“Inputs vs. outputs”“Committed vs. aspirational OKRs”。

## 适用场景

- 经理工作时间很长，团队结果却没有起色。
- 从团队里提拔上来的经理，仍然在做大部分一线执行工作。
- 规划下个季度的日程之前，或团队扩大之后。
- 某个人一再达不到要求，经理不知道该辅导还是亲自接手。
- 不适用于准备某一次具体的一对一面谈（用 one-on-one-prep），不适用于撰写团队 OKR（用 okr-draft），也不适用于交接某一项任务（用 delegation-brief）。

## 需要准备

- 经理一到两周有代表性的日程，或一份写明小时数的活动清单。
- 团队情况：谁向经理汇报、各自负责什么、做了多久。
- 经理的工作会影响到哪些相邻团队，怎样影响。
- 团队这一期的目标或关键结果（如果有）。
- 当前的绩效差距：谁、什么问题、从什么时候开始。

## 步骤

1. **列出这一周。** 每项活动及其小时数：会议、一对一面谈、评审、经理自己的一线工作、邮件、招聘、培训、救火。估算的小时数标 [待确认]。
2. **把每项活动对应到它提升了谁的产出（原则 1）。** 团队产出（帮助你的下属产出更多或更好）、相邻团队产出（帮助你能影响的另一个团队），或自己干活（经理在做团队成员也能做的任务）。有些活动哪一类都不沾，也标出来。
3. **对照成熟度检查自己干活的时间（原则 3）。** 经理亲自做的每项任务：团队里谁能做，他在这项任务上有多少经验？成熟度高：授权给他。成熟度低：不再自己做，改为培训某个人来做。写出人名。
4. **为每个绩效差距分类（原则 2）。** 每个差距：更可能是“不会做”（技能、知识、标准不清楚）还是“不愿做”（动力、优先级、冲突）？写出证据和下一步：不会做就定培训计划，不愿做就谈一次。把这个假设标为 [待一对一面谈确认]。
5. **检查培训时间（原则 4）。** 这周有多少小时用在教或辅导上？如果是零，找出一件只有经理知道、团队又需要的事情，排进日程。
6. **检查一对一面谈（原则 5）。** 这一期谁做过、谁没做过？缺一次，就是经理对团队的了解缺一块。每个人都用 one-on-one-prep 准备。
7. **向前看（原则 6）。** 下个季度会出现什么产出缺口（一次上线、有人离职、业务增长）？如果现在就开始，什么能补上它：招人、培训，还是一套流程？
8. **检查衡量指标（原则 7）。** 团队的关键结果衡量的是不是可以评为达成或未达成的产出？如果列的是活动，标出来，交给 okr-draft。如果有关键结果和某人的薪酬挂钩，也写明。
9. **选出最先做的三项改动。** 最能腾出自己干活的时间、或最能提升团队产出的改动，每项都写明负责人和日期。

## 输出格式

```markdown
# 管理杠杆审查：[经理，团队]（[日期] 这一周）
以下是安迪·格鲁夫公开阐述的原则。本文与安迪·格鲁夫及其公司无关联，也未获得其认可或背书。

## 这一周
| 活动 | 小时 | 提升谁的产出 | 备注 |
|---|---|---|---|
| | | 团队 / 相邻团队 / 自己干活 / 无 | |

**合计：**团队 [h] · 相邻团队 [h] · 自己干活 [h] · 无 [h]

## 要交出去的自己的活
| 任务 | 每周小时 | 谁能负责 | 他在这项任务上的经验 | 授权还是先培训 |
|---|---|---|---|---|

## 绩效差距
| 人 | 差距 | 不会做还是不愿做（假设） | 证据 | 下一步 |
|---|---|---|---|---|

## 培训和一对一面谈
- 本周培训小时数：[h]。接下来要教什么：[主题、教谁、什么时候]
- 这一期没做一对一面谈的人：[姓名]

## 下个季度的缺口
[会缺什么，现在要开始做什么]

## 衡量指标
[衡量产出的关键结果 / 列的是活动的关键结果 / 与薪酬挂钩的关键结果]

## 最先做的三项改动
| 改动 | 负责人 | 期限 |
|---|---|---|

## 使用的原则
[编号，附来源]
```

## 示例

**输入：**“我在一家 40 人的软件公司带客服团队，手下 5 位客服。我的一周：自己回复工单 14 小时，产品会议 6 小时，写帮助中心文章 4 小时，每周团队例会和队列复盘 3 小时，招聘 2 小时，这个月一对一面谈 0 小时（太忙了）。王楠处理账单类工单已经两年；刘洋上个月刚入职，他的升级判断经常出错。产品团队上线的改动，我们往往是先从客户那里听说的。我们的目标是‘回复更多工单’。”

**输出（节选）：**

```markdown
以下是安迪·格鲁夫公开阐述的原则。本文与安迪·格鲁夫及其公司无关联，也未获得其认可或背书。

## 这一周
| 活动 | 小时 | 提升谁的产出 | 备注 |
|---|---|---|---|
| 回复工单 | 14 | 自己干活 | 大多是账单类 [待确认：账单类工单占比] |
| 产品会议 | 6 | 相邻团队 | 如果在会上提出客服的需求，就能避免突然上线 |
| 写帮助中心文章 | 4 | 团队 | 所有客服的重复工单都会减少 |
| 团队例会和队列复盘 | 3 | 团队 | 每周看到整个队列 [待确认：复盘后有什么改变] |
| 招聘 | 2 | 团队 | 团队未来的产能 |
| 一对一面谈 | 0 | 团队（一次没做） | 这个月一次都没有：不了解刘洋和王楠需要什么 |

**合计：**团队 9h · 相邻团队 6h · 自己干活 14h · 无 0h

## 要交出去的自己的活
| 任务 | 每周小时 | 谁能负责 | 他在这项任务上的经验 | 授权还是先培训 |
|---|---|---|---|---|
| 账单类工单 | [待确认：约 8] | 王楠 | 两年 | 授权 |

## 绩效差距
| 人 | 差距 | 不会做还是不愿做（假设） | 证据 | 下一步 |
|---|---|---|---|---|
| 刘洋 | 升级判断经常出错 | 不会做（入职一个月） | 上个月入职；升级判断经常出错（输入） | 两周结对处理升级；一份书面的升级判断清单 |

## 衡量指标
“回复更多工单”是活动计数。交给 okr-draft：改成产出指标，比如首次回复即解决率 [待确认：基线]。

## 最先做的三项改动
| 改动 | 负责人 | 期限 |
|---|---|---|
| 把账单类工单交给王楠 | [经理] | [日期] |
| 和 5 位客服都开始做一对一面谈 | [经理] | 本周 |
| 请产品团队在上线前两天把发布说明发给客服 | [经理] | 下一次产品会议 |
```

## 发送前检查

- [ ] 输出里有出处说明和无关联声明。
- [ ] 每项活动都有小时数（或 [待确认]）和“提升谁的产出”标签。
- [ ] 每项自己干的活都写了人名，并按此人在这项任务上的经验判断授权还是培训。
- [ ] 绩效差距写成附证据的假设，不是对人的定论。
- [ ] 写明了培训小时数和没做的一对一面谈。
- [ ] 检查了关键结果是否衡量产出、是否与薪酬挂钩。
- [ ] 只有三项改动，每项都有负责人和日期。
- [ ] 只按所列来源的引用方式引用格鲁夫。

## 常见错误

- 不问会议改变了谁的产出，就把开会时间算作团队产出。
- 把任务交给对它还很陌生的人却不培训，或者去培训一个早就会的人。
- 把每个差距都当成动力问题。
- 一周一忙，最先砍掉的就是一对一面谈。