How to Run a Mob Programming Session in English

Mob programming — where an entire team works on the same problem, at the same computer, at the same time — puts a premium on clear, real-time verbal communication. Unlike pair programming, where two people can rely on shared context built up over time, a mob session often includes people who think differently and need the facilitator to keep language precise, inclusive, and moving at a good pace.

Opening the Session

Set expectations clearly at the start, especially with a rotating driver-navigator setup.

• “We’ll rotate the driver every 10 minutes — whoever is at the keyboard just types what the group decides, they don’t make unilateral decisions.”
• “If you’re not driving or navigating right now, you’re still part of the mob — feel free to jump in with a suggestion at any point.”
• “Let’s agree on the goal for this session before we start typing: we want a working test for this edge case, not a finished feature.”

Guiding the Driver

The driver’s job is execution, not decision-making — the facilitator’s phrasing should reinforce that.

• “Go ahead and type exactly what we just agreed on — don’t improvise a different approach on your own while you’re driving.”
• “If you see a better way while you’re driving, say it out loud rather than just doing it — let’s decide as a group.”
• “You’re up next as navigator — can you describe out loud what we want the driver to type, one step at a time?”

Managing the Navigator Role

The navigator directs at a higher level than dictating exact syntax, and phrasing should reflect that.

• “As navigator, try to describe intent — ‘let’s extract this into a helper function’ — rather than dictating every character.”
• “Let’s pause the navigator for a second; a few people have follow-up questions about that approach.”
• “Good navigating — that was clear enough that the driver didn’t need to ask any clarifying questions.”

Handling Disagreements

Disagreements are common and healthy in a mob — the language you use should keep them productive.

• “I hear two different approaches here — let’s timebox five minutes to each and vote before committing to one.”
• “I don’t think we’ve reached agreement yet — can whoever’s not convinced explain what’s still unclear?”
• “Let’s park this disagreement for now, get something working, and revisit the design question afterward with fresh eyes.”

Keeping Everyone Engaged

Facilitators actively draw in quieter participants, since a mob can otherwise be dominated by a few voices.

• “We haven’t heard from you in a while — does this approach make sense from where you’re sitting?”
• “Let’s make sure everyone gets a turn driving today, even if some of you are less familiar with this part of the codebase.”
• “If anyone’s lost at any point, please say so immediately — there’s no such thing as a bad question in a mob session.”

Wrapping Up

Close with a clear summary and next steps, since mob sessions can otherwise end without a shared sense of what was decided.

• “Let’s recap what we actually built today and what’s still left before we call this feature done.”
• “Before we break, can someone volunteer to write up the decision we made about the retry strategy, so it’s documented for people who weren’t here?”
• “Great session — let’s schedule the next mob slot for tomorrow to keep momentum on this feature.”

Vocabulary Reference

Key Takeaways

• Reinforce the driver’s role as execution, not decision-making — encourage them to say suggestions out loud rather than silently improvising.
• Guide navigators toward describing intent rather than dictating exact syntax, which keeps the whole mob engaged in the thinking.
• Use timeboxing language to resolve disagreements productively instead of letting debates stall the session.
• Actively invite quieter participants into the conversation — mob sessions can otherwise be dominated by the most vocal few.
• Close every session with a clear recap of what was built and decided, so absent teammates and future readers have a clear record.