新任/在任管理者用 Grove《高产出管理》把管理时间转成团…

当你带团队、排管理日历、设计指标、开 1:1、做委派、跑规划或准备绩效评审时，用这套方法把「忙」变成「组织产出」。

适用场景

解决思路

1. 【核心】把管理者的产出定义为「自己的组织产出 + 受自己影响的邻近组织产出」；对每件可做的事反复问「哪个每单位时间产出最高」，只做高杠杆活动，砍掉负杠杆活动。
2. 【生产原则】先找限制步骤（limiting step）：找出最长、最难或最贵的阶段（常见是 code review、staging access、某个过载的专家），其余一切围绕它排期。
3. 【生产原则】在最低价值阶段修缺陷：在 spec review 就杀掉有缺陷的设计，而不是在上面建了三个 sprint 之后才改。
4. 【生产原则】把 setup 成本高的工作批处理：interviews、code reviews、打断处理都成批做，摊薄准备成本。
5. 【生产原则】承认大多数知识工作是 build to forecast 而非 build to order：按预测配置流水线产能并接受可控风险（如 toast 在客户下单前就烤上）。
6. 【生产原则】你不可能盯住所有工作：把工作当黑盒，只用少量指标开几个观察窗。
7. 【指标】度量产出而不是活动：数「上线后仍存活的功能、被解决的问题」，而不是代码行数、工时、触碰的 ticket 数。
8. 【指标】每个数量指标上线前必须配一个质量指标：deploys/week 配 change-failure rate，ticket closes 配 reopens，velocity 配 incident count。
9. 【指标】优先用领先指标（review queue age、build flakiness、on-call page rate）在产出下滑前预警，并用趋势指标把产出与自身历史对比。
10. 【指标】用 stagger chart：每期对同一时间范围重新预测，纵向读一列即可看出预测是诚实、乐观还是在压数。
11. 【指标】行政工作也按工厂方式度量：offers per recruiter-week、invoices processed per day，并始终配上质量指标。
12. 【杠杆】列出并消除负杠杆行为：对专家做细节性 meddling、卡住别人等待的 waffling、以及经理外露的 gloom，都会向下放大。
13. 【杠杆】优先委派自己最熟的任务（监控成本最低给自己）；但委派必须带监控，没有监控的委派是 abdication。
14. 【杠杆】在任务层面而非人的层面监控：像来料检验一样抽样，task-relevant maturity 低时抽查更密，TRM 升高后逐步放松。
15. 【杠杆】预测自己的限制步骤：先把 1:1、staff meeting、review、planning 放上日历，让打断去填空隙，而不是反过来。
16. 【杠杆】把负载保持在 100% 以下；提前说 no 比晚点交付失败更便宜。
17. 【杠杆】用 office hours 和已知检查点批处理打断，避免碎片化 maker time。
18. 【会议】让 process-oriented meetings（1:1、staff meeting、operation review）按固定节奏运行，占据大约四分之一日历，并承载大部分管理工作。
19. 【会议】1:1 是下属的会议：由下属拥有并带来议程，主管只负责听、了解真正发生了什么。
20. 【会议】按 task-relevant maturity（而非资历或亲疏）设定 1:1 频率：新接任务者每周一次，老手每几周一次，绝不低于每月一次。
21. 【会议】双方各维护一份 hold list，把非紧急事项攒到下次 1:1，借此批处理打断。
22. 【会议】主管写记录：把商定的行动写下来，以表明承诺并强制后续跟进。
23. 【会议】议程走完后追问一句「one more thing」——真正的问题常在最后五分钟浮出水面。
24. 【会议】staff meeting 做成 controlled free discussion，经理充当苏格拉底式提问者而不是讲师。
25. 【会议】反复出现的「ad hoc」会议要转成 process meeting；当 ad hoc mission-oriented 会议吃掉超过约四分之一管理时间，就是 malorganization 的信号。
26. 【决策】让决策走完三段：free discussion（所有观点上桌、欢迎异议）→ clear decision（越有争议越要写得干脆）→ full support（disagree and commit）。
27. 【决策】把决策放在最低胜任层级，离最新技术知识最近。
28. 【决策】用 peer-plus-one 打破 peer-group syndrome：房间里放一位被授权拍板的资深者。
29. 【决策】任何决策会前先答六问：什么决策、何时决、谁来决定、咨询谁、谁批准或否决、通知谁。
30. 【决策】当没有一个人同时具备技术与判断时，把最新技术知识与最强组织判断配对。
31. 【决策】不要悄悄反转决策（那是 waffling）；基于新事实公开反转才是管理。
32. 【OKR】用 MBO/OKR 回答两个问题：我要去哪（objective），以及我如何给自己配速以确认在前进（key results）。
33. 【OKR】目标保持少数、KR 可度量到无需争论；级联时让上一层的 KR 成为下一层的 objective；绝不把 OKR 机械地绑到薪酬公式上。
34. 【规划】规划三步走：评估环境需求、诚实面对当前状态、弥合差距；规划的输出是当下做出的决策和行动，不是文档。
35. 【TRM】按具体任务评定 TRM 并匹配管理风格：低 TRM 给结构化的 how 指令，中 TRM 就 what/why 共同推理，高 TRM 只约定目标加轻量监控；TRM 随任务变化，不等于资历。
36. 【TRM】新晋升的管理者即使是最强工程师，也要把管理任务（1:1、招聘、委派）当作低 TRM 任务给结构化指导。
37. 【评审】绩效评审先独立完成书面评估，再单独决定哪三条信息真正会改变对方明年的产出。
38. 【评审】遵守 no surprises：如果评审里有什么让对方吃惊，那是主管的失败。
39. 【评审】对「躺平的高手」投入最多评审精力：一句 keep it up 等于剥夺了他进入下一层的机会。
40. 【评审】反馈不要攒到年度评审，事件发生时即给。
41. 【培训】经理亲自交付培训（例如 EM 亲自上四节 incident-response 课）——外包培训就是外包标准。
42. 【边界】所有做法的伦理边界：让系统跑热而不是让人跑热；指标度量工作而非工人；杠杆是放大他人产出，不是把审批和信息攥在自己手里当瓶颈。

适用边界 · 注意事项

• 想解决的是个人内在动机问题时，改用 drive-motivation 一类方法，而非本套管理杠杆工具。
• 需要搭的是整个公司运营系统（operating system）时，用 traction-eos 一类框架，本方法是管理者层面的实践。
• 不要把指标用于监视个人，也不要把生产思维用于把人当可替换机器——这会让人优化数字而非产出，背离本方法。