Context switching has a recovery cost

While debugging, I may hold a request path, several possible causes, and the logs that can separate them. A message takes thirty seconds to answer. Returning to the bug means rebuilding that model, and the recovery carries most of the interruption cost.

Complex work lives partly in memory before it reaches code or documentation. During a production failure, the working model may include recent releases, service boundaries, data flow, timing, and discarded hypotheses. Architecture work holds constraints and the consequences of several choices. Writing holds the argument and the purpose of each section.

An interruption evicts parts of that state. The engineer returns by rereading code, piecing together assumptions, and checking which facts were already tested. Calendar time misses this recovery. Eight available hours produce little continuity when meetings and messages divide them into short fragments.

Teams create response expectations through repeated behavior. Someone answers quickly, receives praise, and keeps chat open. Others copy the pattern. A normal question starts to feel urgent because no shared rule says when a reply is due.

Define a fast path for incidents and a response window for routine work. Give urgent operational work one channel or rotation. Store project updates where the team can find them. Give decisions clear owners and protect calendar blocks from optional meetings. These rules prevent each person from interpreting every notification alone.

Some switches are unavoidable. Before leaving a complex task, record:

  • the current goal
  • established facts
  • rejected hypotheses
  • the next useful check
  • local state that could disappear

Two minutes of notes can preserve an hour of reasoning. Keep the handoff close to the work in an issue, draft, or temporary investigation file. Put other open tasks in a trusted system so they can wait for the time assigned to them.

Batch messages, small reviews, and administrative work into defined windows. Group related reviews so codebase context remains useful. Limit the number of active projects each engineer carries.

An on-call rotation protects the rest of the team by giving interrupts a clear owner. Plan a lower project load for the person on call because interruption handling is already real work.

Meetings should produce a decision or useful file. Use an agenda and invite the people required for that outcome. Send context early and let people decline when their input can arrive asynchronously. Schedule related meetings together when possible. Afterward, record the decision, owner, and next review point.

Attention is part of the production system. Set work-in-progress limits. Rank projects so each new request has a visible tradeoff. Track recurring interruptions and remove their causes through better ownership, documentation, automation, or staffing. Protect enough continuous time for complex models to become useful code, decisions, and writing.