Mob Programming

Splitting work by person has one old side effect. Within six months, payments is the thing Theo knows and search is the thing somebody else knows. Then payments breaks on a day Theo is on vacation and the work stops, and when he returns he spends a day rereading code he wrote himself.

Code review only half solved this. Review happens after the work is finished, so a wrong direction surfaces once three days of work are already stacked on top of it. At that point a reviewer has two realistic options: ask for the whole thing again, or wave it through and promise to fix it later. Choose the second option often enough and the codebase collects areas nobody is confident touching.

Opening an area nobody knows made the problem worse. Three people research separately, hold two design meetings, and then merge their code — which is when it turns out they were each holding a different picture. What everyone believed had been agreed in the meeting had been filled in differently inside three heads.

Mob programming inverts the order. Instead of merging later and reviewing later, it puts everyone who matters in the room at the moment the decisions are made. It's close to pair programming scaled up from two people to the size of the team.

A mob session follows a fixed shape. It isn't a group discussion; it's working time with assigned roles and a rotation clock.

1. Pick exactly one task. Something like building the refund cancellation flow — small enough to finish that day. Put two tasks on the table and attention splits, leaving half the room as spectators.
2. Split into one person typing and everyone else deciding direction. One screen, and everybody looks at the same thing.
3. The person typing doesn't write code from their own judgment. They type what has been said out loud. This rule is the whole practice. Let a fast typist run ahead alone and the others are reduced to reading along, which turns the session into five people watching one screen.
4. Rotate every 10 to 15 minutes. Fix the order in advance and run a timer. Five people at 12 minutes each complete a full lap in an hour.
5. Break once an hour. A group concentrating on the same thing burns down faster than one person working alone.
6. When the session ends, merge and run the checks on the spot. With continuous integration (CI) in place the automated checks run here, and the group reads the result together before breaking up.

Two to three hours is the common session length. Some teams do full days, but that isn't where a new team should start. Three hours in the morning and separate work in the afternoon is easier to sustain, and it gives the group a natural place to stop and ask whether the session was worth the hours it took.

The participants are the people whose decisions the task actually depends on. Three to five engineers is the base, with Noa joining for the stretch where screen behavior gets decided and Mia for the stretch where a rule gets decided. Past six people, someone stops getting a turn to speak, and that person opens a laptop and starts on something else.

There are four moments worth calling one.

1. Opening an area whose structure nobody knows. Research, design, and implementation happen in the same room, so there's no gap for an agreement to drift into.
2. Touching something that's hard to undo. Payments and permissions are the standard examples — money sent incorrectly doesn't come back when you revert the commit.
3. Handing code to someone who just joined. It moves faster than making them read documents, and the person handing off finds out on the spot what they can't explain.
4. When a design argument has run for more than two meetings. Differences that talking won't narrow often become visible the moment someone writes a line of code.

The reverse is just as clear. Copy edits, or building one more screen much like the last one, have nothing to decide, and one person is faster. Frequency isn't daily either. Many teams reserve one half-day a week and collect the tasks that belong in it, which also keeps the practice from competing with everything else on the calendar.

"Let's mob this one. Alone it takes two days and nobody else sees it during them."

A judgment that knowledge ending up with one person costs more than the hours do.

"This morning's mob is the payment cancellation flow. Theo types first, 12-minute rotations."

Nailing down roles and the rotation interval before the session starts.

"We mobbed it for two hours, so I'll skip review on this one."

Review already happened while the code was being written, so running the step twice adds nothing.

The quarter Pagedeck added paid billing, Theo was the one who proposed this. Cancellations and refund math are the kind of thing that sends real money to the wrong place when it's wrong, and writing it alone and waiting for review didn't produce enough confidence. Three engineers blocked out three hours and rotated every 12 minutes, and Mia joined for half an hour at the point where the refund policy had to be decided.

The code that came out that morning was maybe half of what Theo would have written alone. In exchange, all three could read it, and when the refund rules changed two months later the work went to whoever was free rather than to the one person who had been there.

The most common misreading is that five people on one task means a fifth of the output. Multiplying headcount by result makes that a natural calculation. What the calculation leaves out is the time that working alone spends elsewhere: waiting for review, unwinding work after review says the direction was wrong, and the queue that forms six months later because one person is the only one who knows that code. Left in place, this belief keeps teams from mobbing where it would pay, and the set of areas one person owns keeps growing.

Reading a mob as teaching time for juniors is the other one. A group around one screen looks like a classroom. In practice it often pays off most among experienced engineers, because design disagreements happen between people who know the material. Used only for teaching, senior engineers start treating it as time taken from them, and once that impression sets it gets hard to assemble a mob when one is genuinely needed.