Is Mob Programming the Right Approach for Your Team?

Originally published on Medium.

The short version

Mob programming (three+ developers working on one task with driver-navigator) sounds collaborative, but the productivity math is brutal: three engineers who could ship 72 units of output often produce 8 because of coordination overhead, consensus waiting, and the slowest-person pacing. Quality is also a myth: groupthink replaces real peer review and bug-catching diffuses. Worst, engineers become task takers without ownership. The gold standard is fully empowered Scrum teams: better decisions because of accountability, faster movement without consensus, real innovation, and retention. Mob programming works in three legitimate cases: high-stakes critical systems, cross-functional ideation, and onboarding. Use it strategically, not as a default.

What is Mob Programming?

Mob programming is three or more developers working on a single task with the driver-navigator model. One person writes the code, the driver. The others steer, the navigators. It sounds collaborative. In practice it's messier than that.

The Productivity Trap

Start with the math. If one engineer ships 24 units of output in a sprint, three engineers in a mob should give you 72. Instead you often get 8.

Why? The overhead eats everything. Context switching and coordination. Waiting for consensus on every decision. Pacing to the slowest person in the room. And interruptions that multiply as the group grows.

That's not collaboration. It's a 67% productivity cut while you pay three salaries.

The Quality Myth

The pitch is that constant peer review lifts quality. What you usually get is groupthink.

Too many cooks, and everyone assumes someone else is catching the bugs. Testing attention drops because people are busy managing the conversation. So you ship code that passed the room and then falls over in production.

Stakeholder Frustration

Features that should take two weeks now take six. Innovation stalls, competitive pressure climbs, and stakeholders watch sprint after sprint go by with almost nothing shipped while three salaries burn.

Then someone asks, "why can't we just hire faster?" Wrong question. Mob programming makes good engineers less productive, so more of them won't fix it.

Engineers Become Task Takers

Here's what bothers me most. Mob programming strips away ownership.

Engineers stop deciding how to solve the problem. They type out someone else's solution while five other people watch. They lose the thread of why the work matters. Creativity goes flat, and the strongest engineers leave first, because their talent is the most obviously wasted.

When Pair Programming Works

Pair programming in small doses has real value. Coaching a junior. Getting a second pair of eyes on a tricky problem. Tackling something genuinely hard together.

But keep it right-sized and deliberate. Not the default setting for every task.

The Gold Standard: Fully Empowered Scrum Teams

Ownership is the whole thing. Engineers who own their work:

• Make better decisions, because they're accountable for them
• Move faster, because they don't need consensus on every line
• Innovate, because they understand the problem deeply
• Stay longer, because they find meaning in the work

They collaborate at the moments that earn it, design reviews, technical feedback, architectural calls, not for every keystroke.

They talk to users and feel the impact of what they build. That connection drives quality and invention far harder than sitting shoulder to shoulder with two other people ever will.

When Mob Programming Does Make Sense

There are real cases for it:

• High-stakes critical systems, where a failure would be catastrophic
• Cross-functional ideation, during genuinely complex problem discovery
• Onboarding, when knowledge transfer is the whole point

Reach for it on purpose, in those moments. Not as a permanent way of working.

Where I Land

Fully empowered Scrum teams with clear ownership are almost always the better bet. More output, higher quality, more invention, and people who stick around.

Mob programming feels good in the moment because it feels collaborative. But collaboration that trades away productivity and ownership isn't really collaboration, it's just busy people sharing a room.

So this week, if your team has drifted into mobbing by default, pull it back to one owner per task and keep the group for the design review. Watch what happens to your throughput. For what empowered product teams look like now, see The Product Operating Model. And for how prototyping together, fast and focused, not mob-style, fits the new build cadence, see Instant Prototyping.