Mob Programming: Why 5 Developers at One Computer Can Be More Productive
"That's such a waste! Five people for one task?"
That's the typical first reaction to Mob Programming. And it's understandable – but wrong.
Mob Programming (also called Ensemble Programming) is a practice where the whole team works together at one computer. And contrary to intuition, it's often more efficient than everyone working separately.
What is Mob Programming?
The Core Idea
TRADITIONAL:
5 developers → 5 computers → 5 features in parallel
MOB PROGRAMMING:
5 developers → 1 computer → 1 feature together
The Roles
DRIVER:
- Sits at the keyboard
- Types the code
- Implements what the Navigators say
- Does NOT think about the solution themselves
NAVIGATOR(S):
- The rest of the team
- Think about the solution
- Give the Driver instructions
- Discuss approaches
ROTATION:
Every X minutes (typically: 5-15) the Driver changes.
Everyone is sometimes Driver, sometimes Navigator.
The Flow
1. The team sits together (physical or remote)
2. A problem/feature is discussed
3. Driver opens editor
4. Navigators discuss the approach
5. Driver types what they're told
6. After X minutes: Rotation
7. Repeat until done
Why Mob Programming Works
The Efficiency Paradox
INTUITION:
5 developers in parallel = 5x throughput
REALITY:
5 developers in parallel =
- 5x code with bugs
- 5x code reviews
- 5x merge conflicts
- 5x "How does this work again?"
- 5x context switches
MOB PROGRAMMING:
1x code, but:
- Fewer bugs (collective review)
- No review needed (was reviewed live)
- No merge conflicts
- Shared knowledge
- Focused work
The Real Benefits
1. Continuous Code Review
TRADITIONAL:
Write → Create PR → Wait → Review →
Comments → Changes → Review again → Merge
MOB:
Write + Review simultaneously
→ Problems caught immediately
→ No PR ping-pong
2. Knowledge Transfer
TRADITIONAL:
"Only Maria knows this part of the code"
→ Single point of failure
MOB:
Everyone wrote the code
→ Everyone understands it
→ No knowledge monopolies
3. Onboarding
TRADITIONAL:
Junior reads docs, tries, asks, waits, tries again
MOB:
Junior is there, sees how seniors think,
asks in real-time, learns context
→ Weeks saved
4. Focus
TRADITIONAL:
Slack, email, "Quick question?", meetings...
→ Constant interruptions
MOB:
The whole team is in the same context
→ No interruptions
→ Deep work as a group
5. Better Solutions
"Two heads are better than one"
→ Five heads are even better
Different perspectives + live discussion
= Better decisions
When Mob Programming Makes Sense
Good Use Cases
✓ COMPLEX PROBLEMS
- No one has the solution alone
- High uncertainty
- Architecture decisions
✓ CRITICAL FEATURES
- Security-relevant
- High business impact
- Low error tolerance
✓ KNOWLEDGE TRANSFER
- Onboarding new team members
- New team working on unfamiliar codebase
- Rotation across teams
✓ PRODUCTION BUGS
- Fast diagnosis needed
- All perspectives help
✓ SPIKE / EXPLORATION
- Evaluating new technology
- Prototyping
- Exploring unclear requirements
Less Suitable For
✗ ROUTINE TASKS
- Well understood
- Little discussion needed
- One person can do it quickly
✗ INDEPENDENT TASKS
- No overlap
- Parallelization makes sense
✗ WRITING DOCUMENTATION
- Less code, more text
- One person usually writes more efficiently
✗ WHEN THE TEAM DOESN'T WANT IT
- Mob needs buy-in
- Forced mob doesn't work
Introducing Mob Programming
Step 1: Start Small
NOT:
"Starting Monday, we do everything in mob."
BETTER:
"Let's try a mob afternoon this week.
We'll take [complex feature]."
WHY:
- Low barrier to entry
- Team can experience it
- Collect feedback
Step 2: Prepare Setup
Physical:
- Large monitor (or projector)
- Comfortable keyboard/mouse
- Space for everyone
- Timer visible
- Whiteboards for side notes
Remote:
- Screen sharing (VS Code Live Share, Tuple, etc.)
- Video for everyone
- Timer tool (Mobster, Mob Timer)
- Breakout option for side discussions
Step 3: Establish Rules
TYPICAL MOB RULES:
1. Driver only types what Navigators say
2. Rotation every X minutes (timer!)
3. Everyone is Driver at some point
4. No laptops on the side
5. Breaks are okay (Pomodoro-style)
6. Questions are welcome
7. We discuss, not argue
Step 4: Facilitate First Session
FACILITATOR ROLE:
- Manage timer
- Announce rotations
- During discussions: keep focus
- Include quiet team members
- Slow down loud team members
- Retro at the end
Step 5: Iterate
AFTER THE FIRST SESSION:
- What worked?
- What was difficult?
- What do we change next time?
TYPICAL ADJUSTMENTS:
- Adjust rotation time
- Different rules
- Different problem types
Tips for Effective Mob Programming
For the Driver
DOS:
- Only type what you're told
- Ask if unclear
- Think aloud: "So I'm writing..."
DON'TS:
- Rush ahead without instruction
- Start discussion (you're there to type)
- Implement your own ideas without team
For Navigators
DOS:
- Think aloud
- Include everyone
- Give concrete instructions
- Navigate on different levels:
- High-level: "We need a function for X"
- Low-level: "Write const result = ..."
DON'TS:
- Take the keyboard from Driver
- Be too vague ("do it somehow")
- Hold monologues
- Dominate the session
For the Team
DOS:
- Respect the timer
- Take breaks (at least every 90 min)
- Do retros
- Be patient (it takes practice)
DON'TS:
- Work on laptop on the side
- Let one person dominate permanently
- Ignore quieter members
- Go too long without breaks
Variants
Mini-Mob (Pair+)
3 people instead of whole team.
WHEN:
- Team too large (>6)
- Not everyone needs to be there
- Specific expertise set needed
Async Mob (Remote)
Not everyone at the same time, but on the same code.
HOW:
- One works, others watch (async recording)
- Comments/reviews in real-time
- Rotation across time zones
CHALLENGE:
- Less discussion
- More coordination needed
Mob Learning
Focus on learning, not output.
EXAMPLE:
- Explore new technology as mob
- Work through documentation together
- Coding katas in mob
Common Objections
"It's Slower"
SHORT-TERM:
Yes, 5 people on 1 feature is slower
than 5 people on 5 features.
LONG-TERM:
- Fewer bugs → Less bugfixing
- No review overhead
- Shared knowledge → Less blocking
- Better decisions → Less refactoring
CALCULATION:
Feature traditional: 5 days dev + 2 days review + 1 day bugfix
Feature mob: 3 days together + 0 days rest
→ Often faster end-to-end
"Introverts Suffer"
REALITY:
- Some introverts love mob (structured interaction)
- Others find it exhausting
SOLUTIONS:
- Not every task in mob
- Allow breaks
- Different roles (Driver is quieter)
- Hybrid: Mob for complex, solo for simple
"Isn't That Just Pair Programming?"
DIFFERENCE:
PAIR PROGRAMMING:
- 2 people
- Driver + Navigator
- Often longer sessions
MOB PROGRAMMING:
- 3+ people
- Driver + multiple Navigators
- Shorter rotations
- More perspectives
- Better knowledge transfer
MOB = PAIR + SCALE
"This Doesn't Work Remote"
REMOTE MOB IS DIFFERENT, BUT POSSIBLE:
TOOLS:
- VS Code Live Share
- Tuple / Pop
- Screen sharing + video
- Mob Timer tools
CHALLENGES:
- More discipline needed
- Good audio important
- Video helps
TIP:
Remote mob is actually easier for rotation
(Keyboard handoff = pass permissions)
Mob Programming and Culture
What Mob Says About a Team
WHEN MOB WORKS:
- Team trusts each other
- Open communication
- Psychological safety
- Willingness to learn
WHEN MOB DOESN'T WORK:
- Ego problems
- Lack of trust
- Fear of making mistakes
- Hierarchical thinking
Mob as Team-Building
MOB PROGRAMMING PROMOTES:
- Relationships (you get to know each other)
- Shared ownership
- Respect for different ways of thinking
- Common standards
- Team identity
→ MOB IS NOT JUST A CODING PRACTICE
→ IT'S A TEAM PRACTICE
Conclusion: Less Alone, More Together
Mob Programming isn't for every situation. But for complex problems, knowledge transfer, and team building, it's a powerful tool.
The Core Principles:
- One problem, one team: Focus instead of fragmentation
- Driver + Navigators: Clear roles, quick rotation
- Continuous review: Quality built in, not added later
- Knowledge transfer: Everyone learns, no one is a bottleneck
- Try it: Start small, iterate
Your Challenge:
Identify a complex feature or a stubborn bug. Plan a 2-hour mob with your team. Observe what happens.
Maybe it's inefficient. Maybe it's transformative. You'll only know if you try.
Want to learn more about team collaboration? Our guide on Psychological Safety shows how to create a culture where Mob Programming works.
