Thoughts About Mob Programming From a Manager’s Perspective

New Relic has always been a proponent of pair programming, but recently many of our engineering teams have embraced a new model of collaborative work known as mob programming.

If you’ve been keeping up with our Taming the Mob series, you’ve encountered various practitioner’s points of view and hopefully have taken away some great tips for effective mobbing. Now it’s time to look at mob programming from the engineering manager’s point of view.

As a VP of engineering at New Relic, it’s important to me that we maintain healthy teams. When several teams in my group started mobbing, I wanted to understand how that process would align with our wider goals. To be honest, I was worried that a team would become less efficient if they all worked as a single unit on the same task.

That didn’t happen. I continue to be pleasantly surprised by both the benefits of mobbing and by the pragmatism of the teams who choose to mob.

In this post, I’d like to share some thoughts on the pros and cons of mobbing from a manager’s perspective.

What is mobbing good for?

Mob programming is great for spreading knowledge throughout a team. When a team works together to write code, or complete a task in a mob, they’re all engaged, active participants, helping each other along. During code reviews, for instance, an active mob is much more likely to catch errors or locate other issues as they talk through the changes. Working this way eliminates needlessly long review cycles and speeds up the product development lifecycle.

Mobbing is also a great way to onboard new engineers—they essentially jump right into “the thick of things.” For instance, new engineers often spend a lot of time searching for documentation on team processes, and that documentation may not exist or can be out of date. As part of a mob, they quickly learn the processes and practices of their new team. New engineers don’t have to pair with multiple different people on the team to gain various bits of domain knowledge; they don’t have to spelunk through code trying to learn it on their own. In a mob, new engineers are surrounded by others who have the combined skills necessary to solve a problem or build a feature.

What’s the right size for a mob?

While there’s no specific size requirement, four to six engineers tends to be the sweet spot for a mob. Of course, mob size can vary depending on the team’s priorities. For high-level design discussions and discovery, a larger mob makes sense. Conversely, for small cleanup tasks, you may want a smaller mob, or even no mob at all. In many cases, pair programming or individual work is a more practical approach for this kind of work.

Most New Relic teams are great at self-organizing, though, and tend to work out the right number of people for the task at hand. Also, most of our teams have a standing rule that if you find yourself in a mob session and you’re not engaged—or, worse, not actually needed—you should feel free to spend your time on other work. This helps ensure that everyone’s time is respected and engineers don’t feel depleted by ineffective or inefficient mobbing sessions. Maintaining a healthy mob is critical to its success.

Should every team use mob programming?

The honest answer is no. Mob programming is effective only when the entire team embraces the process. Some engineers think better when they have time to focus on solo work. A team full of extreme introverts might not take to mobbing well, or might need to really limit their mobbing time. There are plenty of talented engineers who don’t even like pair programming and are unlikely to embrace the benefits of mob programming. Managers need to account for the personalities and preferences of their team members when setting up mobs. At New Relic, teams decide together how they will work.

For teams that do choose mob programming, they don’t always mob for everything. Some teams mob only during planning sessions; some teams mob only when writing new code; and some teams mob for nearly everything they do.

How much time should teams spend in the mob?

There’s no clear guideline here. At New Relic we treat engineering teams as self-organizing, autonomous units, so we prefer to let them decide how much time to spend mobbing. Most teams discover, through tools like retrospectives, how to balance their time between mobbing and individual work.

A typical pattern is that teams will mob frequently at the beginning of a project and cut back as the project draws to a close. At that point, one or two engineers will peel off to finish up the remaining bug fixes, small UX improvements, and so on, while the rest of the mob moves on to the next project. I love this pattern, as it shows that teams are always giving the majority of their attention to their top priority but still have space to fit in the smaller tasks that are also a part of their work.

Do more senior engineers take over and prevent others from improving their skills progress?

From what I’ve seen, it’s actually the opposite. I’ve seen mobs build up shy or less experienced team members and help them gain the confidence and skills needed to thrive. Mobs at New Relic put the less experienced engineers in the driver role more frequently to help ramp up their learning and skills and get them contributing from day one. Our senior engineers often prove to be excellent mentors, taking care to encourage, not just dictate to, junior engineers. With that being said, it’s still a manager’s responsibility to coach both junior and senior team members as needed, whether or not they’re using mob programming.

What about introverts?

This is a great question, as mobbing can certainly be exhausting, especially for engineers who best thrive outside of group settings. We encourage teams to write working agreements with provisions that allow members to spend less time in the mob if they’d rather work alone—with no judgements passed.

Does mob programming hide engineers who are struggling? How do managers evaluate individuals if they spend all their time in a mob?

If they’re not careful, mob programming can cause managers to lose visibility into the performance of individual team members. Managers may have a difficult time detecting if a team member is coasting or struggling. For example, I sometimes hear from engineers that they feel disengaged when not in the driver role (i.e., running the keyboard) while mobbing. As managers, it’s our duty to be aware of such risks and ensure we’re getting the feedback we need to help make all our team members successful.

If your team is heavily invested in mob programming, here are a few things you can do to ensure you’re able to successfully evaluate your reports as individuals:

• Hold regular one-on-one discussions with your engineers. If a team spends a great deal of time mobbing, it can be difficult to ascertain the technical progress for each individual. One-on-ones are a great tool for managers to build trust and to help with any problems they encounter.
• Use 360-degree feedback. Peers can often provide great insights into each other’s growth and success. Don’t forget to look beyond the immediate mob; most engineers have interactions with other teams, especially, for example, if they’ve worked on support escalations.
• See the full picture. We often encourage engineers to take on side projects or other solo work alongside their mob duties, which can benefit both the individual and the company. Managers should look at all contributions, not just those defined as mission critical (which is where the mob tends to focus).

Closing thoughts

As managers, our main goal is to ensure our teams—and the individuals on them—stay healthy, curious, and productive. If our teams adopt the mob programming model, that doesn’t mean that they no longer need us. We need to remain their guideposts. Assist them during planning sessions and guide their priorities. Run their retrospectives. Help them write their working agreements and check in one-on-one to surface any potential problems. Be there to troubleshoot errors and celebrate successes.

Finally, don’t forget that it’s perfectly reasonable for managers to join the mob from time to time! It’s important to keep learning and flexing those coding muscles.

Watch the video below to hear New Relic engineers talk about the principles of mob programming and how it's impacted the software development process at New Relic.

In-line photos by Caito Scherr and Maureen Dugan.