# Team Building Activities for Engineers: Incident Practice

- Author: Bomb Appétit (https://bombappetit.com)
- Published: 2026-10-20
- Category: Remote teams
- Canonical: https://bombappetit.com/blog/team-building-activities-for-engineers-incident-practice

> Team building activities for engineers that feel like on-call: a bomb with a manual, a timer and strikes, and what a software team can take from each round.
Team building activities for engineers land best when they resemble the job. A bomb defusal round does: one person sees a failing system, the others hold a runbook they must read under a clock, and every wrong action costs something. Engineers who roll their eyes at trust falls take a strike seriously, and the habits carry into on-call.

## Why team building activities for engineers should feel like real work

Team building activities for engineers should feel like real work because engineers judge an activity by whether it exercises a skill they use. A quiz about favourite films does not. A timed problem, solved by talking through partial information under pressure, does, and the team leaves with something to discuss at the next retro.

Most software teams already have a shared ritual that looks like a game: the incident. Someone sees a symptom. Someone else knows where the runbook is. A third person keeps track of what has been tried. The best incidents are calm, clear and short. The worst are five people talking at once while one person types.

A bomb defusal round reproduces that shape without the production outage. In Bomb Appétit, the Defuser is the only player who can see the bomb and the only one who can act on it. The Experts have the manual, which holds every rule, and cannot see the bomb. A timer counts down. Each mistake is a strike, and strikes make the timer run faster. Three strikes, by default, ends the round.

That is close enough to an incident that the parallels are obvious to engineers without anyone pointing them out. It is also far enough from work that a mistake is funny rather than career-limiting.

The practical side suits engineering teams too. It runs in a browser with no install, which matters on locked-down work laptops. It is free and needs no account. And because every run is verified by replay, the sceptic on the team can trust the board without taking anyone's word for it.

## The bomb as an incident drill: runbook, pager and timer

The bomb works as an incident drill because each part of a round maps onto a part of incident response. The manual is the runbook. The Defuser is the engineer with access to the system. The timer is the clock on the outage. Needy modules behave like alerts that keep firing while you work on the main problem.

The mapping table below lines up incident response with the bomb. The right-hand column names the habit each row practises. It is a way of framing the round for a team, not a claim that the game teaches incident management on its own.

| Incident response               | In the bomb round                                 | Habit it practises                                          |
| ------------------------------- | ------------------------------------------------- | ----------------------------------------------------------- |
| Runbook                         | The manual, generated from a rule seed            | Finding the right page fast instead of reading from the top |
| Incident commander              | A lead Expert who decides which module comes next | One person setting priorities so the others can execute     |
| Engineer with production access | The Defuser, the only one who can touch the bomb  | Describing what you see before acting on it                 |
| Alert that keeps firing         | A needy module that wakes up during the round     | Handling an interruption without dropping the main task     |
| A failed fix                    | A strike                                          | Stopping to re-check the facts after a mistake              |
| Time-to-resolve pressure        | The timer, which speeds up after each strike      | Keeping calm when the cost of error is rising               |
| Shared incident channel         | The call where everyone hears the same words      | Saying things once, clearly, for everyone                   |

The incident commander row is the one most teams skip, and it is the one that matters most. Without a lead Expert, the other Experts all start reading different pages at once and the Defuser gets three instructions at the same time. Pick one Expert to say "Wires next" and the round calms down.

The needy module row deserves its own session. Needy modules cannot be solved. They wake up now and then and need attention until the rest of the bomb is done, and ignoring one too long earns a strike. The question of [who should watch the needy modules](/blog/needy-modules-never-stay-solved#who-should-watch-the-needy-modules) is the same question as who watches the dashboards during an incident.

## What do engineers practise as the bomb's Defuser and as Experts?

As the Defuser, an engineer practises reporting a system's state precisely to people who cannot see it, then acting only on a confirmed instruction. As an Expert, an engineer practises reading reference material under time pressure and turning a rule into one unambiguous command. Both skills show up in every on-call shift.

The Defuser's job is mostly observation. Before anything else, they read the edgework: the serial number, batteries, indicators and ports on the sides of the bomb. Rules in the manual refer to these details all the time. A Defuser who reads them out early saves the Experts from asking later, just as an on-call engineer who pastes the error message and the version number saves a round of questions.

Then the Defuser describes one module at a time, in order, without guessing at the answer. "Four wires: red, blue, blue, white" is a good description. "I think I need to cut the blue one" is not, because it skips the part the Experts need.

The Expert's job is lookup and translation. The manual for a given rule seed has a page per module, and each page is a set of conditions. A rule might depend on the colour of the last wire or whether the serial number ends in an odd digit, but the exact rules change with the seed. The Expert finds the matching condition and turns it into a single action: "Cut the third wire."

Engineers who mostly write code tend to find the Defuser seat harder than they expect. Describing what you see without interpreting it is a discipline. That is a good reason to rotate everyone through it.

## Can engineers see how the game works before they play?

Engineers usually want to know how the game works before they play it, and the answer does not spoil a round. The bomb a team faces is generated from a seed, the manual is generated from a rule seed, and knowing that a generator exists does not tell you which wire to cut.

The design is small enough to explain in a few sentences. The engine is pure TypeScript with no dependencies, no clock and no access to the DOM. A bomb is a function of its bomb seed, and a manual is a function of its rule seed. Time enters only through two functions that advance the state and apply an action. A lint rule rejects calls to the system clock and the random number generator inside the engine package, so the same inputs always give the same result.

That determinism is why the leaderboards can be trusted. The Defuser's browser records every action with a timestamp. When a round ends, the server replays the log against the bomb it issued and only lists the run if the replay agrees. Engineers who like this kind of thing tend to ask about it over the first round. [How a defusal gets ranked](/blog/games-with-leaderboards-how-a-defusal-gets-ranked#verified-runs-only-what-the-server-checks-before-listing) explains the replay in more depth.

There is one honest caveat. The manual is already in the Experts' hands, so knowing how the rule generator works gives them nothing they do not have. Asking how the game is built is a side quest for the curious, not a strategy.

## The engineering team mistake: treating the round as a speedrun

The engineering team mistake is treating a bomb round as a speedrun. Engineers like optimizing, so the second round becomes a race: skip the edgework, guess the obvious module, shave seconds. The bomb then explodes on a strike nobody checked, and the team learns the opposite of what an incident drill should teach.

Speed comes from clean communication, not from skipping steps. A Defuser who reads every module before acting is faster over a whole round than one who acts first and gets a strike, because each strike speeds up the timer. The first strike multiplies its speed by 1.25. The second takes it to 1.5. A team that rushes pays for it in time.

Leaderboards make the urge worse. Each mission has its own board, ranked by the most time left and then the fewest strikes, and only signed-in players appear. That is a fine goal for a team that already communicates well. As a first session's goal, it pushes people to skip the very habits the session is for.

Set the goal as "no strikes" for the first few rounds instead. Once a team can defuse cleanly, chasing time is a reasonable next step, and the [mission leaderboards](/leaderboard) are there for it.

## Engineering team retro after a bomb round

An engineering team retro after a bomb round runs like a blameless postmortem: what happened, in what order, where the information got stuck, and what the team will try next time. Ten minutes is enough. The point is to name communication patterns while they are fresh, not to find out who caused the strike.

A useful order is timeline first. Ask the Defuser to describe the round from their seat, then each Expert from theirs. The two accounts rarely match. The Defuser remembers saying "the second wire"; the Expert heard "the second blue wire". That gap is the interesting part, and it is the same gap that shows up in real incident reviews.

Then ask three questions. When did someone have information the others needed and not share it? When did two people talk at once? What did the team do after the first strike? Each answer points to a habit to change in the next round.

Keep it blameless. A strike is a team outcome, in the same way a failed deploy is. Naming the person who cut the wrong wire shuts the Defuser down for the rest of the session.

A new engineer can join this kind of session in their first week as an Expert, which is a gentler start than any fun-fact round; see [ice breakers for new hires: the first-week bomb](/blog/ice-breakers-for-new-hires-first-week-bomb). Quieter engineers often prefer the Expert seat for good reasons, which the guide to [team building activities for introverts](/blog/team-building-activities-for-introverts-expert-seat) explains.