Back to Details

shadow-work

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Shadow Work

Shadow Work

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

如何使用此技能

  • Team misses commitments but everyone seems busy -> diagnose all three shadow-work types and identify the dominant capacity drain
  • Ad-hoc incidents and support requests eat capacity -> start with Type 1: Invisible Production Support
  • Senior engineers burn out doing unglamorous coordination -> start with Type 2: Glue Work
  • Off-the-record requests quietly consume sprints -> start with Type 3: The Shadow Backlog
  • Remote team has weak visibility into what people actually absorb -> include The Remote Amplification Problem
  • 团队无法兑现承诺但全员看似忙碌 -> 诊断所有三类Shadow Work类型，找出主导的产能消耗因素
  • 临时事件和支持请求占用产能 -> 从Type 1：隐形生产支持入手
  • 资深工程师因从事乏味的协调工作而burnout -> 从Type 2：粘合性工作入手
  • 非正式请求悄悄消耗迭代资源 -> 从Type 3：影子待办事项入手
  • 远程团队对成员实际承担的工作缺乏可见性 -> 纳入远程放大问题的考量

Default Response Shape

默认回复结构

When the user asks for help, do not only explain the concept. Produce a practical diagnosis:
  1. Likely shadow-work type - name the type(s), with confidence and evidence from the user's prompt.
  2. What to measure for 2-6 weeks - lightweight signals, not a heavy process rollout.
  3. Immediate containment - what to do this week so the team stops bleeding capacity.
  4. Structural fix - what to change in planning, ownership, rotation, recognition, or PM/EM workflow.
  5. Stakeholder message - a concise script the EM can use with PMs, leadership, or the team.
If the user's facts are thin, ask for the minimum missing data: where the work comes from, who absorbs it, how often it happens, and whether it is currently tracked anywhere.
当用户寻求帮助时，不要仅解释概念，需给出实用的诊断结果：
  1. 可能的Shadow Work类型 - 明确类型，结合用户提示中的信息说明置信度和依据。
  2. 未来2-6周的测量内容 - 采用轻量化的信号指标，无需推行复杂流程。
  3. 即时遏制措施 - 本周可采取的行动，阻止团队持续流失产能。
  4. 结构性修复方案 - 在规划、职责分配、轮岗机制、认可机制或PM/EM工作流程上需做出的调整。
  5. 利益相关方沟通话术 - 经理可用于与PM、管理层或团队沟通的简洁脚本。
如果用户提供的信息不足，询问必要的缺失数据：工作来源、承担人员、发生频率，以及当前是否有任何追踪记录。

What Shadow Work Is

Shadow Work是什么

Shadow work is untracked work that consumes real capacity but does not appear in the plan. It makes teams consistently miss commitments without anyone understanding why. It falls into three types, and each type requires a different response.
The key management move is not "work harder" or "estimate better." The first move is to make the work legible enough that the team can make tradeoffs honestly.
Shadow Work（影子工作）是指未被追踪的工作，它会消耗实际产能但未出现在计划中。这会导致团队持续无法兑现承诺，却没人明白原因。它分为三种类型，每种类型需要不同的应对方式。
核心管理举措不是“更努力工作”或“更精准估算”。第一步是让这类工作足够清晰可见，以便团队能诚实地做出权衡。

Diagnostic Questions

诊断问题

Use these questions before prescribing fixes:
  • Source: Where does the unplanned work come from: production, other teams, PM requests, managers, engineers, customers, or the codebase itself?
  • Absorber: Who usually handles it? Is it evenly distributed, or does it concentrate on one or two senior people?
  • Visibility: Does it appear in tickets, sprint boards, incident logs, review docs, or performance reviews?
  • Pattern: Is it recurring, seasonal, project-specific, or random?
  • Cost: Does it mostly cost calendar time, focus time, emotional energy, roadmap capacity, or promotion credit?
  • Tradeoff: What planned work silently loses when this work appears?
在提出修复方案前，先使用以下问题收集信息：
  • 来源： 未计划的工作来自何处：生产环节、其他团队、PM请求、经理、工程师、客户，还是代码库本身？
  • 承担者： 通常由谁处理这些工作？是均匀分配，还是集中在一两位资深人员身上？
  • 可见性： 这些工作是否出现在工单、迭代看板、事件日志、评审文档或绩效评估中？
  • 模式： 是重复发生、季节性、项目特定，还是随机出现？
  • 成本： 主要消耗的是日程时间、专注时间、情绪精力、路线图产能，还是晋升积分？
  • 权衡： 当这类工作出现时，哪些计划内的工作会被悄悄牺牲？

Type 1: Invisible Production Support

Type 1：隐形生产支持

Ad-hoc incident triage, alert investigation, support-team requests, manual fixes, and customer escalations that never enter the ticket system.
Without tracking, patterns go unnoticed. The same 15-minute manual fix can burn hundreds of hours annually while the root cause stays unfixed. The team appears to have capacity but consistently underdelivers, and has no data to show why.
What to do:
  • Create a lightweight category for unplanned support work, even if it is only a tag in the ticketing system
  • Track for 4-6 weeks, then run a frequency analysis: top recurring issues, top request sources, top absorbers
  • Rotate hot-fix responsibility instead of letting one person become the permanent human circuit breaker
  • Convert repeated manual fixes into roadmap items with a visible cost-of-delay argument
指从未进入工单系统的临时事件分类、告警排查、支持团队请求、手动修复和客户升级问题。
如果不进行追踪，模式就会被忽视。同样的15分钟手动修复每年可能消耗数百小时，而根本问题却始终未得到解决。团队看似有产能却持续交付不足，且没有数据能说明原因。
应对措施：
  • 为非计划支持工作创建一个轻量化分类，哪怕只是工单系统中的一个标签
  • 追踪4-6周，然后进行频率分析：找出最常出现的问题、主要请求来源和主要承担人员
  • 轮换热修复职责，避免让某个人成为永久的“人工断路器”
  • 将重复的手动修复转化为路线图事项，并附上明确的延迟成本论证

Type 2: Glue Work

Type 2：粘合性工作

Code reviews, mentoring, onboarding, documentation, coordination, cross-team translation, and "can you just help them unblock?" work that lands disproportionately on senior engineers.
Glue work creates two problems when unmanaged: the engineers doing it burn out without recognition, and the engineers not doing it get promoted without learning the work that keeps the organization functioning.
What to do:
  • Name glue work explicitly in performance conversations and promotion packets
  • Distribute the skills downward through pairing, live review sessions, office hours, and rotating ownership
  • Protect senior engineers' maker time when they are acting as multipliers
  • Track whether glue work is becoming a default identity for one person rather than a shared team capability
指代码评审、指导、入职培训、文档编写、协调工作、跨团队沟通翻译，以及“你能不能帮他们解决阻塞问题？”这类工作，这些工作大多落在资深工程师身上。
如果不对粘合性工作进行管理，会产生两个问题：从事这类工作的工程师会因得不到认可而burnout，而不从事这类工作的工程师却能在未掌握维持组织运转所需技能的情况下获得晋升。
应对措施：
  • 在绩效对话和晋升材料中明确提及粘合性工作
  • 通过结对编程、实时评审会议、办公时间和轮换职责，向下传递相关技能
  • 当资深工程师发挥multiplier（倍增器）作用时，保护他们的专注工作时间
  • 追踪粘合性工作是否成为某个人的默认职责，而非团队共享的能力

Type 3: The Shadow Backlog

Type 3：影子待办事项

Work outside the official roadmap: PMs making off-the-record fix requests, engineers taking longer routes they know are right, unplanned integrations negotiated directly with other teams, and "small asks" that never look small in aggregate.
This can quietly consume a large share of real capacity while breaking trust between business and engineering. Leadership sees a team that commits and misses, without seeing where the capacity went.
What to do:
  • In planning, ask: "What are we likely to get asked to do that we have not scoped?"
  • Budget explicit shadow capacity when the environment is noisy; start with 10-20% if you lack data
  • Redirect off-the-record PM requests into the official backlog without shaming the requester
  • Periodically present shadow backlog data to stakeholders as evidence for roadmap tradeoffs
指官方路线图之外的工作：PM提出的非正式修复请求、工程师选择他们认为正确的更长路径、与其他团队直接协商的非计划集成，以及单个看似微小但累积起来规模不小的“小请求”。
这类工作会悄悄消耗大量实际产能，同时破坏业务与工程团队之间的信任。管理层看到的是一个承诺却无法兑现的团队，却不知道产能去向何方。
应对措施：
  • 在规划阶段询问：“哪些我们尚未界定范围的工作可能会找上门？”
  • 在环境多变时预留明确的影子产能；如果缺乏数据，先从10-20%开始
  • 将PM的非正式请求引导至官方待办事项中，不要指责请求者
  • 定期向利益相关方展示影子待办事项的数据，作为路线图权衡决策的依据

The Remote Amplification Problem

远程放大问题

For remote teams, shadow work is doubly invisible: your manager cannot casually observe it either. This means you have no natural evidence when advocating for a team member's raise or promotion, and weak visibility when capacity is being consumed.
Building lightweight tracking habits is therefore management infrastructure, not overhead. It protects the team's ability to get credit for real work and gives the EM evidence for capacity conversations.
对于远程团队而言，Shadow Work的隐形性加倍：经理也无法通过日常观察发现这类工作。这意味着在为团队成员争取加薪或晋升时，你没有天然的证据；在产能被消耗时，可见性也很弱。
因此，建立轻量化的追踪习惯是管理基础设施，而非额外负担。它能保护团队为实际工作获得认可的能力，也能为EM提供产能沟通的证据。

Stakeholder Scripts

利益相关方沟通话术

Use direct, non-accusatory language. The goal is to expose the tradeoff, not blame the source of the work.
With a PM: "I want to make these requests visible because they are real work. If we keep handling them outside the backlog, we will keep missing the planned roadmap and neither of us will have good data. Let's add them to the board and decide what they displace."
With leadership: "The team is not missing commitments because the estimates are careless. We are absorbing unplanned work that is not represented in the plan. I am going to track it for the next few weeks and come back with the recurring sources, cost, and options."
With a senior engineer doing too much glue work: "I see how much coordination and review work you are absorbing. Some of it is valuable, but I do not want it to become invisible or trap you away from growth work. Let's decide what should be recognized, rotated, or stopped."
使用直接、无指责性的语言。目标是揭示权衡关系，而非指责工作来源。
与PM沟通： “我希望让这些请求变得可见，因为它们是真实的工作。如果我们继续在待办事项之外处理这些请求，我们会持续无法完成计划中的路线图，而且我们双方都没有可靠的数据。让我们把它们添加到看板上，然后决定要替换掉哪些工作。”
与管理层沟通： “团队无法兑现承诺并非因为估算草率。我们一直在处理未被纳入计划的非预期工作。我将在接下来几周内追踪这些工作，之后会反馈重复出现的来源、成本和解决方案选项。”
与承担过多粘合性工作的资深工程师沟通： “我看到你承担了大量的协调和评审工作。其中一些很有价值，但我不希望这些工作变得隐形，也不希望它们让你无法专注于成长型工作。让我们一起决定哪些工作应该得到认可、轮岗或停止。”

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
。

Related Skills

相关技能

  • roadmap-planning
    - Shadow work should be explicitly budgeted in capacity planning, not ignored
  • working-with-pm
    - Off-the-record requests are a PM-EM relationship problem, not just a capacity problem
  • retaining-developers
    - Senior engineers absorbing invisible glue work without recognition are in the "unappreciated" retention state
  • knowledge-sharing
    - Glue work often overlaps with documentation and onboarding failures
  • roadmap-planning
    - Shadow Work应在产能规划中明确预留，而非被忽视
  • working-with-pm
    - 非正式请求是PM-EM关系问题，而非单纯的产能问题
  • retaining-developers
    - 承担隐形粘合性工作却得不到认可的资深工程师处于“未被赏识”的留存风险状态
  • knowledge-sharing
    - 粘合性工作往往与文档编写和入职培训的不足相关