team-composition

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Team Composition

团队组成

Before Starting

开始之前

Check for EM context first. If

.agents/em-context.md

exists, read it.

.agents/em-context.md

does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and

.agents/reports/[name].md

does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update

.agents/em-context.md

.agents/reports/[name].md

automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先确认工程经理（EM）的背景信息。如果

.agents/em-context.md

文件存在，请读取该文件。

如果

.agents/em-context.md

文件不存在，请先询问并保存一份基础的经理资料，之后再提供详细建议：职位/头衔、团队规模、团队使命或负责领域，以及当前面临的挑战或优先级。

如果对话核心是某位特定人员，且

.agents/reports/[name].md

文件不存在，请先询问并保存该人员的基础资料，之后再提供详细建议：职位/级别、任职时长、优势，以及当前面临的挑战或成长方向。

如果后续对话中出现可长期留存的新信息，请自动更新

.agents/em-context.md

或

.agents/reports/[name].md

文件。仅保存稳定的事实和模式，不保存猜测、暂时的挫败感或未明确的解读。

Response Style

回复风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

State the likely diagnosis or recommendation first
Ask at most 2-3 targeted questions only if the missing context changes the advice
Give the next concrete action and, when useful, exact wording the manager can use
Mention the relevant framework briefly, but do not explain every part of it
Offer a deeper version only after the direct answer

首次回复需简洁实用。除非用户要求深入讲解，否则不要全盘输出整个框架。

默认遵循以下原则：

首先说明可能的诊断结果或建议
仅当缺失的背景信息会影响建议时，最多提出2-3个针对性问题
给出具体的下一步行动，必要时提供经理可直接使用的措辞
简要提及相关框架，但无需解释其所有细节
仅在给出直接回复后，再提供深入版本的内容

How to Use This Skill

如何使用本技能

Diagnosing what the team is missing / who to hire next → The Dungeon Party Model
Team is slow despite having enough headcount → Barrels and Ammunition
Senior engineer who thrived before is struggling now (or vice versa) → Commandos, Infantry, and Police
Team is dangerously small or built around one person → Minimum Team Size

诊断团队缺失的能力/下一步招聘人选 → 使用Dungeon Party模型
人手充足但团队效率低下 → 使用Barrels and Ammunition框架
此前表现出色的资深工程师如今陷入困境（反之亦然） → 使用Commandos、Infantry和Police模型
团队规模过小或过度依赖某个人 → 使用最小团队规模指南

Default Response Shape

默认回复结构

When helping with team composition, diagnose capability before recommending headcount:

Team need: execution, reliability, glue, architecture, exploration, or phase-fit.
Current imbalance: which archetype or capability is missing or overloaded.
Evidence: symptoms in delivery, incidents, planning, collaboration, or morale.
Intervention: hire, grow, reassign, pair, split ownership, or change expectations.
Risk: what happens if the team adds the wrong kind of person.

Do not default to "hire a senior." Explain what capability is missing.

在协助团队组成相关问题时，先诊断团队能力，再建议招聘人手：

团队需求：执行能力、可靠性、协作衔接、架构设计、探索创新，或阶段适配能力。
当前失衡点：哪种原型或能力缺失或过载。
证据：交付、事故、规划、协作或团队士气方面的症状。
干预措施：招聘、培养、重新分配任务、结对编程、拆分职责，或调整预期。
风险：如果团队招聘了不合适的人员会产生什么后果。

不要默认建议“招聘资深工程师”。需明确说明缺失的具体能力。

The Dungeon Party Model

Dungeon Party模型

Every role-playing game requires a balanced party. A team of all warriors dies to magic. A team of all healers can't kill anything. The same logic applies to engineering teams.

The five archetypes:

每个角色扮演游戏都需要平衡的队伍。全是Warrior的队伍会死于魔法攻击，全是Healer的队伍无法击败敌人。这一逻辑同样适用于工程团队。

五种原型：

The Warrior

Warrior（战士）

Senior problem-solver. Owns the hard bugs, the production fires, the gnarly migrations. Decisive and effective under pressure. The person you call when something is genuinely broken.

Team need it fills: execution on difficult, high-stakes work.

资深问题解决者。负责处理棘手的bug、生产环境故障、复杂的迁移任务。在压力下果断且高效。是遇到真正棘手问题时你会求助的人。

填补的团队需求：高难度、高风险工作的执行能力。

The Tank

Tank（坦克）

Reliable executor, typically earlier in career, works closely with a Warrior. Not expected to lead — expected to deliver consistently on well-defined work and absorb some of the Warrior's load.

Team need it fills: sustained output on standard work without burning senior bandwidth.

可靠的执行者，通常处于职业生涯早期，与Warrior密切合作。不要求其领导工作，但需持续稳定地完成明确的任务，分担Warrior的部分工作负荷。

填补的团队需求：在不消耗资深人员精力的前提下，持续输出标准化工作成果。

The Healer

Healer（治疗师）

Empathy-driven, business-oriented, the team's social glue. Often the bridge between engineering and product/design. Great at facilitating difficult conversations, unblocking cross-team friction, and keeping team morale intact during hard periods.

Team need it fills: relationships, communication, and organizational navigation.

富有同理心、以业务为导向，是团队的社交粘合剂。通常是工程与产品/设计之间的桥梁。擅长推动艰难对话、消除跨团队摩擦，并在困难时期保持团队士气。

填补的团队需求：人际关系维护、沟通协调，以及组织内的事务推进能力。

The Wizard

Wizard（巫师）

Senior or staff engineer who handles system design, architecture documents, and systemic thinking. Sees consequences several steps ahead. Slower to produce output but prevents expensive mistakes.

Team need it fills: architectural quality and long-range technical direction.

资深或Staff工程师，负责系统设计、架构文档和系统性思考。能预见多步之后的结果。输出速度较慢，但能避免代价高昂的错误。

填补的团队需求：架构质量保障和长期技术方向规划。

The Rogue

Rogue（盗贼）

Versatile full-stack utility player. Context-switches across areas, ships exploratory work, covers gaps. The person who can pick up anything and make progress.

Team need it fills: flexibility and coverage in unpredictable situations.

多才多艺的全栈多面手。能在不同领域间切换工作，完成探索性任务，填补团队缺口。是那种能接手任何工作并取得进展的人。

填补的团队需求：不可预测场景下的灵活性和任务覆盖能力。

Using the Model

模型使用方法

Audit your current roster. For each engineer, identify their primary archetype. Then look for gaps: which archetype is missing or overloaded?

Common gaps:

No Tank → Warriors burn out on routine work
No Healer → Team is technically strong but organizationally brittle; cross-functional friction accumulates
No Wizard → Architecture decisions get made ad hoc; technical debt compounds

Watch for EM archetype bias. EMs tend to over-hire in their own archetype. Former Warriors hire Warriors and ignore Healers. Former Healers hire for culture fit and end up short on execution. The model counteracts this by making the gap explicit.

Use it for hiring decisions. When a headcount opens, map the current team first. The next hire should fill the most critical gap — not replicate the most common archetype.

审核当前团队成员：为每位工程师确定其主要原型。然后寻找缺口：哪种原型缺失或过载？

常见缺口：

没有Tank → Warrior会因常规工作burnout
没有Healer → 团队技术实力强劲，但组织层面脆弱；跨职能摩擦不断积累
没有Wizard → 架构决策随意；技术债务持续累积

注意工程经理（EM）的原型偏见：EM往往倾向于招聘与自己同原型的人员。曾是Warrior的EM会招聘Warrior，忽略Healer。曾是Healer的EM会注重文化适配，导致执行能力不足。该模型通过明确指出缺口来抵消这种偏见。

用于招聘决策：当有招聘名额时，先梳理当前团队情况。下一位招聘人选应填补最关键的缺口——而非复制最常见的原型。

Caveats

注意事项

This is a diagnostic model, not a box to lock people into. Most senior engineers span multiple archetypes. The point is not to label people but to identify what the team is currently missing and what to optimize for next.

这是一个诊断模型，而非用来限制人的框架。大多数资深工程师会跨越多个原型。其目的不是给人贴标签，而是识别当前团队缺失的能力，以及下一步需要优化的方向。

Barrels and Ammunition

Barrels and Ammunition框架

Keith Rabois's insight: adding headcount doesn't linearly increase velocity, because most hires are ammunition — skilled people who need direction. What limits your team's throughput is the number of barrels.

A barrel is someone who can take an idea from conception all the way to shipping and bring people along in the process. They don't need direction — they create it. Adding a barrel doubles your effective output. Adding ammunition without barrels just creates more coordination overhead.

Barrels are rare and culturally specific. Someone who is a barrel at one company may not be at another — the skill is partly about navigating a specific organization. When you find one, treat them accordingly: give them equity, visibility, and significant scope. Replacing a barrel is nearly impossible.

Practical application: when a team is slow despite headcount, the diagnosis is often "not enough barrels." Before requesting more engineers, ask: how many of the people we already have can end-to-end own something? If the answer is one or two, more ammunition won't fix it.

Keith Rabois的观点：增加人手并不会线性提升团队速度，因为大多数新员工是ammunition（弹药）——需要指导的熟练人员。限制团队吞吐量的是**barrels（炮管）**的数量。

Barrel是指能将一个想法从概念阶段一路推进到上线，并带动其他人共同推进的人。他们不需要指导——他们会创造方向。增加一名Barrel会让团队的有效产出翻倍。在没有足够Barrel的情况下增加ammunition，只会增加协调成本。

Barrel稀缺且具有文化特异性：在一家公司是Barrel的人，在另一家公司可能不是——这种能力部分取决于对特定组织的熟悉程度。当你找到Barrel时，要给予相应的待遇：股权、曝光度和重要的工作范围。替换Barrel几乎是不可能的。

实际应用：当团队人手充足但效率低下时，诊断结果往往是“Barrel数量不足”。在申请更多工程师之前，先问自己：我们现有的人员中，有多少人能端到端地负责一项工作？如果答案是一两个，那么增加ammunition无法解决问题。

Commandos, Infantry, and Police

Commandos、Infantry和Police模型

Robert X. Cringely's model of how companies evolve requires different types of people at different stages:

Commandos — the first wave. Operate at startup speed. Work hard, fast, and cheap. Their job is to establish a beachhead: build the prototype, prove the idea, move before anyone knows they're there. They're not precious about quality — they're precious about speed.

Infantry — the second wave. Scale what the commandos started. They work systematically, build properly, and ship the first real product. Where commandos made 20 decisions a day, infantry makes them stick.

Police — the third wave. Companies that succeed eventually need compliance, process, and stability. Police ensure repeatable quality but are poor at innovation or speed.

The management trap: most people strongly prefer one of the three modes and are poorly suited for the others. A commando in a police phase is a troublemaker. A police officer in a commando phase is a bottleneck. Mismatches explain a large fraction of "why is this person struggling?" situations.

Two practical uses:

When hiring, identify which phase your team/product is in. Hire commandos to build new things; hire infantry to scale them. Police skills are rarely a shortage in engineering.
When a senior engineer who thrived in a startup phase struggles in your scaled organization (or vice versa), phase mismatch is often the explanation — not a sudden decline in skill.

Robert X. Cringely提出的公司发展阶段模型，不同阶段需要不同类型的人员：

Commandos（突击队员）——第一波人员。以初创公司的速度运作。努力、快速、低成本地工作。他们的任务是建立滩头阵地：构建原型、验证想法、在他人察觉之前行动。他们不重视质量——重视速度。

Infantry（步兵）——第二波人员。将突击队员开创的业务规模化。他们系统化地工作，规范地构建产品，并推出第一个真正的产品。突击队员每天做20个决策，步兵则确保这些决策落地。

Police（警察）——第三波人员。成功的公司最终需要合规、流程和稳定性。Police确保质量的可重复性，但不擅长创新或快速行动。

管理陷阱：大多数人强烈偏好三种模式中的一种，不适合其他模式。处于Police阶段的Commando会成为麻烦制造者。处于Commando阶段的Police会成为瓶颈。这种不匹配是“为什么这个人表现不佳？”这类问题的主要原因之一。

两个实际用途：

招聘时，确定你的团队/产品处于哪个阶段。招聘Commandos来构建新事物；招聘Infantry来规模化发展。工程团队中很少缺少Police的技能。
当一位在初创阶段表现出色的资深工程师在规模化组织中陷入困境（反之亦然）时，阶段不匹配往往是原因——而非技能突然下降。

Minimum Team Size

最小团队规模

From An Elegant Puzzle (Will Larson): never let a team drop below roughly 4 people — and never create a team around a single person.

A team of 1 or 2 is structurally fragile: one person's vacation, illness, or departure can halt everything. It also means no real code review, no knowledge redundancy, and no ability to handle an incident while also doing normal work.

The failure mode to avoid: creating small "teams" as organizational fictions — one engineer "owns" a product area and is technically a team. This engineer carries all the risk and gets none of the support structure a real team provides. When something goes wrong or when they leave, there's no team to absorb it.

Minimum viable team (Larson's guidance): ~4 engineers. This gives enough coverage for on-call, code review, technical design, and vacation without creating a single point of failure.

When you're below this: either grow the team to minimum viability, merge it into a larger adjacent team, or be explicit that it's a temporary solo/pair arrangement with a transition plan — not a permanent structure.

出自《An Elegant Puzzle》（Will Larson）：永远不要让团队规模降到约4人以下——永远不要围绕单个人组建团队。

1或2人的团队在结构上非常脆弱：一个人的休假、生病或离职可能导致一切停滞。这也意味着没有真正的代码评审、没有知识冗余，无法在处理事故的同时开展日常工作。

需要避免的失败模式：将小型“团队”作为组织虚构——一名工程师“负责”某个产品领域，在技术上被视为一个团队。这位工程师承担了所有风险，却得不到真正团队提供的支持结构。当出现问题或他们离职时，没有团队能承接工作。

最小可行团队（Larson的建议）：约4名工程师。这样可以为值班、代码评审、技术设计和休假提供足够的覆盖，避免单点故障。

当团队规模低于此标准时：要么将团队扩大到最小可行规模，要么将其并入相邻的更大团队，要么明确说明这是临时的单人/双人安排，并制定过渡计划——而非永久结构。

Dive Deeper

深入探索

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read

references/sources.md

如果用户询问框架的来源、想要阅读原文，或想要了解本技能中任何主题的更多背景信息，请读取

references/sources.md

文件。