Mob Programming

Mob programming extends pair programming to the whole team. Instead of two people at one computer, you have three to six people at one computer.

• One person types (the driver)
• Everyone else thinks, discusses, and directs (navigators)
• Roles rotate frequently (every 5-15 minutes)

This sounds absurdly inefficient. Five people doing one person's typing? But teams that try it often report surprising benefits.

When mobbing works well, the team:

• Solves complex problems faster than individuals
• Spreads knowledge to everyone simultaneously
• Makes better decisions through diverse perspectives
• Stays focused (no context-switching)
• Builds shared understanding of the code

Mobbing isn't for everything. Use it for:

Complex problems: When no one person has all the knowledge needed. The combined expertise of the mob exceeds any individual.

High-stakes decisions: Architecture choices, security-sensitive code, things that affect the whole system. Mobbing reduces the risk of one person making a mistake.

Knowledge transfer: When you want everyone to learn something simultaneously. A new technology, a complex domain, unfamiliar code.

Onboarding: New team members learn the codebase, the patterns, and the culture—all at once.

Breaking logjams: When something is stuck, fresh perspectives unblock it.

Don't mob on:

• Routine, well-understood work
• Tasks that require individual concentration
• When the team is too large (>6 people becomes chaotic)

Roles:

• Driver: Hands on keyboard. Types what navigators say. Doesn't make decisions.
• Navigators: Think, discuss, direct. One navigator speaks at a time to avoid chaos.
• (Some teams add a facilitator to keep things moving.)

Rotation:

• Every 5-15 minutes, rotate the driver
• Use a timer to enforce rotation
• Everyone takes a turn driving

Strong-style navigation:

• "For an idea to go from your head to the computer, it must go through someone else's hands."
• Navigators explain intent; the driver figures out the keystrokes
• This prevents one person from dominating

Setup:

• One computer, large screen (or projector)
• Everyone can see the screen
• Comfortable seating for extended sessions
• Remote: screen share with all participants, one person has keyboard control at a time

Mobbing works remotely with the right tools:

Screen sharing: One person shares; everyone watches. VS Code Live Share or similar for shared editing.

Video on: Seeing faces helps with communication.

Clear audio: Everyone should be able to hear and speak.

Explicit handoffs: "Okay, I'm passing keyboard control to Alice."

More breaks: Remote mobbing is even more intense than in-person. Take breaks every 45-60 minutes.

Written sidebar: A chat channel for links, notes, or side questions without interrupting the speaker.

Remote mobbing can work surprisingly well. The forced structure (clear handoffs, explicit communication) sometimes makes it better than casual in-person mobbing.

You don't have to mob all the time or never. Most teams use mobbing selectively:

Mob for kickoffs: Start new features as a mob to establish direction, then break into pairs or solo.

Mob for reviews: Instead of async code review, review as a mob—everyone sees the code, discusses it, and improves it together.

Mob for learning: When adopting new technology, mob on the first use. Knowledge spreads immediately.

Solo or pair for implementation: Once the direction is clear, individuals or pairs can execute faster.

Think of mobbing as a tool, not a commitment. Use it when it adds value; use other approaches when they're more appropriate.

The key question: Is this problem better solved by many minds or individual focus? Let the answer guide your approach.