Mob Programming 1/3 - One Task, One Keyboard, Full Team Attention

Most teams measure efficiency by how busy everyone looks. Each developer has their own ticket, their own branch, their own TODO list.
But busyness isn’t the same as progress. What slows teams down are the handovers, the unclear decisions, and especially hidden silos.

Mob programming takes a different approach. The whole team works together, on one problem, at one computer.
At first it sounds expensive. In practice, it solves the very issues that drain time and energy in the background (Software Teaming).

What is it?

At its core, mob programming is simple: bring the whole team - whatever “team” means in your case - into one space, to solve one problem together.
One person is the Driver at the keyboard. Everyone else acts as Navigators, guiding the direction of the work.

It’s often described as the distillation of agile principles. Teams self-organize, communicate directly, and focus on people and collaboration over process. Trust is built into the format.

Why do this?

The real benefit isn’t “more eyes on the code.” It’s that all perspectives are present at once.
Developers, testers, product managers, infra, design - whoever the work touches.

That means:

• Learning accelerates - juniors grow faster, seniors gain new perspectives.
• Decisions speed up - no waiting on Slack threads or late reviews.
• Team cohesion builds - everyone contributes, everyone is heard.
• Silos break down - domain, infra, testing, and product knowledge stop being bottlenecks (Software Teaming).

The result: fewer surprises, smoother flow, and a team that grows stronger together.

How it works in practice

• Driver: the person at the keyboard. Their role is to translate team intent into code. When coding, the Driver should be a capable programmer (Software Teaming). The driver is purely the person translating the ideas of the navigators into code. If the driver has an idea, he should switch with someone else
• Navigators: everyone else. They don’t dictate keystrokes, they share ideas and business logic. What should happen, not how to type it.
• Rotation: every 5–10 minutes, the Driver role rotates. This keeps energy up and prevents one voice from dominating (Software Teaming).
• Daily retro: the mob closes each day with a short reflection - what to keep, what to change (Software Teaming).

Setting it up for success

The environment matters. A single laptop on a desk won’t cut it.

• Large monitor or projector so everyone can see.
• Whiteboard to capture open questions and agreements.
• A timer for Driver rotations.
• Clear facilitation - someone balances voices and keeps energy flowing.
• Small teams, probably no more than 5 people.
• Kindness, consideration, and respect - the baseline for any session.

Small details like these make the difference between “five people crammed around a screen” and “a team in flow.”

Isn’t this a waste of resources?

It feels counterintuitive to put five or six people on one task. But consider the hidden costs of solo work: misaligned assumptions, handover delays, duplicate efforts, defects that slip through.
A single rework cycle often burns more hours than a mob session would have. This is supported by experience reports such as the Hunter Industries case study.

Instead of multiplying partial solutions, the mob produces one shared solution - built, tested, and understood by the whole team.

It also doesn’t have to be the default. Think of it as a tool in the belt: use it for complex problems, shared learning, or building cohesion.

Closing

This series is my way of starting to learn in public. I’ll explore practices like mob programming, reflect on what I read and try, and share the results. There’s much more to this concept, which I’ll dig into over time.

If you’re curious, try a simple experiment: run one 90-minute mob on a safe codebase. Rotate every 5–10 minutes, include more than just developers, and close with a short retro (Remote Mob Programming).
Then compare the outcome to how you usually work.

Next, I’ll look at what changes when the mob isn’t in the same room (Remote Mob Programming).