manager-dot-dev 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:
- Likely shadow-work type - name the type(s), with confidence and evidence from the user's prompt.
- What to measure for 2-6 weeks - lightweight signals, not a heavy process rollout.
- Immediate containment - what to do this week so the team stops bleeding capacity.
- Structural fix - what to change in planning, ownership, rotation, recognition, or PM/EM workflow.
- 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
Type 3: The Shadow Backlog
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
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.
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."
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.
Related Skills
roadmap-planning- Shadow work should be explicitly budgeted in capacity planning, not ignoredworking-with-pm- Off-the-record requests are a PM-EM relationship problem, not just a capacity problemretaining-developers- Senior engineers absorbing invisible glue work without recognition are in the "unappreciated" retention stateknowledge-sharing- Glue work often overlaps with documentation and onboarding failures