The Team Lead Handbook · Running the Team's Work

Handling Interruptions and Support Rotations

Protect focus while still responding to support requests and incidents: a rotation that absorbs interruptions, with a model of how many the team can handle.

Scenario

Example team: the platform team (five engineers) supports twelve product teams. Questions arrive in a shared channel all day; whoever sees one first answers. Everyone is interrupted several times an hour. Planned work barely moves and two engineers say they feel burned out.

What you see on the team

  • Constant pings; nobody gets a focused hour.
  • The most helpful engineers answer most questions — and fall behind on their own work.
  • Planned items take two to three times longer than estimated.
  • Requests are lost in chat; some get answered twice, some never.

The common mistake

Sharing interruptions across everyone, so the whole team works in fragments instead of one person handling them.

Why it happens

Answering quickly feels responsive and kind. But interruptions are expensive: each one breaks concentration, and the cost lands on everyone. Without a rotation, the most conscientious people take the most load — a fast route to burnout. Incident practice offers a model: PagerDuty's public incident response docs describe explicit on-call rotations with clear handovers.

The playbook

One person on rotation ("support" or "interrupt" duty) for a week:

  • handles incoming questions, small requests and first-line incidents;
  • takes no planned sprint work;
  • improves documentation and automation for repeated questions.

One front door: a request form or channel with a template; nothing in DMs.

Clear service levels: e.g. first response within four working hours for questions; immediate for incidents.

Track the load to decide when one person isn't enough:

Interrupt load: is one person on support enough?Try it yourself
import random

random.seed(3)
HOURS_PER_WEEK = 35
weeks = 8

# Requests per week from 12 product teams (example) and time per request in hours
for teams_growth in (1.0, 1.5):
    loads = []
    for _ in range(weeks):
        requests = sum(random.randint(1, 4) for _ in range(int(12 * teams_growth)))
        hours = sum(random.choice([0.25, 0.5, 0.5, 1, 2]) for _ in range(requests))
        loads.append(hours)
    avg, peak = sum(loads) / weeks, max(loads)
    print(f"{int(12 * teams_growth)} teams: avg {avg:4.1f} h/week, peak {peak:4.1f} h "
          f"-> {avg / HOURS_PER_WEEK:.0%} of one person (peak {peak / HOURS_PER_WEEK:.0%})")

Output

12 teams: avg 25.2 h/week, peak 33.5 h -> 72% of one person (peak 96%)
18 teams: avg 39.2 h/week, peak 45.0 h -> 112% of one person (peak 129%)

When the rotation is consistently above ~70% of a person's week, add a second person, reduce demand (self-service, docs), or renegotiate scope.

Hand over at the end of each rotation: open requests, recurring themes, ideas for automation.

Turn repeats into products: the top three repeated questions each month become documentation or self-service tooling.

What to say

Introducing the rotation:

"Starting Monday, one of us is on support each week and takes no sprint work. Everyone else mutes the support channel. Requests go through the form so nothing gets lost. Let's review in a month: load, response times and how focused the rest of the week felt."

To a product team bypassing the process:

"Happy to help — could you put it in the support form? This week Lee is on rotation and will pick it up within four hours. It keeps the rest of us focused on the migration you're waiting for."

Trade-offs

  • Support week can feel like a punishment; rotate fairly, include the lead, and value the automation work done during it.
  • Slower answers for non-urgent questions are the price of focus; clear service levels make this acceptable.
  • Context loss between rotations; written handovers fix most of it.

Signals it's working

  • Planned work estimates become accurate again.
  • Response times meet the agreed levels.
  • Repeated questions decline as docs and self-service appear.
  • Engineers report more focused time.

Key points

  • Concentrate interruptions on one person per rotation instead of everyone.
  • One front door, clear service levels, written handovers.
  • Track load; above ~70% of a person's week, add capacity or reduce demand.
  • Turn the most frequent requests into documentation and self-service.

Practice questions

Your team is interrupted all day by support questions. What's your structural fix?

Answer

Create a weekly support rotation: one person handles all requests through a single front door with clear response times and takes no sprint work; everyone else focuses. Track load and turn repeated requests into self-service.

How do you know when one person on support isn't enough?

Answer

When measured support load is consistently above roughly 70% of a person's week or response times slip; then add a second person, reduce demand with self-service, or renegotiate scope.

What should happen at the end of a support rotation?

Answer

A written handover: open requests, recurring themes and ideas for automation or documentation, so the next person starts with context and repeats get fixed.

Open in the app to mark lessons complete, take notes and track your progress.