Multitasking Name Game

The Multitasking Name Game is a short game attributed to Henrik Kniberg, designed to make the cost of multitasking visible. In small groups, a 'developer' must write the names of several 'clients', first alternating letter by letter, then completing one name before moving on to the next. Each client measures the time taken to receive their full name. The game concretely illustrates the difference between starting many things and quickly finishing what is engaged.

Walkthrough

1. 1

   Set the intention and the framework

   2 min

   The facilitator introduces the game without revealing the entire conclusion: 'We will compare two ways of working when multiple requests come in at the same time. Your mission will be very simple: to write names and measure when they are completed.' They clarify that the goal is not to judge the speed of the developer's writing, but to observe a work system. Participants must play seriously, without trying to optimise or circumvent the rule. This creates a safe framework and focuses attention on the flow.

   Tip — Emphasise from the start that the developer should not be personally evaluated; otherwise, they may feel pressured and write too quickly at the expense of observation.

2. 2

   Form groups and assign roles

   3 min

   The facilitator forms groups consisting of one developer and ideally 4 to 5 clients. In each group, each client wants their own name to be written on a sheet. The developer receives writing materials, and the clients have a way to time the elapsed time until their name is complete. If there are more people, some participants observe errors, hesitations, or waits. The facilitator checks that each group understands who is writing, who is requesting, and who is measuring.

   Tip — Choose names that are actually used within the group: involvement is better, and clients immediately notice if their name is incomplete or misspelled.

3. 3

   Round 1: satisfy everyone at the same time

   4 à 6 min

   The facilitator gives the exact rule: 'At the signal, the developer writes the first letter of each client's name, then the second letter of each client, then the third, and so on until all names are complete.' Each client starts their timer at the common start and stops it only when their name is finished. Clients can track their request, but must not change the rules during the process. The developer thus constantly alternates between names, simulating multiple open tasks in parallel.

   Tip — Before starting, have a client rephrase: 'What should the developer write first? And then?' This check prevents some groups from mistakenly writing a complete name too early.

4. 4

   Collect results from Round 1

   2 à 3 min

   At the end of the round, the facilitator asks each client to note or announce their delivery time: the elapsed time until their name is complete. They also ask observers and clients to report any errors: missed letters, inversions, hesitations, or incorrectly finished names. The groups keep these results for comparison with the second round. The facilitator avoids commenting too early to not influence the experience. The goal is to obtain a reliable snapshot of the multitasking mode.

   Tip — Have the times recorded in the order of clients around the table; this makes it visible that some are waiting a long time while everyone has been 'started'.

5. 5

   Round 2: finish one name before moving on to the next

   4 à 6 min

   The facilitator announces the second rule: 'This time, the developer writes a complete name before moving on to the next client. When a name is complete, the concerned client stops their timer. Then the developer processes the next name until all are finished.' The same names and roles are kept as much as possible to compare the two systems. Clients still measure their own delivery time. This round illustrates sequential work where fewer things are started at once to finish faster.

   Tip — Do not let the group debate for long about the order of clients: simply take the order around the table or the announced order, otherwise the discussion masks the main effect of the game.

6. 6

   Compare the two rounds

   3 à 4 min

   The facilitator asks the groups to compare, client by client, the time taken to receive the name in Round 1 and Round 2. They point out the expected result of the game: in the second round, all names, including the last one, are delivered earlier, and there are generally fewer errors. Participants identify what has changed: fewer context switches, less work in progress, more completion. The facilitator connects the observations to work situations where many requests are open simultaneously.

   Tip — Ask for the numerical observations first before interpretations; this avoids opinion debates and anchors the discussion in what participants have just experienced.

7. 7

   Debrief and transfer to work

   5 à 7 min

   The facilitator concludes by stating the central lesson: 'Start less, finish more; limit work in progress.' They then invite participants to relate the experience to their projects, meetings, tickets, client requests, or individual tasks. Clients can share what they felt when their name was started but not finished. The developer describes the mental load and the risk of errors in each round. Finally, the group chooses a concrete action to reduce multitasking in their context.

   Tip — End with an observable decision, such as reducing the number of open topics simultaneously in a team; without a concrete commitment, the game remains an amusing demonstration but poorly transferred.

Variants

• In a large group, form several teams in parallel with one developer and 4 to 5 clients per team, then compare the findings between teams during the debrief.
• With observers, ask one or two people per group to note hesitations, interruptions, corrections, and moments of waiting, without intervening during the rounds.
• Remotely, use a shared document or an online whiteboard: the developer writes the names, clients time themselves at home and announce their time when their name is complete.
• To speed up the workshop, have only one group play in demonstration while others observe, then use the collective observations for the debrief.