成功管理管理者（Managing Managers）的五项原则
摘要
本文由前 Square CPO 兼业务负责人 Saumil Mehta 撰写，分享了他在 Square 九年间管理超过 800 名员工、100 多位经理过程中提炼出的管理管理者的五项核心原则。Mehta 的核心洞见是：所有的一线管理者问题，直接或间接都源于"隔级领导"（Skip Lead）——即经理的经理。五项原则包括：(1) 认识到管理管理者是与管理个人贡献者 (IC) 完全不同的角色，学习曲线至少同等陡峭；(2) 进行"API 端点实验"——假设你只能通过直接下属经理来推动工作，以此强迫自己培养新的价值创造方式；(3) 永不削弱 (Never Undermine) 直接下属经理的权威；(4) 永不为直接下属经理的低绩效向上级"打掩护" (Never Cover)；(5) 使用"任务相关成熟度"（Task-Relevant Maturity, TRM）来匹配项目和经理，并用"不确定性-影响力"矩阵做项目评审。作者强调，卓越的隔级领导是组织规模化中的承重支柱。
正文
引言：所有经理问题的根源都在隔级领导
"人们不是辞掉工作，而是辞掉他们的经理。"这句职场老话我们大多都听过。大多数人都曾听到朋友或同事抱怨他们的经理缺乏支持、微观管理 (Micromanagement)、产品嗅觉缺失、反馈不公，或是其他司空见惯的关系问题。
当我在 Square 越来越资深——最终领导所有产品、营销和合作伙伴关系，涵盖 800 多位同事和超过 100 位经理——我频繁听到这类抱怨，无论在工作场合还是朋友之间，不分产品经理 (PM)、工程师、设计师还是营销人员，也不论资历深浅。
随着时间推移，虽然对话内容没变，但我的建议发生了显著变化。我现在不再聚焦于当事人自己的经理，而是总会说："跟我说说你的经理的经理吧。" 这个人也被称为"隔级领导"（Skip Lead）。
[此处原文含隔级领导 vs 一线经理层级关系示意图]
当我把问题聚焦到隔级领导时，通常会让人们感到惊讶。但这背后是有原因的，源于来之不易的经验。事实上，我坚信所有的经理挑战，都直接或间接地与隔级领导有关。
不要把所有负担都压在一线经理身上，我们需要把分析的目光上移到隔级领导。毕竟，隔级领导负责招聘经理，负责评审他们的绩效，负责辅导他们——或者未能做到。
多年来，我得出结论：大量的组织杠杆来自于帮助新任管理者有效过渡到管理者的管理者这一角色。通过对话、人才评审和直接领导大型组织的经验，我总结出几条关键原则，帮助新任隔级领导更好地理解和履行其职责。如果你是一名新任隔级领导，或希望很快成为一位，这篇文章为你而写。
原则一：认识到你身处不同的角色
首先，退一步来认知（并接受）一个事实：管理管理者所需的技能和责任，与直接管理个人贡献者 (Individual Contributor, IC) 截然不同。大多数人凭直觉知道，从 IC 转为一线经理 (Line Manager) 是一次角色变化，有着陡峭的学习曲线。但认为从一线经理到管理者管理者的学习曲线同样陡峭——如果不是更陡峭的话——是非常反直觉的。毕竟，这些人已经"进入管理层"了，这不就是同一套方法应用在更大的团队上吗？
[此处原文含管理角色层级转变示意图]
答案是：不，差远了。
这是一套完全不同的责任体系，因为你不再直接与 IC 一起工作（IC 自己做工作，拥有完整上下文），而是需要透过一个抽象层——一线经理——来工作，而且要同时跨越六位或更多的经理。任何想亲自紧盯每项工作的念头都得抛弃。此外，IC 作为执行者、经理作为支持者和辅导者那种清晰的职责划分也模糊了，因为现在出现了经理向其他经理汇报的情况。还有，从一线 IC 那里获取未经过滤信息的能力，也消失了。
可悲的是，组织和高级领导层对这次重大角色变化的认知缺失是普遍存在的。而众所周知，哪里存在严重的自我认知缺失，平庸就一定会紧随其后。
在我自己的组织中，我对此问题的严重性如此清楚，以至于多年来我坚持亲自审批每一位一线经理晋升为经理管理者的案例。有时我甚至会与新任隔级领导安排一对一沟通，明确设定关于这一重大角色转变的期望。有时这被认为是不必要的过度干预，但我知道，如果新任隔级领导能从一开始就认识到这陡峭学习曲线的自我认知，整个组织就已经领先一步了。
原则二：进行 API 端点实验
API (Application Programming Interface) 之所以美妙，是因为它允许工程师依赖接口完成任务，而忽略背后的所有复杂性。这一类比可以应用于管理管理者，方法是进行如下思想实验："如果我完全无法接触组织中的任何 IC，只能通过我下属的经理来推送或拉取信息来做决策，我该如何变得有效？"
这种内省的力量，类似于在健身房举重或进行冷水浴：在不自然的环境中做不舒服的事情，会产生成长。大多数刚到位的隔级领导不久前还在一线经理岗位上，他们最习惯的是直接与 IC 打交道、获取详细上下文并给予指导。这个具有挑战性的问题迫使他们面对一个核心拷问：当核心的上下文构建和决策工具——直接接触 IC——被移除，只有直接下属经理可用时，他们该如何创造价值。这立即迫使新任隔级领导面对一连串后续问题，例如：
- 如果不与 IC 直接交谈，我如何帮助一线经理识别团队中的问题？
- 我如何帮助一线经理处理他们团队中的 IC 绩效问题，而不是自己亲自处理？
- 当一线经理的判断与我相反时，我何时选择遵从他们的判断？
- 即使经理已经与所有 IC 交谈并拥有更多一手信息，我在何种情况下坚持自己的观点？
- 我如何以对经理已有工作形成补充（而非重复）的方式评审其团队的产出？
- 我如何在足够早的阶段提供输入，使一线经理能及时纠偏？
- 哪些领域我完全授权给一线经理，哪些领域我保留最终签批权——为什么？
进行这项练习有两个关键前提。首先，以本能般的熟练度回答这些问题需要多年的实践。（但我发现，新任隔级领导如果主动提出这些问题，会加速他们在角色中的学习。）其次，这是一个思想实验，应当认真对待但不应字面化执行。在现实中，隔级领导当然应当定期与隔级下属 (Skip Report) 交流。但是他们如何与隔级下属互动、以及这如何与直接下属形成互动，可以从极端实验中获益。
原则三：永不削弱 (Never Undermine)
在 Square，我与数十位隔级下属保持定期一对一沟通，每周为 800 人组织中的任何人开放办公室时间 (Office Hours)，并在 Slack 和面对面中有大量临时对话。如果你是一名新任隔级领导，这也应当是你的常见实践。
这些对话极具价值，因为它们提供了未经过滤的反馈——这些反馈可能是你直接下属经理遗漏的，甚至是刻意过滤掉的。它们也为评估你直接下属经理的表现提供了关键的上下文来源。
但这些对话也有风险。新任隔级领导的本能反应是当场给出强烈意见、解决问题和做决策，而不从管理链条中的其他人那里获取完整上下文。这感觉很高效！甚至可能感觉像是在实践"创始人模式"（Founder Mode）。
但总体而言，即兴的解决方案和强烈意见实际上会削弱管理链条中你的直接下属经理，使他们在自己的团队面前丧失权威。你剥夺了直接下属经理从你这里获得辅导的机会——如何处理特定情况、学习你的推理思路、理解你的上下文——然后由他们自己以持续且可扩展的方式在其团队中应用。除了削弱直接下属经理外，你还很容易在隔级下属与他们的直接经理之间造成矛盾指令的混淆。LinkedIn 前 CEO Jeff Weiner 在一篇关于此主题的优秀文章中阐述了这个问题："多年前，我的一位前直接下属帮我点透了这一点。虽然他和他的团队欢迎我的意见，但他注意到，很多时候我以为是无所谓的随口一说，却会引发一场极具破坏性的'救火演习'。在那之前，我完全不知道我的意见被赋予了如此之重的分量。"
更好的做法是：仔细倾听，多问跟进问题，然后主动与你的直接下属经理合作完成所有后续跟进和实际的方向设定。
[此处原文含隔级领导正确沟通模式示意图]
以上建议与近期主张创始人 CEO 实践创始人模式的呼声并不冲突。做得好，创始人模式意味着创始 CEO 保持高度参与和亲力亲为，同时辅导和赋能管理链条。做得不好，创始人模式不过是制造削弱、剥夺权威和混乱的配方。
原则四：永不遮掩 (Never Cover)
新任隔级领导削弱直接下属经理的反面，是在自己的上级面前为直接下属经理的低绩效打掩护 (Cover)。请看下面这张图——任何在大型组织中工作过的 PM 都会感到非常熟悉。
[此处原文含"打掩护"现象示意图：隔级领导替表现不佳的一线经理完成其工作并向更上层汇报]
即便隔级领导潜意识（甚至明确地）知道这名一线经理在挣扎，正面面对这个问题确实很难——尤其对于新上任的隔级领导。于是自然的倾向是悄悄自己解决问题，承担双倍职责——接手部分一线经理的工作，然后在其他人面前为直接下属经理的绩效打掩护。
在快速增长的科技公司中，这种情况经常发生。我已经数不清多少次在剖析一个走向失败的项目残骸时，发现正是这个问题。但为坏消息打掩护的本能，深深植根于人类情感：失败的羞耻与尴尬、对冲突的恐惧、以及不安全感。
新任隔级领导的更好做法是：(1) 清晰地向管理链条上层汇报绩效不足和纠偏计划，(2) 向上征求对纠偏方案的反馈，(3) 与直接下属经理设定明确的绩效期望。
[此处原文含正确应对方案示意图：透明上报绩效问题而非遮掩]
原则五：用任务相关成熟度（TRM）来授权和评审工作
从以上原则可以看出，隔级领导最成功的时候，是学会如何从直接下属经理那里获取最大产出的时候。广义来说，这关乎在直接下属经理之间分配责任，以最大化整个团队的产出。听起来够简单的，对吧？
但在实践中，做好授权非常困难。在大多数高增长科技公司中，隔级领导面临的是不断变化的环境。每隔几周就会有新项目被规划出来；一个正在进行的项目因工程师发现意外问题而偏离轨道；一位大客户向高管层大声投诉，引发救火行动；一位负责关键项目的高级 IC 威胁要辞职；一名工程师和设计师在原型的争论中激烈争吵；一项突发的监管变化威胁到即将上线的国家发布。正如你所见，每个项目——以及围绕项目的情况——在所需努力和时间、模糊性和技术复杂度、涉及的团队数量以及对公司的潜在影响方面，差异巨大。
[此处原文含各种突发场景示意图——客户投诉、员工离职、团队冲突、监管变化等]
更复杂的是，项目和情况只是等式的一半。隔级领导还需要判断哪一个直接下属经理最适合承担，因为正如每个项目和情况各不相同，每个一线经理也是如此。
在任何一个隔级领导的组织中，一线经理们在技能水平、机构知识、情感成熟度、应对模糊性的能力以及其他独特优势和弱点上差异极大。在产品开发中，经理甚至可能专攻工程子学科如移动端，而 PM 负责人可能专攻开发者工具或消费社交媒体等特定领域。
做好授权之所以如此困难，是因为它需要在一个不断变化的环境中对多样化的项目和多样化的人员进行持续匹配。
幸运的是，Andy Grove 的经典著作《High Output Management》为我们提供了一个关键管理概念框架来应对这种匹配：任务相关成熟度（Task-Relevant Maturity, TRM）。TRM 要求隔级领导评估每个项目或情况的具体特征——范围、规模、风险、持续时间、模糊性等——然后考虑哪位经理基于其技能和经验最适合（就该特定项目或情况而言）。
当一个项目或情况出现时，隔级领导可以提出以下问题来确定哪位经理最适合：
- 我哪个经理之前处理过非常类似的项目？
- 我哪个经理具备这种情况所需的技术水平？
- 我哪个经理曾向我表示过希望承接这类项目以拓展自己？
- 我哪个经理足够资深，能应对高度模糊性？
- 在极为敏感的人际关系处理上，我最信任哪个经理？
- 我哪个经理最适合偏重移动端的项目？
- 哪个经理能在需要我个人稍多参与的情况下完成这个项目？
- 我可以把这个任务完全交给谁，让我能彻底从这件事上脱手？
精于授权的隔级领导会持续通过 TRM 的视角来过滤项目、情况和人员，以最大化团队产出和速度。
但授权只是关键的第一步。正如 Andy Grove 在书中提醒我们的，授权并不意味着推卸责任。隔级领导仍然有责任持续深入地评审工作——并在必要时进行微观管理——以确保事情正常运行。最终，责任止于隔级领导。
下面这个 2×2 矩阵可以帮助隔级领导从两个关键维度进行授权后的评审：不确定性 (Uncertainty) 和影响力 (Impact)。通过清晰阐明项目的不确定性（例如一个全新的 0 到 1 产品，定义上就是高度不确定的）和项目的影响力（例如核心产品中的一个关键发布，可能决定财务计划的成败），隔级领导可以在初次将项目分配给一线经理后，灵活调整自己的评审节奏。
[此处原文含不确定性×影响力 2×2 矩阵图：低不确定性与低影响力 → "可遗忘"式委托；高不确定性与高影响力 → 分配给高 TRM 的经理并密切持续评审]
例如，一个低影响、低不确定性的项目可以轻松委托给一位经验较少的一线经理，然后"忘记"它。但一个高影响、高不确定性的项目应当分配给能力更强的人（即对该情况拥有高 TRM）——并且要紧密、持续地评审。
一种常见的高不确定性与高影响力项目类型是涉及多个团队协作，跨越不同一线经理甚至跨越不同隔级领导的。鉴于跨团队沟通的固有困难、各团队之间的优先级冲突以及涉及的一线经理数量，隔级领导有责任在授权后持续评审工作，尽早发现问题——并解决它们。
[此处原文含复杂多团队交叉项目示意图]
结语
新任管理管理者可以在上任第一周就开始应用这五项原则，并希望持续多年。它始于认知角色变化和陡峭的学习曲线。如果新任隔级领导运用认知技巧来集中注意力、谨慎处理与 IC 的互动和对一线经理的意外影响、深入理解任务相关成熟度、并用不一致性作为信号来解决冲突，他们就能随着时间的推移成为管理管理者的专家。
但如果你是这个角色的新手，我希望你也给予自己耐心的宽容。达到顶尖水平很难，需要很多年。在管理管理者十多年之后，我仍在学习、改进和打磨我的模式匹配直觉。你也会如此。也许几年后，当你听到朋友给出那个经典的抱怨时，你也会问："隔级领导是谁？"
本文由 Saumil Mehta 撰写。你可以在 LinkedIn 和 X 关注 Saumil，阅读他关于公司建设的个人文章请访问 Medium。