Collaboration lessons from mob programming

What mob programming taught me about remote collaboration and why it might make your team faster.

Nowadays many software companies operate at least somewhat hybrid, with employees working from home for parts of their week. This relatively recent shift has changed how we collaborate: on the one hand, we can meet synchronously with almost anyone, almost any time; on the other hand, our human capabilities are often under-utilized in these settings. Reading the room and setting it up for an effective meeting is reduced to a grid of small rectangular windows. Who knows how many of your co-workers are glaring at you in their pajama pants?

And even though technical solutions try to emulate the experience of sketching quick diagrams on a whiteboard or taking over someone’s keyboard when they are stuck, these tools have real limitations in my experience. They rarely feel natural. It is harder to read the room: on a large Miro board, for example, it is difficult to track what everyone is actually looking at and engaging with.

Effective collaborative meetings in remote settings are genuinely hard.

When collaboration tools are involved, the organizer needs to educate the group in advance and often run trial sessions before things click. It takes tenacity: accepting some frustrating early attempts, integrating the lessons, and refining the approach until it actually works.

As a result, I think many leaders default to a more hierarchical divide-and- conquer structure, where collaboration happens either asynchronously or under heavy top-down direction from one person issuing directives. Those directives favor clarity and executability over adaptation and diverse input. The outcome, predictably, is more likely to lack coherence.

There are certainly legitimate reasons why many companies are returning to in-office or hybrid models where coffee-machine conversations are the norm: synchronous collaboration comes more naturally in a shared physical space, while focused individual work tends to suit the remote environment.

My experience with synchronous work in a remote setting

That said, even in a fully remote environment, synchronous collaboration can be done well.

Early in my career as an engineering leader, I was asked to integrate a second team into my existing one after their team lead quit. My first team owned the core platform components; the new team was building on and extending those capabilities. There was obvious potential for collaboration and mutual learning, but after a sprint of business as usual, it was clear we were not speaking the same language.

I did not really know what the new engineers were doing day to day: what problems they were running into, what tools they used, what practices they had developed. There were plenty of written documents about their work and planned tasks, and we spent time going through them together, but the whole process felt overwhelming and directionless, more resource management than real collaboration. But I did not want to just be a manager for them.

So I tried mob programming: the entire team works on one clearly defined task together, in the same room, on the same computer. Since my team was remote, that meant a Zoom room. We could not literally share a machine, but we used a tool that made it easy to hand off control of the codebase, the steering wheel, so to speak. Rotating the driver role regularly is essential: if the same person drives the whole time, others disengage and stop contributing.

Yes, engineers are introverts, have their preferred ways of doing things, and are often very opinionated about it. So, I cannot say that everyone was excited about it from the start. But it was highly effective:

• Learning was immediate and visceral. Everyone saw the pain points firsthand, and when the team got stuck, someone usually knew the answer. New team members could quickly contribute to tasks the core platform team had always owned. The core team, in turn, learned a lot about what it actually felt like to use the platform they had built.
• At every moment, it was clear what mattered most. An experienced developer who has long since forgotten the struggles that shaped their setup often cannot write good onboarding documentation because those struggles are invisible to them now. But in a mob session, when a junior engineer or someone unfamiliar with the codebase takes the wheel, they naturally ask the questions that lead to the most important conversations. After a few sessions, we learned we needed a designated note-taker to capture the substance of those exchanges.
• Team spirit grows, far more than it does when people see each other for fifteen minutes a day to discuss yesterday’s blockers.
• There is some shared vulnerability, for example when something does not work and for a while nobody knows what the cause is. How beautiful to get humbled together.
• There is a shared sense of ownership when a task actually gets finished and everyone has contributed to it.
• And we actually get to know each other, because we are hanging out together. There is room for laughter and some stories, as opposed to a more transactional meeting approach.

Is collaboration really slowing us down?

After that experience, I started using mob programming sessions deliberately for specific tasks, and the most surprising thing was how fast the team could move. Collaborative mob programming is most effective when:

• The problem is complex or ambiguous.
• Alignment is critical.
• The cost of miscommunication is high.
• Learning and capability-building matter.

One such opportunity arrived when a specific customer needed a demo of a potential product feature by a fixed deadline.

Predictably, the requirements were ambiguous at first and changed several times across the two-week window we had.

Rather than assigning the task to one or two engineers and leaving them to wrestle with the ambiguity alone, I decided to implement it as a team. What followed:

• Progress was always visible. At any point in the process, we knew exactly where we stood relative to the goal.
• When the team encountered a fork in the road, or a technical constraint that required a product or customer decision, I could step away from the mob session, get answers quickly, and come back with minimal disruption. While I was gone, the team would shift to the next well-defined task, or simply take a break.
• When customer requirements shifted, we could pivot quickly. Because we had built a shared understanding of the problem throughout the process, we could adapt and re-align without starting from scratch.

In the end, we had plenty of time to test the solution and hand it off to the customer success team before the demo.

What surprised me was the reaction from people outside our team. Many thanked us for the sacrifices we must have made to deliver something so messy on time. In reality, we probably worked fewer hours than usual:

• At the end of each day, everyone was aware of the progress and could give a confident, grounded assessment of where things stood.
• It took some time, but we also got better at taking regular breaks. The drop in energy in the room became legible to everyone. We started holding each other accountable for taking care of ourselves. As the group leader, I had some responsibility to model and celebrate that. It made the work more sustainable and, ultimately, more effective.

Lessons for the office and non-engineers

Offices are more conducive to synchronous collaboration than remote environments, but the physical setting alone is not enough. The company still needs to provide the cultural foundation. I have worked in office environments where top-down planning made real collaboration difficult: the priority was focus and output, not necessarily the best long-term solutions.

Learning this the hard way in a remote setting, I have come to believe that effective collaboration comes down to four core ingredients:

• An ambitious but clearly defined goal, something like next quarter’s strategy.
• A process that encourages, or ideally requires, active participation from everyone.
• A way to evaluate progress and velocity toward the goal.
• Awareness of the group’s capacity.

If you consistently get through every agenda item in every meeting, that is probably a sign that the people in the room are not really collaborating with you, either because they feel unsafe speaking up, or because they have not been given the support to develop that skill.

This perspective from Jensen Huang on avoiding one-on-one meetings offers an interesting example of how leaders can foster more collaboration.

Reflections of the day

• Think of a task for your team. Does it call for more collaboration, or more focused individual work?
• Do you think more collaboration could make your team faster? If not, why? If yes, what would it take to get there?

With care,

Martin