您本月还剩 1 篇文章可阅读，之后需要 注册 一个免费的 LeadDev.com 账户。

预计阅读时间：10 分钟

关键要点：

  • 工程经理面临的是一个权衡问题，而不是工作量问题。每一项期望单独来看都可能是合理的。问题在于它们正在同时扩大。
  • 隐藏的权衡与可见的权衡一样真实。把选择明确化，才能有东西可以去争取。 
  • 目标是将判断力集中在能改变结果的地方。

工程经理被要求在各个方向上做更多。你可能被期望帮助团队借助 AI 更快推进、与技术决策保持紧密接触、通过模糊性指导团队、跨团队施加影响，并更具战略性地运作。 

每一项期望单独来看可能都是合理的。问题在于它们正在同时扩大。这通常被描述为工作量问题。实际上它是一个权衡问题。

领导力容量是有限的。你只有有限的注意力可用于教练、评审、决策、升级和理解不断变化的组织。某些事情已经在被舍弃，无论是否有人承认。聪明的做法是让这些权衡变得可见。

这不是为了少做而少做，而是更清楚地了解你的判断力在哪里最重要、你选择忽视什么，以及谁需要知道。

升级你的收件箱。

每周接收工程洞见，提升你的领导力方法。

工程经理角色不会线性扩展

许多工程组织谈论管理容量时，仿佛它可以线性扩展。增加几个项目、利益相关者或更多依赖，经理就会神奇地拉伸覆盖。

然而，范围并非只朝一个清晰的方向增长。有时意味着更多直接下属。有时意味着更少但更资深的人，并行运行更多工作。有时意味着更多跨团队依赖、更不明确的归属，或更多技术变更同时流经系统。

AI 为此增加了另一层。它可以帮助团队更快产出工作，但也会增加你需要解读的材料量：更多功能提案、更长的规格，以及更多半成品选项争夺决策。瓶颈从产出工作转移到判断哪些工作是连贯且值得做的。

控制跨度与上下文负载之间的区别很重要。控制跨度是关于有多少人向你汇报。上下文负载是关于你被期望同时处理多少对话、决策和风险。

认知过载以微妙的方式显现：风险浮现所需时间变长、教练反馈变浅、技术判断变得不可靠。

作为经理，你并没有变得更没能力。只是角色已经超出了一个人能良好承载的上下文量。

3 个需要明确的权衡

隐藏权衡的问题在于，它们很少感觉像是真正的选择。它们感觉像是在积累压力下的即兴决定。

你错过设计评审，因为团队有人这一周过得很艰难，需要你更多。你缩短一对一会谈，因为跨团队的火情在等待。你让工程师主持一次讨论，因为你不可能在每个地方。你跳过策略文档，因为眼前的交付风险更响亮。

这些决定本身并不自动是错误的。其中大多数正是优秀经理应该做的。重要的是你是否刻意做出了权衡，以及周围的人是否知道你做出了这个决定。

让我们将这些反复出现的张力分组成对，探索我们默认反应的替代方案。

更多相关内容

1. 深度 vs. 广度

第一个权衡是：在覆盖不断增长的组织表面时，你能多深入地理解你负责的系统和决策。

选择深度，你就会参与设计评审、架构辩论和风险对话。你能更直接地发现问题。你可以真正指导工程师处理细节，但你用于对齐、影响和跨团队串联工作的时间更少。

选择广度，你会把时间花在塑造归属、升级路径、优先级和决策制定地点上。这可能正是团队需要的，但如果你从未说明，你的工程师仍会期望你参与每个重要的技术对话，而你的经理则期望你在三个层级之上工作。

无论哪种方式，未满足的期望都会造成挫败。

更清晰的说法是：“鉴于我们目前的范围，我本季度选择广度。我将减少参与详细设计评审的时间，更多地确保我们有正确的负责人、正确的决策论坛和清晰的升级路径。”

现在人们有具体的内容可以去争取。你的经理可以挑战它。你的团队可以标记风险。这就是重点。一旦权衡可见，它就可以被讨论和调整。

2. 紧急 vs. 重要

第二个权衡是：当节奏从未放缓时，你能为长期质量、团队健康和战略保护多少时间。

紧急工作很响亮。事故、升级、阻塞、高管要求、客户问题、临近截止期限。所有这些都要求你立刻处理。

重要工作则通常更安静。教练新任技术负责人。写下决策规则，使下次不需要你的干预。修复不断产生救火演练的流程缺口。在下个规划周期爆发前建立对齐。

我们告诉自己，等事情平静下来再去做重要的事。我们都知道，在大多数地方，事情不会平静下来。

更刻意、更有意的方式可能是：“本月我将保护时间来指导我们的新任技术负责人。除非有真正需要我的范围、可靠性或跨团队依赖问题，否则我不会参加每个项目状态评审。”

具体句子并不重要。重要的是说出什么会得到你更少的关注。跳过这一步，你的日历就会变成你的策略，而最响亮的事情总是获胜。

3. 存在 vs. 影响

第三个权衡是：在不稀释你对真正能推动关键事项的影响力的前提下，你能在多大程度上出现在每一次对话和评审中。

经理们经常混淆可见性与价值。出现在每个会议中感觉负责任。被抄送每条线程感觉有信息。评审每个决策感觉安全。但超过一定程度，可见性只是对你判断力的征税。

更好的问题不是“我应该在哪里？”而是“我的存在在哪里能改变结果？”

有时这意味着退出定期会议并查看 AI 摘要。有时这意味着让工程师主持架构讨论，只在决策超出你事先同意的界限时介入。有时这意味着用简短的风险、所需决策和仍悬而未决的依赖列表取代状态更新。

一个有用的边界表述是：“我不需要参与每一次讨论。我只需要在决策涉及客户承诺、可靠性、人员配备或其他团队路线图时提前得到提醒。”

这有助于你的团队理解你的参与实际意味着什么。不是每个决策都应该等待你，而是正确的决策在正确的时间、以足够的上下文到达你这里，使你的判断力值得被利用。

让我们对此进行更深入的探讨。

将监督视为有限容量

我们通常对技术容量很自律。我们跟踪利用率、饱和度、延迟、错误预算和瓶颈。我们毫无争议地接受：当需求超过容量时，系统会退化。我们几乎从未用这种方式思考领导力。

每个组织都有有限的评审、决策、验证和教练资源可供分配。超出这个范围，质量不会崩溃，而是会侵蚀。更多工作需要返工。决策会被重新开启。归属变得模糊。经理变得被动反应。团队等待太久才得到决定，或者放弃并停止询问。

通常的回应是变得更高效。更短的会议、更多委派、更清晰的例程和受保护的专注时间。所有这些都有帮助，但仅限于一定程度。效率可以买回时间，但不能让你免于决定你的判断力在哪里最重要。

更好的起点是仔细审视你的监督负载本身。

问问自己哪些决策真正需要你。哪些评审你只是出于习惯在做。你在哪里只是在重复已经足够优秀的工程师的判断。哪些批准创造了安全，哪些只制造了延迟。你在哪里仍然是后备，因为没有人明确归属。

然后有意识地卸载负载。取消低价值批准。将归属下推到应有的位置。要求资深工程师负责整个问题领域，而非零散任务。写下决策规则，使例行请求停止找你。用更好的运营信号取代重复的状态检查。明确哪些风险需要升级，哪些团队应该自行处理。

重点不是退出，而是将你的注意力保留在判断力真正能改变结果的地方。

一个具体的方法是绘制决策边界。工程师在没有你评审的情况下做出本地实现决策。技术负责人负责你在同意的架构约束内的设计决策。当决策影响范围、人员配备、可靠性、客户承诺或其他团队时，你才会被拉入。当权衡触及组织优先级或需要你无法控制的资源时，总监才会被拉入。

这些边界不会完美，也不需要完美。它们的任务是消除不必要的升级，使剩余的升级更清晰。

协商而非吸收

许多经理默默吞下这些张力，因为说出它们感觉像承认自己跟不上了。事实并非如此。这是约束下的领导力，这才是真正的职责。

与你经理的对话不应该听起来像承认失败。它应该听起来像是一个你们共同解决的设计问题：“我们的范围在扩大，而对教练、技术深度和组织领导力的期望保持不变。这些不能一起扩展。让我们一起决定我们想有意识地做出哪些权衡。”

这种重新表述很重要。你不是在寻求同情，而是在帮助组织做出更好的选择。

优秀的高级经理可能无法立即消除压力。但他们可以澄清优先级、减少冲突的需求，并停止用两个相互矛盾的目标来衡量你。

对你的团队也是如此。从某些决策中退后？说明原因。保护更多时间用于教练？说出什么会得到你更少的关注。要求资深工程师承担更多技术判断？清楚说明他们在哪些地方有权限，以及你仍然希望在哪些地方被循环告知。

人们处理权衡的能力远胜于处理模糊性。挫败感通常不是来自权衡本身，而是太晚才发现每个人都假设了不同的权衡。

如何开始

你不需要重新设计整个工作就可以开始。选择一个你已经在做但从未说出口的权衡。把它写成一句话：“本季度我正在优化 ___，这意味着我将刻意减少对 ___ 的关注。”

例如：“本季度我正在优化更广泛的组织对齐，这意味着我将较少参与常规项目状态跟踪。” 

或者：“本季度我正在优化指导我们的新任技术负责人，这意味着除非设计讨论跨越我们同意的升级界限，否则我将退出一些设计讨论。”

然后测试它。把它带给你的经理和团队，并问：“如果这是真的，会发生什么？”他们的回答会告诉你这个权衡是否可行、是否被误解，或是否真正有风险。

每月一次，坐下来思考四个问题： 

  • 我现在正在优化什么？ 
  • 因为这个优化，什么被忽视了？
  •  这种忽视是有意的还是无意的？ 
  • 谁需要知道？

这样你就能防止角色完全被最响亮的压力所塑造。

未来的工程经理

随着工作的不断扩展，工程经理被要求指导更多人、监督更多系统、参与更多决策，并影响组织的更多部分，所有这一切都基于这些责任可以共同增长的假设。它们不能。领导力容量是有限的，而某些事情已经在得到你更少的关注。

做得好的经理不是那些永远吸收每个新期望的人，而是那些理解自己的注意力最值得投入在哪里、让这些选择变得可见，并推动组织有意识地做出决定而不是太晚才发现的人。