Back to Details

delegation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Delegation

工作委派

Before Starting

开始之前

Check for EM context first. If 
.agents/em-context.md
exists, read it.
If 
.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
or 
.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

如何使用该技能

Identify the situation first:
  • You're the bottleneck — doing too much yourself → The Two Things to Delegate First (start here)
  • Not sure how much involvement to have on a task or with a person → Task-Relevant Maturity
  • Wondering if you're micro or under-managing → Micromanagement vs. Under-management
  • Engineers wait to be told rather than acting → Intent-Based Leadership
  • Want to give engineers deeper ownership beyond individual tasks → Giving Engineers a Kingdom
  • Assigning work across the team strategically → Three-Layer Assignment Framework
  • Feeling anxious about letting someone do it differently than you would → read 
    references/extended.md
     — Delegation Anxiety
  • Going on vacation / someone needs to cover → read 
    references/extended.md
     — Covering for You While You're Away
  • Deciding which tasks to pick up yourself as EM → read 
    references/extended.md
     — Being Hands-On: Choose Tasks Intentionally
  • Someone on the team seems entirely self-directed → read 
    references/extended.md
     — Free Electrons
  • A process keeps breaking despite repeated asks → read 
    references/extended.md
     — Mechanisms Over Intentions
  • Engineers keep coming to you for answers instead of deciding → read 
    references/extended.md
     — Pulling Instead of Pushing
  • Feedback about being too controlling or too hands-off → read 
    references/extended.md
     — 4 Decision-Making Modes
先识别场景：
  • 你是瓶颈——承担了太多工作 → 首先委派这两类工作（从此处开始）
  • 不确定对某项任务或某个人该投入多少精力 → Task-Relevant Maturity框架
  • 想知道自己是否存在微观管理或管理不足的问题 → 微观管理vs管理不足
  • 工程师等待指令而非主动行动 → 意图导向型领导力
  • 希望让工程师在单个任务之外获得更深层次的所有权 → 为工程师划分“领域”
  • 战略性地在团队中分配工作 → 三层分配框架
  • 对放手让他人以不同方式完成工作感到焦虑 → 阅读
    references/extended.md
     — 委派焦虑
  • 即将休假/需要他人代班 → 阅读
    references/extended.md
     — 休假期间的工作代班
  • 决定作为EM应该亲自承担哪些任务 → 阅读
    references/extended.md
     — 亲力亲为：有目的地选择任务
  • 团队中有人完全能自主工作 → 阅读
    references/extended.md
     — 自由型员工
  • 尽管多次要求，流程仍持续出问题 → 阅读
    references/extended.md
     — 机制优先于意愿
  • 工程师总是来找你要答案而非自己做决定 → 阅读
    references/extended.md
     — 引导而非推动
  • 收到关于你控制欲过强或过于放任的反馈 → 阅读
    references/extended.md
     — 四种决策模式

Default Response Shape

默认响应结构

When helping with delegation, diagnose the bottleneck before giving tactics:
  1. Delegation target: what work should move away from the manager.
  2. Maturity read: how much context, autonomy, and follow-up the person or task needs.
  3. Delegation contract: owner, decision rights, check-in cadence, and done criteria.
  4. Risk controls: what the manager should inspect without taking the work back.
  5. Script: exact wording for assigning the work or resetting ownership.
If the manager is anxious about quality, address the control fear directly and design a review loop rather than advising them to "just let go."
在协助委派工作时，先诊断瓶颈问题再给出策略：
  1. 委派目标：哪些工作应该从管理者手中转移出去。
  2. 成熟度评估：该人员或任务需要多少上下文信息、自主权以及跟进支持。
  3. 委派约定：负责人、决策权限、检查频率以及完成标准。
  4. 风险控制：管理者应检查哪些内容，且不收回工作权限。
  5. 话术模板：分配工作或重置所有权时可直接使用的准确表述。
如果管理者对工作质量感到焦虑，直接解决其控制欲顾虑，并设计一个审查循环，而非建议他们“直接放手”。

The Two Things to Delegate First

首先委派的两类工作

1. Day-to-Day Operations: The Team Rep

1. 日常运营：Team Rep模式

The most impactful first delegation is the daily operational load — alerts, support requests, production issues.
How it works:
  • Each day/week, one team member is the "Team Rep" (rotating)
  • The Rep is responsible for: monitoring alert channels, helping the support team, debugging new issues, coordinating incident response
  • The Rep is NOT responsible for fixing everything — the developer who introduced a bug fixes it. The Rep coordinates and learns.
  • The manager is NOT the first call. The Rep is.
Setup tips:
  • Put it on the calendar as a recurring rotation with a written guidelines doc
  • In the first rotations, consultations with you are fine — but never solve it yourself
  • Keep yourself in the rotation. Don't exempt yourself from the load you're delegating.
Benefits:
  • No single point of failure (bus factor)
  • Increased ownership and debugging skills across the team
  • Developers feel "we're in the same boat"
最有效的首次委派是日常运营工作——告警处理、支持请求、生产环境问题。
运作方式：
  • 每天/每周轮换一名团队成员担任“Team Rep”
  • Team Rep负责：监控告警渠道、协助支持团队、调试新问题、协调事件响应
  • Team Rep无需负责解决所有问题——引入bug的开发者负责修复。Team Rep仅负责协调和学习。
  • 管理者不是第一联系人，Team Rep才是。
设置技巧：
  • 将轮换安排添加到日历中，并编写书面指南文档
  • 首次轮换时，允许向你咨询，但绝不要亲自解决问题
  • 将自己也纳入轮换名单，不要豁免自己所委派的工作负担
好处：
  • 消除单点故障（bus factor）
  • 提升团队整体的责任感和调试技能
  • 让开发者感受到“我们同舟共济”

2. New Projects: Epic Ownership

2. 新项目：Epic Ownership模型

Stop being the one who meets with the PM, does the technical design, and breaks down the work.
How it works:
  • When a new epic arrives, assign a team member as the owner
  • They: meet with the PM, write the technical design, break it into tasks, decide work distribution
  • You: stay involved — share thoughts, ask questions, review — but they make the decisions
Each developer leads only one project at a time, so they can be 100% dedicated to it — often producing better designs than you rushing through five simultaneously.
不要再亲自对接PM、做技术设计和拆分工作。
运作方式：
  • 当有新的epic项目到来时，指派一名团队成员作为负责人
  • 他们负责：对接PM、撰写技术设计文档、拆分任务、决定工作分配
  • 你负责：参与其中——分享想法、提出问题、审查——但由他们做决策
每位开发者一次只负责一个项目，这样他们可以100%投入——通常能产出比你同时兼顾五个项目时更优质的设计。

Knowledge Ownership

知识所有权

If you're the go-to person for every system and every question, that's a problem. Divide the team's systems and applications across people with clear, explicit owners. When someone asks you about a system, redirect them to the owner.
如果你是所有系统和问题的首选联系人，这是个问题。将团队的系统和应用明确分配给不同的负责人。当有人向你询问某个系统时，引导他们去找对应的负责人。

Delegation Principles

委派原则

  • Never delegate 100% of an area. Stay in the rotation. Do the work yourself occasionally.
  • You can share at least 50% of your current work. The exceptions are fewer than you think.
  • Never solve it for them. When they're struggling, coach — don't rescue.
  • Match the task to the person's driver. When you delegate something that doesn't align with what motivates someone, they procrastinate and you end up nagging. When it aligns — they take ownership without being asked. A Connection-driven engineer will thrive as the team's interview coordinator; an Impact-driven one will take on the CS sprint you've been avoiding; a Growth-driven one will light up when you hand them an architectural decision. "Every task you don't like can be a growth opportunity for someone else." (See 
    engineer-motivation
    for how to identify each person's driver.)
  • 绝不要100%委派某个领域的工作。保留在轮换名单中，偶尔亲自处理相关工作。
  • 你至少可以分享当前50%的工作。例外情况比你想象的少。
  • 绝不要替他们解决问题。当他们遇到困难时，提供指导——而非直接接手。
  • 任务匹配人员的动机。当你委派的工作与某人的动机不符时，他们会拖延，你最终不得不催促。当工作与动机匹配时——他们无需被要求就会主动承担责任。注重联结的工程师会胜任团队面试协调员的工作；注重影响力的工程师会接手你一直回避的客户成功冲刺任务；注重成长的工程师在拿到架构决策任务时会充满热情。“你不喜欢的每项任务，对别人来说可能都是成长机会。”（查看
    engineer-motivation
    了解如何识别每个人的动机。）

Intent-Based Leadership

意图导向型领导力

From Turn the Ship Around (Marquet): instead of asking permission or waiting for direction, team members state their intent and proceed unless stopped.
The pattern: "I intend to deploy the release at 2pm — let me know if you see a reason not to." Instead of: "Should I deploy the release?"
Why it works: asking permission transfers ownership to the person being asked. Stating intent keeps ownership with the person acting, while still maintaining oversight. Over time, it trains the entire team to think like owners rather than executors.
How to implement it:
  • Model it yourself with your own manager: "I intend to finalize this hire — flag me if you have concerns" (this is also how you earn delegation upward)
  • When a report comes to you asking "should I do X?" — ask them what they intend to do and have them tell you. Then respond to their intent rather than making the decision for them
  • Reserve overrides for cases where you have information they don't. If you're overriding purely because you'd do it differently, ask whether that's worth the cost to their ownership
The goal: a team that moves without being told, rather than a team that waits to be told.
出自《Turn the Ship Around》（Marquet）：团队成员无需请求许可或等待指令，只需表明意图即可推进，除非被阻止。
模式示例：“我计划在下午2点部署版本——如果您有异议请告知我。” 而非：“我应该部署这个版本吗？”
为何有效：请求许可会将所有权转移给被询问者。表明意图则让行动者保留所有权，同时仍保持监督。久而久之，这会训练整个团队像所有者而非执行者一样思考。
实施方法：
  • 先以身作则，对你的上级使用该模式：“我计划完成这次招聘——如果您有顾虑请提醒我”（这也是向上委派的方式）
  • 当下属来问“我应该做X吗？”时——询问他们的计划并让他们告知你。然后针对他们的意图做出回应，而非替他们做决定
  • 仅在你掌握他们不知道的信息时才否决。如果仅仅因为你会用不同方式做就否决，要考虑这对他们的责任感造成的损失是否值得
目标：打造一个无需指令就能行动的团队，而非等待指令的团队。

Micromanagement vs. Under-management

微观管理vs管理不足

From The Dichotomy of Leadership (Willink): the failure modes on both ends of the delegation spectrum are equally real, and the symptoms are distinct.
Signs you're micromanaging:
  • You approve every decision before it moves forward
  • Team members stop bringing you problems because they expect you to solve them
  • You review and rewrite work that was "good enough"
  • No one acts when you're not available
  • Your calendar is full of unnecessary check-ins
Signs you're under-managing:
  • Tasks go off-track and you're the last to know
  • Team members make significant decisions without relevant context you had
  • Quality degrades or standards slip without you noticing
  • Work done by different people on the team is inconsistent in ways that matter
  • You find out about problems after they've become crises
Neither extreme is safe. The default assumption in engineering culture is that under-management is better than micromanagement — which leads many EMs to stay too hands-off and catch problems too late.
The right position moves depending on the person and the task (see Task-Relevant Maturity). But the diagnostic above gives you early signals before you've drifted too far in either direction.
出自《The Dichotomy of Leadership》（Willink）：委派范围两端的失败模式同样真实存在，且症状截然不同。
微观管理的迹象：
  • 每项决策都需经你批准才能推进
  • 团队成员不再向你汇报问题，因为他们认为你会直接解决
  • 你审查并重写“足够好”的工作成果
  • 你不在时无人行动
  • 你的日程排满了不必要的检查
管理不足的迹象：
  • 任务偏离轨道时你最后才知道
  • 团队成员在不了解你掌握的相关上下文的情况下做出重大决策
  • 质量下降或标准降低而你未察觉
  • 团队不同成员完成的工作存在重要差异
  • 问题演变为危机后你才得知
两种极端都不可取。工程文化中的默认假设是管理不足比微观管理好——这导致很多EM过于放任，太晚才发现问题。
合适的管理程度会根据人员和任务而变化（参见Task-Relevant Maturity框架）。但上述诊断能在你偏离正轨太远之前给出早期信号。

How Much Involvement Is Right: Task-Relevant Maturity

合适的参与度：Task-Relevant Maturity框架

Most managers stop at "juniors need more oversight, seniors less." That's still too blunt.
Andy Grove's concept from High Output Management: Task-Relevant Maturity (TRM) — not the person's general seniority, but their maturity for this specific task. A senior engineer doing something for the first time has low TRM for that task. A junior doing their fifth microservice has high TRM.
  • Low TRM → structured involvement: tell them what to do, check in regularly, be available
  • High TRM → step back: set the goal, let them work, trust the outcome
Getting this wrong in either direction is a failure:
  • Too hands-on with high TRM → micromanagement, demotivation
  • Too hands-off with low TRM → the customer (internal or external) pays for the mistake
When a task feels high-stakes, ask yourself: is this person's TRM actually high for this task — or just in general?
大多数管理者仅停留在“初级员工需要更多监督，高级员工需要更少”的层面。这仍然过于笼统。
Andy Grove在《High Output Management》中提出的概念：Task-Relevant Maturity (TRM)——不是指人员的总体资历，而是指他们在这项特定任务上的成熟度。首次接触某项工作的高级工程师在该任务上的TRM较低。完成第五个微服务开发的初级工程师在该任务上的TRM较高。
  • 低TRM → 结构化参与：告知他们要做什么，定期检查，保持可沟通状态
  • 高TRM → 退居幕后：设定目标，让他们自主工作，信任结果
无论哪个方向出错都是失败：
  • 对高TRM人员干预过多 → 微观管理，打击积极性
  • 对低TRM人员放任不管 → 客户（内部或外部）为错误买单
当任务风险较高时，问问自己：这个人在这项任务上的TRM真的很高吗——还是只是总体资历高？

Giving Engineers a Kingdom

为工程师划分“领域”

Beyond task delegation, each engineer should own a defined area — a kingdom with real decision-making authority, not just execution responsibility.
Four ownership types that work:
  1. An application or system — the owner drives the roadmap relationship with PM, monitors usage, and is the incident point-of-contact
  2. A microservice — health monitoring, technical debt prioritization, contributing guidelines
  3. A third-party integration — leads the vendor relationship, monitors release notes, tracks integration health
  4. An internal tool — the internal expert and champion, responsible for adoption and updates
The key distinction from task delegation: kingdom owners hold decision-making authority over their area. They prioritize, not just execute.
Aim for one to two kingdoms per engineer; spreading too many thin defeats the purpose. Start by identifying the areas that consume the most of your own time and transfer those first.
The framing matters: "ownership area" can feel like a burden of chores. "Kingdom" implies authority and pride — both affect whether engineers embrace or resist the responsibility.
除了任务委派，每位工程师都应该拥有一个明确的负责领域——一个拥有真正决策权限的“领域”，而非仅仅是执行责任。
四种有效的所有权类型：
  1. 应用或系统——负责人主导与PM的路线图沟通、监控使用情况，并作为事件联络人
  2. 微服务——健康监控、技术债务优先级排序、贡献指南制定
  3. 第三方集成——主导供应商关系、监控发布说明、跟踪集成健康状况
  4. 内部工具——内部专家和倡导者，负责工具的推广和更新
与任务委派的关键区别：领域所有者对其负责领域拥有决策权限。他们负责优先级排序，而非仅仅执行。
目标是每位工程师负责1-2个领域；分配过多会失去意义。从识别你自己花费时间最多的领域开始，先转移这些领域的所有权。
表述方式很重要：“负责领域”可能让人觉得是负担。“领域”意味着权威和自豪感——这两种感受会影响工程师是接受还是抗拒这份责任。

The Three-Layer Assignment Framework

三层分配框架

Work assignment operates across three layers that must be balanced simultaneously:
  • Efficiency — assign the most capable person for what's needed right now
  • Advancement — assign for growth and career trajectory, often at a speed cost
  • Durability — assign to prevent single-points-of-failure, even when neither efficiency nor growth is optimized
The knowledge map exercise makes the third layer concrete: plot engineers against skill/system areas to visualize coverage gaps and identify dangerous single-owner areas.
When moving engineers into new domains to serve advancement or durability, apply Task-Relevant Maturity (see above) — a Staff engineer new to a domain needs closer guidance than their title implies.
Two traps to watch: inertia (comfortable assignments calcify even when business needs change) and activation energy (the transition cost is real and must be planned for, not wished away). Revisit assignments deliberately every quarter rather than letting the last good decision run indefinitely.
工作分配需同时平衡三个层面：
  • 效率——分配给当前最胜任该工作的人员
  • 发展——为了成长和职业轨迹分配工作，通常会牺牲速度
  • 稳定性——分配工作以避免单点故障，即使效率和发展都未达到最优
知识图谱练习能让第三个层面具体化：将工程师与技能/系统领域对应起来，可视化覆盖缺口，识别存在危险单点所有者的领域。
当为了发展或稳定性让工程师进入新领域时，应用Task-Relevant Maturity框架（见上文）——刚接触新领域的Staff工程师比其头衔暗示的需要更多指导。
需要注意两个陷阱：惯性（即使业务需求变化，舒适的工作分配仍固化不变）和启动成本（过渡成本真实存在，必须提前规划，而非忽略）。每季度主动重新审视工作分配，而非让之前的合理决策无限期延续。

Dive Deeper

深入学习

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic — read 
references/sources.md
 for the full list of source articles (with links) and books.
如果用户询问框架的来源、想要阅读原文或了解任何主题的更多上下文——阅读
references/sources.md
获取完整的来源文章（含链接）和书籍列表。

Related Skills

相关技能

  • managing-yourself
    — Over-involvement is trap #5 in the 10 ways EMs get stuck
  • engineer-motivation
    — Identifies each engineer's driver for motivation-aligned delegation
  • managing-yourself
    — 过度参与是EM陷入困境的10种方式中的第5种
  • engineer-motivation
    — 识别每位工程师的动机，以便进行匹配动机的委派