.agents/em-context.md

.agents/em-context.md

.agents/reports/[name].md

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.

• 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

• 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

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.

• 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?

• 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

• 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

• 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

• 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