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.

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

---

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

---

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.

---

What Shadow Work Is

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.

---

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?

---

Type 1: Invisible Production Support

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

---

Type 2: Glue Work

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

---