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 when three or more developers work together on a single task using the driver-navigator model. One person writes the code (the driver) while the others guide the direction (navigators). It sounds collaborative, but the reality is much more complex.

The Productivity Trap

Let's talk about the math. If one engineer can produce 24 units of output in a sprint, and you put three engineers in a mob, you might expect 72 units of output. Instead, you often get 8 units.

Why? Because:

• Context switching and coordination overhead
• Waiting for consensus on every decision
• Meeting pace needs to serve the slowest person
• Interruptions and distractions multiply with group size

That's not collaboration - that's a 67% productivity reduction while paying three salaries.

The Quality Myth

Mob programming proponents claim it improves quality through continuous peer review. In practice, you get groupthink instead.

Too many cooks in the kitchen creates a false sense of security. Everyone assumes someone else is catching bugs. Testing focus actually decreases because people are busy managing the discussion. You end up with code that passes the room's approval but fails in production.

Stakeholder Frustration

Features that could be delivered in two weeks now take six. Innovation stalls. Competitive pressure builds. Your stakeholders watch sprints pass with minimal shipped value while three salaries burn.

Then comes the question: "Why can't we just hire faster?" The answer is that mob programming makes good engineers less productive, not more.

Engineers Become Task Takers

Here's what really bothers me about mob programming. It strips away ownership.

Engineers no longer decide how to solve problems. They execute someone else's solution while five other people watch. They're disconnected from understanding why their work matters. Creativity dies. The best engineers leave because their talent is being wasted.

When Pair Programming Works

Pair programming in small doses - coaching a junior, getting feedback on a tricky problem, tackling something genuinely complex together - that's valuable.

But it should be right-sized and intentional, not a default approach.

The Gold Standard - Fully Empowered Scrum Teams

Ownership matters. Engineers who own their work:

• Make better decisions because they're accountable
• Move faster because they don't need consensus
• Innovate because they understand the problem deeply
• Stay longer because they find meaning in their work

They collaborate at the right moments - design reviews, technical feedback, architectural decisions - not for every line of code.

They connect with users and understand the impact of their work. That connection drives quality and innovation far better than sitting side-by-side with two other people.

When Mob Programming Does Make Sense

There are legitimate cases:

• High-stakes critical systems where failure is catastrophic
• Cross-functional ideation during complex problem discovery
• Onboarding when knowledge transfer is the goal

Use it strategically, not as a permanent way of working.

The Bottom Line

Fully empowered Scrum teams with clear ownership are almost always the better bet. You get more productivity, higher quality, better innovation, and better retention.

Mob programming feels good in the moment because it feels collaborative. But collaboration that sacrifices productivity and ownership isn't actually collaboration - it's just busy people in a room together.

For a broader look at what empowered product teams look like now, see The Product Operating Model. For how prototyping together (fast, focused, not mob-style) fits the new build cadence, see Instant Prototyping.