Incident Response Intermediate By Samson Tanimawo, PhD Published Aug 22, 2026 5 min read

Incident Roles When You Only Have 5 Engineers

The four-role IC playbook assumes a 50-engineer org. On a five-engineer team, the same roles still exist, just doubled and tripled up. The minimal viable version.

Why the four-role playbook fails small teams

The classic incident playbook has IC, Operations, Communications, Scribe, four named people. On a five-engineer team that means everyone is on the bridge plus the team has nobody left to actually fix the bug. The playbook needs compression.

The deeper issue: the four-role playbook was designed for organisations that have dedicated incident-response personnel. Most small teams don't have a Comms Lead or a Scribe role; the engineers do all the work. Trying to artificially split into four roles when you only have four engineers produces theatre, not coordination.

The right frame: small teams need the FUNCTIONS of the four roles, not the bodies. One person can perform two functions if the functions are compatible. The IC and Comms function are highly compatible (both involve consolidating + writing). The IC and Scribe function are highly compatible (the IC's running summary IS the timeline). The Operations function, actually doing the technical work, is incompatible with IC, because IC requires sustained coordination focus.

The two-role minimum

Two people minimum. One does coordination, one does technical. Both responsibilities need their own brain. Trying to be both IC and primary debugger simultaneously is the most common small-team mistake, within twenty minutes the bridge has no IC and the technical work has stalled because the engineer is being interrupted by coordination demands.

The IC + Driver pattern works for SEV2 incidents on a 5-engineer team. SEV1 incidents need at least one more body. SEV3 incidents can sometimes be handled by a single engineer playing both roles (IC-light: just keep the channel updated, no formal cadence).

Triple-hatting cleanly

The IC also does comms. They post the customer update at the 10-minute cadence. They also scribe, the IC's running summary IS the timeline. Three responsibilities on one person, but they reinforce each other (writing the comms forces the IC to consolidate; scribing forces them to stay aware).

The compatibility between these three roles is what makes triple-hatting work. Each one produces text. Each one requires consolidating the team's current state. Each one rewards calmness over speed. They're not three different mental modes; they're three outputs of the same mental mode.

What does NOT work: triple-hatting IC + Comms + Driver. Driver is hands-on-keyboard work; IC and Comms are coordination work. Doing both simultaneously means the IC is typing into a terminal, missing the bridge conversation, and the comms post is 20 minutes late. If you only have one person, pick: are they IC (and someone else drives) or Driver (and the bridge runs without an IC)? IC wins almost every time, because the bridge with no IC degrades faster than the technical work with no Driver.

Rotation on long incidents

If the incident runs past 90 minutes, swap the IC. Cognitive load on an IC is high; an exhausted IC misses things. The new IC takes over the channel; the previous IC becomes a debugger or rests for an hour.

The signs that a swap is needed. The IC's status updates are getting shorter and less specific. The IC is starting to repeat themselves. The IC is no longer asking probing questions. The IC has gone silent for 5+ minutes. Each is a signal that the cognitive battery is drained.

The swap protocol. The current IC says: "I'm handing IC to NAME at the top of the next status update. NAME, do you accept?" The new IC says yes out loud. The bridge topic updates. The current IC posts a final consolidated summary; the new IC reads it before saying "I have IC." Two minutes; the bridge restarts with fresh focus.

Antipatterns to avoid

One person doing everything. The bridge falls apart at minute 45. The engineer is exhausted, the comms are stale, the technical work has stalled. By minute 90 the team has accumulated more cost than two engineers from minute one would have. The "I can handle this alone" instinct is wrong almost every time.

No formal IC. The bridge has three theories competing forever. Engineers debate technical merits; nobody decides which to investigate first. By the time the team converges, an hour is gone. Naming an IC, even reluctantly, saves 30+ minutes on most multi-theory incidents.

The CTO joining and quietly becoming IC. Senior leaders who join a bridge often take over by virtue of seniority. This sounds helpful and is usually harmful: the on-call team loses ownership, can't push back on the CTO's preferred theory, and learns to defer instead of lead. If a senior leader joins, they should explicitly say "I'm here to support, not to drive" and let the named IC continue.

The IC who is also the senior debugger. Common because senior engineers are often the most knowledgeable about the service. The trap: as soon as the senior IC starts debugging, the bridge loses coordination. If your most senior engineer is on the bridge, give them the Driver role and let a less-senior engineer be IC. The IC role isn't about technical knowledge; it's about coordination focus.

Onboarding new ICs

The first time a new engineer is IC, they should pair with an experienced IC who has the role formally; the new engineer shadows for the first 30 minutes, takes over for the next 30, and the experienced IC stays on the bridge as a safety net. Three or four such co-incidents and the new IC can run solo.

What new ICs find hardest. Saying "I'm IC" out loud. Telling senior engineers to stop debugging because the bridge is going sideways. Writing customer comms when the situation is still ambiguous. Each of these gets easier with practice; none of them is innate. Most teams that struggle to develop ICs simply haven't given anyone the opportunity to be one.

The practice exercise. Run a tabletop quarterly: a fictional incident scenario, a new IC takes the role, the rest of the team plays out the bridge. Costs an hour; produces an IC who has practised the awkward parts before they hit a real 3am scenario.

What to do this week

Three moves. (1) Identify your team's IC bench: who has run a SEV2+ as IC in the last quarter? If the answer is 1-2 people, you have an IC depth problem; expand the bench by pairing junior engineers with senior ICs over the next two quarters. (2) Document the IC + Driver pattern in your incident playbook explicitly, most small-team playbooks copy the four-role version and produce confusion. (3) Schedule a tabletop next sprint: pick a SEV2-shaped scenario, name a new IC, run it for 30 minutes. The first tabletop reveals what the team didn't know it didn't know.