Mob Programming 3/3 - Beyond Code: Where Else Can We Mob?
Mob programming is often pictured as a group of developers around a single keyboard. But the principle is broader: the right people working on the same thing, at the same time, in the same space (physical or virtual).
Once you see it that way, you start spotting opportunities well beyond coding.
Where mobbing shines outside code
- Design sessions: Instead of handoffs between designers and developers, bring everyone together to sketch, debate, and refine in real time.
- Incident reviews: Post-mortems often fail because perspectives are siloed. Mobbing ensures ops, dev, QA, and product all contribute equally to the story and the fixes.
- Architecture decisions: Rather than circulating docs for weeks, gather the team, explore trade-offs, and decide together.
- Onboarding: New hires learn faster when they see the team solve problems in context, not just through a wiki.
- Documentation: Writing or updating docs as a group ensures accuracy and spreads ownership.
These uses have been tried in industry. An experience report from Buchan & Pearl describes how a financial services team used mobbing not only for coding but for testing and analysis. Another survey by Ståhl & Mårtensson shows mobbing evolving into a general practice for collaborative knowledge work, not just development.
Why it works
The same reasons mob programming works for code apply elsewhere:
- Learning accelerates - domain and business knowledge flow freely.
- Decisions speed up - no waiting on async approvals or scattered comments.
- Cohesion builds - people solve problems together, not in sequence.
- Silos break down - business and technical sides stop being separate conversations.
A qualitative study found that these benefits extend beyond productivity: participants reported higher engagement and stronger team identity.
What to watch out for
- Task fit: Don’t mob trivial updates or work that doesn’t need group input.
- Fatigue: Cap sessions at 90 minutes and take breaks.
- Facilitation: Someone still needs to balance voices and keep the group on track.
As one developer put it after five months of mobbing: “It works best when the whole team respects the time and energy of everyone else.”
Closing
Mobbing isn’t about code - it’s about collaboration. Once you’ve tried it in software, you start to see opportunities everywhere.
For me, this is where the learn-in-public journey widens. I’ll keep experimenting with mobbing on design sessions, onboarding, and reviews, and I’ll share what sticks and what doesn’t.
If you’re curious, pick one non-coding task this week and try mobbing it. Keep it short, keep it structured, and compare the outcome to how you usually work.