Pairing As A Manager

I manage a team developers. Every two weeks, I pair-program with each person on the team for an hour. If you’re a software developer managing developers, the ability to pair-program is a unique skill you have that you should take advantage of.

Pair programming helps me gather information, enforces communication and collaboration norms, and (sometimes) helps us solve tricky technical problems.

Gathering Information

I typically pair on whatever the developer is working on. Managing means writing code is squeezed out (as it should be) in favor of other work. Instead of producing directly, I support the team in producing. One side-effect of being out of the code is losing touch with what it’s like to work in the codebase, infrastructure, and environment. I don’t feel the pain of poor infrastructure or design, or the payoff of great tooling or tech choices.

Part of my job is to provide an environment for developers to do their best work. I pair to see if I’m providing that environment technically. Is it hard to make changes? Are our builds flaky? Do we take too long to spin up new services? The team can tell me, but I learn different things when experiencing it directly while pairing. I use this information to prioritize technical investment. We might push off some feature work to speed up our deploys or refactor a gnarly module.

Communication and Collaboration Norms

The team is fully distributed and rarely meets in person. Working remotely requires individual communication skills and a shared culture of collaboration. We don’t get ad-hoc collaboration for free like an in-person team. We also miss out on a lot of signal around mood, body language, facial expressions, etc. That’s a weakness of remote teams. To fortify our team against this, we have to deliberately craft our team culture and values to encourage collaboration, asking questions, reaching out, responding, and working together well. We don’t pair full time (I would quickly dissolve in to slime and ooze away to another job in such an environment). However, we pair regularly and with little ceremony. This helps us share information, solve problems, get to know each other better, and make up for missing those out-of-band communication channels like lunch, passing in the office, etc.

By pairing as a manager, I signal to the team that collaboration is important enough for me to choose to do it over other things. This rolls down to other team members. We pair more after I instituted it, and individuals pair more with each other without any direct encouragement from me. Pairing as a manager helps our team communicate more and makes us a stronger remote team.

Solving Technical Problems

The least important reason to pair as a manager is to crank stuff out. Sometimes I can help unblock or share context and really move a task along. Sometimes I have insight or help to offer as another set of eyeballs connected to a brain that understands code. Sometimes I just follow along and learn. I think I’m slightly less effective as a pair than I was as an individual contributor because I have less context in the code. However, I still think it’s a net positive for the developers I’m pairing with. I should probably ask them, though would they tell me if I was wasting their time? 🤔

Potential Downsides

Pairing as a manager has downsides. The power dynamics can get strange. Developers are pairing with their boss. They could feel pressure to give a good impression, or feel like expressing doubt or missteps will reflect poorly on them. I try my best to head off these concerns, but I can’t completely eliminate power dynamics.

Pair As A Manager

Despite downsides, the benefits of gathering direct information, modeling norms of communication and collaboration, and working together to solve hard problems outweigh the costs.

Have you paired with your team as a manager? Do you have different experiences? Are you trying this out for the first time? Let me know what you think on Twitter at @jamison_dance.