Mob Programming: A Field Report From a Six-Person Team
Pair programming with an entire team—not just two people—sounds impractical. But when a group of six engineers from three different teams, most of them new to the Shipping domain and several new to Shopify, were given six weeks to ship an ambitious project, mob programming became the practice that saved them from fragmentation.
The team started in a familiar pattern: pulling backlog items, pairing rarely and only with close acquaintances, and submitting pull requests that got little substantive feedback. Reviews passed with a few nits, and work moved forward, but connection and shared learning were thin.
Then teammate Sheldon Nunes introduced mob programming. An early attempt was a flop: six people on a video call, one driver sharing a screen, everyone else effectively zoned-out observers. The fix was rotation discipline.
Rotating the Driver Changes Everything
The team switched to a 10-minute driver rotation. At each handoff, the driver pushes changes and the next person pulls and takes over. With five people rotating every 10 minutes, the team covered about 50 minutes of focused work per cycle. The short rotation made it hard to disengage—your turn always came around faster than expected.
The format produced useful pressures. Decisions got made quickly, because nobody wanted to end a turn without contributing, and most decisions were reversible enough that hesitation wasn't worth it. Context sharing stayed lean for the same reason. Code review effectively disappeared: everyone had written the code together. The fastest, most obvious win was shipping speed, but the deeper payoff showed up in team dynamics.
After the first session, feedback flowed more easily. It was collaborative rather than judgmental because everyone shared ownership of the work. Close collaboration surfaced each person's unique workflow, and the time passed more enjoyably with casual drawing and other low-stakes interactions on a shared screen.
Five Lessons From Three Months of Daily Mobbing
1. Drawing Is Learning
A crudely drawn arrow is a form of communication that verbalizing alone cannot replace. Verbal-only instructions about which scroll position, which bracket on which line, or where exactly that spelling error lives become an exercise in frustration without the shared canvas. Doodling also keeps people engaged during builds—30 seconds feels like an eternity while monitoring a driver, and having something to draw or watch being drawn changes the group's energy.
2. Make the Mob Discoverable
The initial mobbing was an offshoot of an informal coffee chat, using Slack's /call feature. Starting in a private group created two problems: guests with relevant context couldn't be added, and a small private call pressured everyone to join regardless of availability.
Moving to a public channel resolved both issues. Any teammate can drop in and out, take breaks, and join without needing an invitation. The /call feature in a public channel, with screen sharing, keeps the mob alive precisely because it doesn't have to be planned or coordinated.
3. Choose Your Problem (and Clean Gits) Carefully
A rotating-driver mob needs problems that let people set up quickly, with one branch and a simple build. A rotation handoff should collapse to:
git pull
<mob>
git commit -a -m 'WIP!!!'
git push
This means abandoning good commit messages during a session—acceptable as long as the final change gets a meaningful message when the task completes. Rotations end with debugging statements in place or an unfinished line. That's fine. The trade-off is a handoff that takes seconds, not minutes.
Some work is naturally poor mobbing material. Long test suites, for instance, burn too much time waiting for feedback at each step. Documentation and other writing tasks are equally awkward; it's hard to draft a sentence with six people watching. In practice, someone would volunteer to take such tasks solo or in a pair.
4. Non-Developers Are Welcome
Mobbing is inclusive in a way that pair programming usually isn't. Directors who rarely code in their day jobs and curious product managers can sit in as drivers or observers. The default assumption—that the driver doesn't already know the answer—makes the format naturally welcoming to less-experienced developers. Everyone contributes context, so no single person has to carry the session.
5. Two Hours Max, Then Take a Break
Mobbing is draining, especially for introverts. The team found two hours to be the effective upper limit, and timeboxing the session also reduced the "fear of missing out" that non-participants might feel. The format was, notably, also intense enough that the team had to establish intentional no-pairing days to allow for social recovery.
Restoring Osmosis in Remote Work
For this team, the lasting change from mob programming was cultural. Remote work had stripped away the informal learning channels that an office provides—overhearing conversations, noticing new shortcuts, picking up tricks by walking past a screen. Without mobbing, you had to know to ask the question to get the answer.
Mobbing reversed that. Instead of being isolated and disconnected, the team collectively over-corrected toward collaboration. Newcomers had a distinct advantage: the mob carries low-context members, since there's always someone on the call who can fill in the gaps. You don't have to ask every question or supply every answer; you can absorb knowledge simply by participating.
