工程经理应该有多少直接下属？

Source: Dev.to

研究显示 5‑9 人。现实要更复杂。

每位工程经理最终都会问这个问题：我到底应该管理多少人？

答案比大多数人想象的更重要。管理的人太少，你就只是个被美化的技术负责人。管理的人太多，你就会变成一个会议机器，无法给任何人提供有意义的关注。

研究发现

最常被引用的数字来自数十年的管理研究：7 ± 2 直接下属 是最佳范围。

• 少于 5 位下属 – 你作为管理者可能没有被充分利用。公司要么会在你的工作中加入个人贡献（让你成为“玩家‑教练”，这也有自己的问题），要么会质疑这个岗位是否必要。
• 5‑7 位下属 – 黄金区间。足够多的人来证明全职管理角色的合理性，又足够少，以至于你可以进行有意义的每周 1:1，提供真实的反馈，并真正了解每个人在做什么。
• 8‑9 位下属 – 如果团队成员资深且自主，这仍可管理。你需要严格规划时间的投入。
• 10 位以上下属 – 进入生存模式。1:1 可能变成每两周一次或流于表面。你会错过信号——倦怠、脱离、以及日益加重的阻碍。

没人谈论的变量

那个 7 ± 2 的数字假设了很多前提。实际上，你的管理容量取决于：

团队资历

一支由自我驱动且经验丰富的高级工程师组成的团队，需要的管理开销比拥有多名需要指导、代码审查和职业辅导的初级开发者的团队要少。

你在做多少 IC 工作

如果你仍然有 40 % 的时间在写代码（在初创公司很常见），实际上你的管理容量只有一半。一个兼任玩家‑教练的管理者在管理 7 人时，实际上只相当于用 3 个人的注意力去管理 7 人。

组织复杂度

跨团队依赖、利益相关者管理、招聘——这些都会消耗你的人员管理带宽。如果你每周有 30 % 的时间花在跨职能会议上，你的有效管理跨度就会缩小。

团队是否有 EM 与技术负责人分工

有些组织将人员管理（EM）与技术领导（技术负责人或资深工程师）分开。如果你有一位强有力的技术负责人负责架构决策和技术指导，你就能管理更多的人。

实际规模下会发生什么

• Startups (< 50 eng) – 经理通常有 4‑6 名下属，但同时也是玩家‑教练。有效的管理跨度更像是 3‑4 人。
• Growth stage (50‑200 eng) – 这是管理跨度问题最严重的阶段。快速招聘导致经理的下属人数突然从 5 人增至 10 人以上。这是我见过的导致经理倦怠的首要原因。
• Enterprise (200+ eng) – 通常在保持 5‑8 人的下属比例方面做得更好，但组织复杂性带来了隐藏的额外负担。

真正的问题：你能给每个人他们需要的东西吗？

与其执着于数字，不如自问：

• 我能每周与每位下属进行一次有意义的 1:1 吗？ 不是例行的状态更新，而是关于他们的工作、成长和阻碍的真实对话。
• 如果有人出现倦怠，我会注意到吗？ 如果你没有足够的信号来提前发现这种情况，说明你的下属太多。
• 我能为每个人写出有深度的绩效评估吗？ 如果你在复制粘贴通用的反馈，说明你已经被分散得太薄。
• 我了解每个人下一步想要在职业上做什么吗？ 不是他们的职位头衔愿望，而是他们实际的成长领域和兴趣。

如果你对上述任何一项回答“否”，要么你的下属太多，要么你需要更好的系统来保持信息畅通。

构建可扩展的系统

我见过的那些能够很好地管理更大团队的经理都有一个共同点：他们构建系统，而不是依赖记忆和英雄主义。

一些有帮助的做法：

• 异步站会，取代每日会议。你可以获取信号而不占用日历时间。像 Vereda 这样的工具可以在 Slack 中运行这些站会，并使用 AI 提取模式——重复出现的阻塞、看起来卡住的人、工作负荷不平衡。
• 结构化的 1:1 文档，将上下文在周与周之间传递。如果你每次 1:1 都以“最近怎么样？”开场，就在浪费前 10 分钟重新建立上下文。
• 轻量级团队健康指标。不是监控——只提供足够的信号，让你知道该把注意力放在哪里。站会是否变短（可能的脱离感）？是否有某个人总是被同一个依赖阻塞？

底线

5‑7 是大多数工程经理的最佳范围。 超过 9 人，你可能会做出不该有的取舍。低于 4 人，则需要确保你能提供足够的价值，以证明需要专职的管理角色。

但人数并不如你对每个人投入的关注质量重要。一个拥有 8 名下属且系统完善的优秀经理，表现会超过一个拥有 5 名下属却平庸的经理。

我正在打造 Vereda —— 一款免费 Slack 站立会议机器人，配备 AI 分析功能，帮助工程团队的管理者在不增加会议的情况下保持信息通畅，尤其适用于团队规模扩大时。如果你正面临管理不断壮大的团队的挑战，快来了解一下。