So far, we’ve talked about pairing as if it’s just you and a partner with total agency in how you do your programming work. In reality, you’re probably part of an organization or at least a team that has an opinion on how, when, and with whom you program. You might think you won’t be able to pair program in your situation, or that your boss would never get on board with it (though there’s a good chance they would love the results). In this chapter, we’ll navigate how to incrementally add pair programming to your organization at the right pace and level of subtlety to give it a fair shot.
Before you eagerly dive into pairing, you need to be circumspect: What is the team’s attitude toward pairing, and how will it affect your ability to find a partner and successfully work together, even for short stretches? Will it attract resentment from your peers or a skeptical look from anyone in management?
I’ll be honest: I’m a manager myself, and I’m most inspired by employees who come to one-on-ones and team retrospectives prepared with questions, ideas, or topics they’ve been thinking about. It shows that the employee values my leadership and cares about my managerial agenda.
If no one on your team has paired before and you want buy-in from the top before you begin, consider: what are your manager’s objectives and priorities when it comes to pairing? Are there larger company values (knowledge-sharing or cross-training) or objectives (reducing churn, defects, helpdesk calls, or missed deadlines) that would support a pairing initiative?
- Start from shared values. You can lay some groundwork just by being a good listener and staying curious about the problems management deals with on a regular basis. Learn their thoughts on coordination costs, time wasted on red herrings, reducing training costs, or the consequences of a programmer’s over- or under-confidence. What are their ideas to reduce wasted effort and improve output quality? Don’t get too evangelical or push any agenda—but do pay attention to opportunities where pairing might offer advantages.
- Tap into their experiences. Your manager has probably been building software for a long time. What have been their experiences with doing code reviews, talking through problems with a coworker, or sharing creative control? How have they seen cross-training or mentorship work best?
- Take interest in sharing knowledge. A manager who is responsible for personnel development should be looking for ways to spread the knowledge and experience that more senior team members have. You can suggest pairing part-time—either with someone more junior than you or with someone you’d like to learn from—as a career development opportunity. You’ll either look generous with your knowledge and time or hungry to learn, both of which are attitudes most managers want to encourage if they’re even remotely serious about developing a robust and effective team.
- Emphasize the value of risk mitigation. Single points of failure are dangerous, as we discussed with the bus factor. Surely your manager has been left in the lurch when someone quit or took a sudden leave of absence. If you demonstrate attention to the business risks that pair programming mitigates, not only will you support a case for pairing, you’ll also build affinity with your manager and show them support. You might also point to research showing improvements in the code as a result of pairing; what are the consequences if your team allows a big mistake to slip through?
- Annual reviews, check-ins, and even one-on-ones are great times to discuss pair programming. With a little prior reflection, you can align it with personal and team goals. Don’t let these opportunities to talk to your manager sneak up on you!
It’s great to work with your manager’s blessing if you can get it, but even if you can’t (or, more likely, your manager is too busy to think about implementing a top-down, team-wide pairing effort), you might find just as much success by adopting some of the practices of pairing with your colleagues gradually and non-disruptively. The goal is to approach it like an experiment, testing the hypothesis that pair programming produces better software faster than two people would individually.
- Find your co-conspirator(s). Who is most tuned-in to XP and continuous improvement? For teammates who seem open, propose that you experiment together with pair programming. If they’re more reluctant, ask if they would be open to helping each other with stories from time to time.
- Try a few short sessions with a lightweight setup (screen sharing or collaborative editor; act like you’re remote even if you’re close by) to see if you work well together.
- Keep the momentum going. If you’re not explicitly pairing, you can start by simply saying, “Wow, I really like working together on stories. Can we do this more often? How about for a half-hour every Friday?” A month later: “This is great! Can we increase our time to an hour?”
- Identify some KPIs (key performance indicators, in manager-speak) that pairing is helping. Productivity is highly subjective, so think about what matters to your boss and your team. Tracking the number of story points completed or defects produced can be meaningful. What matters might be subjective, like familiarity with the codebase or the amount of confidence you feel, but you can still assign it points or a rating scale to measure it.
- Start pairing slowly at first—short, occasional sessions without a lot of pressure. You want it to work, and jumping in too quickly might jeopardize the experiment. Don’t overestimate how adaptable you are. It takes time to get used to a new way of working.
Take some notes after each pairing session so you can look back over your progress later. Whatever metrics you’re tracking, the more diligently you measure them and track how these KPIs improve as you pair, the better you can defend your choice and get buy-in to make it an official practice on your team. What did you work on? What did you learn? What domain knowledge, tools, or parts of the system did you become acquainted with because of your partner? You might be enjoying pairing, but if it’s not leading to quality and productivity gains, you’ll have difficulty getting the rest of the team or your manager on board.
We’ve talked about how pairing eliminates silos, but if two members of the team get in a rut of always pairing with each other, they can create a silo of their own. No matter how well-intentioned the rationale may be, any imbalance in pairing frequency is leaving some knowledge on the table.
To combat this, many pairing teams draw a pairing matrix on a whiteboard or keep a spreadsheet that tallies how many times any two people have paired. This way, you can correct for imbalances without having to explicitly make a pairing schedule. You can see who pairs together a lot and steer toward the less common pairings when you have the freedom to do so.
Pair rotation sounds simple enough in theory, but in practice, it’s a lot harder than you’d think. Do you break up a pair in the middle of a long-running story? There are pros and cons. Do you have an anchor that sees the story through to the end, or does that create a power imbalance because the anchor becomes the de-facto owner and will probably end up driving a lot? These are things to work out in your retrospectives. Remember, the team should be willing to try anything once, as long as it’s a small change that doesn’t kill your productivity. Once you’ve tried something, be honest about how it compares and whether it’s worth continuing.
Avoiding institutionalization and calcification
You may have fought a long hard battle to get pairing accepted among your team, but now you have a new challenge: resisting central planning and rigid institution of pair programming. Among managers, a common reaction to a new way of working is to mandate, manage, and control it. It’s pairing by fiat: Somebody in charge makes a plan that assigns who is pairing with whom and on what story. They define exactly how pair programming works, so everyone will do it right. A pairing schedule goes on the wall, and procurement gets a purchase order for ten chess clocks.
In some organizations, this is the best you can hope for, but the ideal is to self-organize based on what needs to be done. It’s a bit like the difference between project planning by Gantt chart versus an Agile or Scrum board. The former doesn’t take in all the information and can’t keep up with changes on the ground as they happen. It gives a false sense of security that all the uncertainty is being managed when really, it’s better to define the objectives clearly and let smart people figure out how best to get there.
If your boss is pushing rigid pairing practices, the best way to deal with these mandates is to approach them with an inquisitive mindset. Ask what they’re hoping to get out of the pairing schedule. A few weeks later, ask them how it’s working. A few weeks after that, ask if they considered a pairing matrix to accomplish the same goal.
If you are the manager who wants your team to pair, be intentional about where you want to see your team headed and the steps to get there, don’t push it too fast, and remember that these practices serve the outcomes; we don’t serve the practices for their own sake. If there’s another way to get there, so be it!
Wherever you fall on the org chart, remember to keep an open mindset of experimentation and “trying anything once.” That’s how organizations keep up with changing best practices and create a community of continuous learning and self-reinforcement.
There’s an old story of a newly married couple that bakes their first brisket together. The meat turns out delicious, but the husband asks the wife, “Why did you cut off the ends? That’s the best part!” She answers, “I don’t know; that’s the way my mother always made it.” They ask the mother why, and she gives the same response. Finally, they ask the grandmother, and she says, “Because my pan wasn’t big enough!”
In programming, we also tend to do things just because we’ve always done them that way, or we followed someone else without really examining if they need to be done or if there’s a better way. Pairing gives us the opportunity to see how someone else works, the mental space to ask “why?”, the courage to try completely new things with a partner, and the opportunity to share what you learned with the broader team.
Pair programming doesn’t only transfer technical knowledge—like how to use a framework, how a codebase was architected, or tools and techniques to make your programming more efficient. It also transfers implicit knowledge—the experiences, routines, strategies, and intuition that members of a team accumulate over the arc of their careers. When this knowledge is shared among a team, an informal Community of Practice (CoP) can form, where individuals lean on each other to share insights, gain knowledge, and advance their practice.
At its core, a CoP is about a self-motivated commitment to making software the best way possible through a set of shared practices and values. It’s a critical mass of continuous learners who naturally share their knowledge and humbly open themselves to the wide world of things they don’t know.
Pair programming is an important tactic (but not the only one by any means) to develop a strategic CoP among software engineers. Pairing helps develop implicitly shared practices that transcend two perspectives through pair rotation, cross-pollination by proximity, and collective reflection on the pairing process.