Mob Programming: Process, Sessions, Benefits and Costs

Mob programming puts an entire team on one task, at one computer, at the same time. One person types, one person directs, the rest watch, think and speak up. Teams use it to raise code quality, spread knowledge and cut the delays that come from handoffs, and it works for remote teams as well as it does around a single desk.

I have introduced pair and mob programming to several development teams. The transition is rarely smooth and the results are worth the discomfort. When I first suggested gathering five developers around a single screen, I met skepticism. "It sounds inefficient" was the most common objection. Within days, the same skeptics were the practice's strongest advocates.

This article covers three questions people ask me: how the process works step by step, how to run a session, and what the practice buys and costs.

What is mob programming?

Picture your whole development team gathered around one workstation. One person types (the driver), another gives immediate direction (the navigator), and the rest contribute ideas, spot problems and suggest solutions (the mob). This is pair programming scaled to the whole team. In a remote setting it looks like a video meeting where the driver shares an editor window.

The name comes from Woody Zuill's team at Hunter Industries, who described the practice as "all the brilliant people working on the same thing, at the same time, in the same space, and at the same computer". Some teams call it ensemble programming or, in the tooling world, "mob development". The mechanics are the same.

How a mob programming session works, step by step

A session follows a fixed structure. The structure is what makes the practice work with five or six people; without it, you get a meeting where one person codes and the rest read email.

The three roles

The driver sits at the keyboard and types. The driver's job is to translate what the navigator says into code, and nothing else. A driver who starts making design decisions on their own has broken the loop, and the rest of the mob has stopped participating.

The navigator decides what to do next and tells the driver in plain language, at the level of detail the driver needs. With a senior driver, "extract that into a method" is enough. With a junior one, the navigator names the method and says where it goes. The navigator listens to the mob, picks the best idea on the table, and turns it into an instruction.

The mob is everyone else. They watch the screen, think ahead, point out a missed edge case, look up documentation, and offer alternatives. They speak to the navigator, not to the driver. A mob member who wants a different approach argues for it; the navigator decides.

Rotation and the timer

Roles rotate on a timer. Every ten to fifteen minutes the driver steps away, the navigator takes the keyboard, and the next person in line becomes navigator. One team in the research I cite below settled on "ten minutes minus the number of participants" per turn. In my experience, ten to twenty minute rotations work best while a team is learning; shorter turns keep everyone alert, and nobody sits in a role long enough to get stuck in it.

Rotate on the clock, not on the task. If the timer goes off mid-function, the next driver finishes the function. That feels wrong the first few times and is the point: the code has to be understandable to the next person at every moment, so the mob writes code that reads well.

A single turn, in practice

The timer starts. The navigator states the next small goal: "Let's write a failing test for the empty-list case."
The driver types. The mob watches and speaks up if the navigator has missed something.
The test fails. The navigator states the smallest change that makes it pass. The driver types it.
Someone in the mob suggests a cleaner shape. The navigator agrees or defers it, and says so.
The timer goes off. The driver commits or hands over a working tree, and roles shift by one seat.

Over an afternoon, the mob repeats that loop dozens of times. A session ends with a short retrospective: what slowed us down, what to change tomorrow.

Running a mob programming session

How long, and how often

Start with a single two-hour session per week. Two hours is long enough to finish something meaningful and short enough that skeptics can try it without feeling their week was taken away. Teams that stay with the practice grow it from there; some mob for most of the day, others reserve it for specific kinds of work.

Inside a session, the most successful setup I led used forty-minute blocks with five-minute breaks. Breaks are not optional. Mobbing is intense for everyone, including the people who are not typing, and a team that skips breaks will call the practice exhausting and drop it.

Your first session

Pick a real, complex task. Not a toy exercise and not a trivial ticket. A problem with several plausible solutions gives the mob something to argue about, and early wins build momentum.
Set up the room or the call. In person: one large screen everyone can read, one keyboard, chairs for everyone. Remote: see the tooling below.
Agree the rules out loud. The driver types what the navigator says. The mob speaks to the navigator. Rotate on the timer. Anyone can call a break.
Start the timer and go. Resist the urge to plan for an hour first. Ten minutes of design discussion at the whiteboard, then code.
Hold a five-minute retrospective at the end. One team in the research described daily retrospectives as "pressure valves". Small frictions surface while they are still small.

Let people participate at the level they are comfortable with. I have seen teams force everyone to drive on day one, and the resentment lasted longer than the session.

Remote mob programming: setup and tools

Remote mobbing works. The team studied by Ståhl and Mårtensson moved to remote mob programming during the COVID-19 pandemic and reported that it "works remarkably well". When I helped a distributed team make the same move, I expected it to work for some people and not others. After the first technical hiccups, the team reported stronger collaboration than they had with remote pairing.

What a remote mob needs:

A shared editing environment, not only screen sharing. The studied team found plain screen sharing insufficient and moved to "a concurrent editor on a shared remote host in the company's internal cloud". VS Code Live Share and JetBrains Code With Me give you the same thing without the infrastructure.
Fast handovers. mob.sh wraps the git commands so each side of a handover is one command: the outgoing driver runs mob next, the incoming driver runs mob start, and the work-in-progress branch travels between machines. Without something like it, handovers eat the rotation.
A visible timer. Shared on screen, so nobody has to police it.
Explicit turn-taking. Without body language, people talk over each other or go quiet. A raised-hand reaction or a dedicated chat channel for "I want to say something" fixes most of it.
Cameras on, most of the time. One participant in the research said it is "much easier to 'zone out' and lose focus while working remotely" and that "turning on the cameras might help". It does.
A digital whiteboard for the design discussion at the start.

Remote sessions can be more inclusive than in-person ones. Some people who rarely spoke in the office found it "easier to join remote mob sessions"; others had the opposite experience. Offering both modes lets each person find the setting where they contribute.

If your team is starting to use AI coding agents inside the mob, the roles shift again; I wrote about that in Mob Agentic Engineering.

Mob programming benefits and costs

What it buys you

Higher quality code. When several experts review code as it is written, defects get caught before they exist. Ståhl and Mårtensson (2021) found that mob programming teams reported "improved software quality and reduced technical debt" compared to their previous approach. One team in their study noted that "the things we have done as a mob are of better quality and have fewer problems". Across three teams where I introduced the practice, we saw a clear drop in production defects within the first quarter.

Faster knowledge sharing. Juniors learn from seniors by watching them work, and specialists spread their domain knowledge to the whole team without a single training session. I have watched new team members reach in weeks a level that used to take months.

A team that talks. One developer in Ståhl and Mårtensson's study put it this way: "Previously we were a group of people... We call it a team, but it is really a financial construction, a number of employees who share a room." Mob programming turned them into "a group of friends programming together". One of my teams went from barely speaking to holding voluntary lunch discussions about architecture.

Less delivery risk. When everyone has touched every part of the system, nobody's holiday blocks a release. Practitioners in the research reported that "the mob is never stuck, you are always moving forward" and that "vulnerability to unplanned absence of key individuals was lessened".

What it costs you

Throughput on small tasks. Five people on one trivial ticket is five people doing one person's job. The teams in the research were unanimous that small, contained tasks were "inefficient to handle as a mob". You learn to be selective.

A slower start on any given piece of work. The first version of a feature takes longer when five people weigh in on every line. The saving shows up later, in less rework, fewer defects and no waiting for the one person who knows the module, and in my teams it has outweighed the slower start every time we used the mob on the right kind of task.

Energy. Some people leave a session "completely exhausted"; others find it "fairly relaxing". Breaks, time boundaries and the freedom to sit out a session make the difference between a sustainable practice and burnout.

Calendar time. A mob needs everyone in the same hours. For a team spread across many time zones, that may limit sessions to a two- or three-hour overlap.

When to use it

Complex tasks that need several areas of expertise
Architectural design work
Hard problems with no obvious solution
Onboarding new team members
Breaking down and planning large features

When not to

Simple, routine tasks
Reactive work such as customer support
Individual code reviews
Work that needs long, uninterrupted individual focus

"Isn't it inefficient to have everyone on one task?"

This is the first objection I hear, every time. It does not hold up in practice. One practitioner said it well: "the mob could only do one thing at a time, but did it fast and did it well and truly done." With every needed skill in the room, work does not wait for a review, a question on Slack, or the one person who knows the billing module.

Comparing programming approaches

Aspect	Solo Programming	Pair Programming	Mob Programming
Quality	Varies with individual skill	Higher than solo	Highest quality, fewest bugs
Knowledge sharing	Limited	Good between pairs	Whole team
Learning curve	Low	Moderate	Steeper initial adjustment
Productivity	Fastest for simple tasks	Balanced	Most efficient for complex tasks
Team cohesion	Limited impact	Improves pairs' relationships	Strongest team building
Remote effectiveness	High	Moderate	High with the right tools

Conclusion

Mob programming changes how a team approaches software, whether the team shares a room or a video call. It is not for every task or every person, and its benefits for quality, knowledge sharing and team cohesion make it worth a place in your practice.

When I first argued for it, the common refrain was "we can't afford to have five developers on a single task". The same organizations now reserve the mob for their hardest problems because they cannot afford to solve those any other way: faster delivery, fewer defects, more engaged teams.

Start small, pick a complex task, and give people room to join at their own pace. If you want help introducing the practice to your team, that is part of what we do; see Team Organization on our services page.