Recover a team stuck in reactive mode
Recover by making interruption load visible, reducing hidden priority channels, protecting planning capacity, and converting repeated reactive patterns into owned, managed work.
- Situation
- A team spends most of its time handling interruption, urgency, and spillover work.
- Goal
- Move the team from endless reaction toward a more deliberate, sustainable operating rhythm.
- Do not use when
- the team is temporarily in true incident or launch mode and the reactivity is expected
- Primary owner
- engineering manager
- Roles involved
engineering managertech leaddelivery leadproduct partnersupport or operations partner if interrupts originate there
Context
The situation
Deciding whether to reach for this playbook: when it fits, and when it doesn't.
Use when
Conditions where this playbook is the right tool.
- Planned work is regularly displaced by interrupts
- The team feels permanently busy but not effective
- Retros repeatedly mention urgency, switching, and unclear priorities
- People cannot remember the last time the team had stable focus
Stakes
Why this matters
What this playbook protects against, and why skipping or half-running it tends to be expensive.
Reactive teams lose more than productivity. They lose confidence, decision quality, learning time, and often their ability to tell what is actually important versus merely loud.
Quality bar
What good looks like
The observable qualities of a team or system that is actually doing this well. Not just going through the motions.
Signs of the playbook done well
- Interruptions are visible and categorized
- The team has fewer surprise priority channels
- Some capacity is protected for planned work and prevention work
- Repeat urgent patterns become managed workstreams
- The team can explain its operating mode with evidence rather than fatigue language
Preparation
Before you start
What you need available and true before running the procedure. Skipping this is the most common reason playbooks fail.
Inputs
Material you'll want to gather first.
- Interrupt history
- Current backlog and commitments
- Sources of urgent work
- Incident/support patterns
- Team capacity profile
- Recent retro themes
Prerequisites
Conditions that should be true for this to work.
- The team can observe or reconstruct interruption patterns
- Someone can influence intake and prioritization
- The team is willing to stop normalizing reactivity
Procedure
The procedure
Each step carries its purpose (why it exists), its actions (what you do), and its outputs (what you produce). Read the purpose. It's what keeps the step from degenerating into checklist theatre.
Expose the real interrupt system
Make the hidden operating model visible.
Actions
- Track what interrupts the team, from whom, and how often
- Identify hidden priority channels and escalation paths
- Estimate how much planned work is displaced
Outputs
- Interrupt map
- Priority channel inventory
Separate urgent from unmanaged
Stop every repeated pain from wearing the same urgent label.
Actions
- Classify interrupts into true emergencies, recurring urgent classes, and weakly filtered asks
- Identify the categories that should become managed work
- Challenge urgency inflation with evidence
Outputs
- Interrupt taxonomy
Protect focus and prevention capacity
Create room for the team to stop living only in response mode.
Actions
- Reserve some capacity for planned work and recurrence reduction
- Reduce simultaneous priority streams
- Assign a visible interrupt owner where that helps contain switching
Outputs
- Capacity protection model
Tighten intake and escalation
Reduce the number of ways work can become urgent by social force alone.
Actions
- Define what qualifies as urgent
- Create a simpler intake path for non-urgent asks
- Ensure leadership and partner teams know the new model
Outputs
- Urgency and intake policy
Review whether the team is regaining control
Make recovery visible and durable.
Actions
- Track changes in interruption rate, focus time, and repeat pain
- Review whether planned work completion stabilizes
- Continue converting recurring interrupt classes into owned work
Outputs
- Reactivity recovery review
Judgment
Judgment calls and pitfalls
The places where execution actually diverges: decisions that need thought, questions worth asking, and mistakes that recur regardless of good intent.
Decision points
Moments where judgment and trade-offs matter more than procedure.
- What interrupts are truly urgent?
- Which recurring urgent patterns deserve prevention work first?
- How much protected capacity is realistic right now?
- Who has the authority to reject weakly filtered priority demands?
Questions worth asking
Prompts to use on yourself, the team, or an AI assistant while running the procedure.
- What actually interrupts this team most often?
- Which interrupts are real emergencies versus unmanaged repeat pain?
- What priority channels need to be closed or controlled?
Common mistakes
Patterns that surface across teams running this playbook.
- Calling for better prioritization without changing intake channels
- Expecting the team to self-protect against leadership-driven urgency
- Trying to eliminate all interrupts instead of managing the system
- Ignoring support and operational sources of churn
Warning signs you are doing it wrong
Signals that the playbook is being executed but not landing.
- The team still says everything is urgent after the reset
- Planned work is still displaced but nobody can explain by what
- Interruptions are better logged but not better controlled
- Leaders still route around the new intake and priority model
Outcomes
Outcomes and signals
What should exist after the playbook runs, how you'll know it worked, and what to watch for over time.
Artifacts to produce
Durable outputs the playbook should leave behind.
- Interrupt map
- Priority channel inventory
- Interrupt taxonomy
- Capacity protection model
- Urgency and intake policy
- Reactivity recovery review
Success signals
Observable changes that mean the playbook landed.
- The team finishes more planned work predictably
- Recurring interrupt categories start shrinking
- People describe the system of work more clearly and less emotionally
- Retros shift from helplessness toward controllable action
Follow-up actions
Moves that keep the playbook's effects compounding after it finishes.
- Promote repeated interrupt classes into operational or architecture improvement plans
- Review whether staffing or ownership changes are needed
- Keep interrupt visibility alive after the first improvement cycle
Metrics or signals to watch
Longer-horizon indicators that the underlying problem is receding.
- Interrupt count by source
- Planned work displacement rate
- Repeat urgent class frequency
- Focus time or uninterrupted work blocks
- Team confidence in its ability to plan
AI impact
AI effects on this playbook
How AI-assisted and AI-driven workflows help execution, and the ways they can make it worse.
AI can help with
Where AI tooling genuinely reduces the cost of running this playbook well.
- Clustering interrupts and recurring urgent classes from chat, tickets, and incidents
- Summarizing hidden priority channels from work history
- Drafting intake rules and escalation summaries
AI can make worse by
Distortions AI introduces that make the underlying problem harder to see.
- Increasing the volume of polished incoming asks
- Making reactivity sound well-managed through better summaries
- Creating more activity without reducing system load
Relationships
Connected playbooks
Failure modes this playbook tends to address, decisions behind the situation, red flags that motivate running it, and neighboring playbooks.