Switching Pairs Within a Team

Pair programming is a classic method of spreading knowledge around a team. It’s when two software engineers work with one monitor on the same code, at the same time, with one or more keyboards. Combined with the switching pattern, it’s an awesome way to spread knowledge and learning around a team, as described in the following stories.

Richard Sheridan, reflecting back on his pre–Menlo Innovations days, told me about how he discovered Extreme Programming Explained by Kent Beck.¹ As a programmer himself, Richard was struck by something in Kent’s book. “It’s when Kent said, Think back like I did. When were you the most productive? I was the most productive when I worked closely with another person.” Richard reflected back to when he was a programmer and remembered when he paired with another person…that they were able to be productive together and that they had safety together to not make a big mistake.² He and James Goebel (who would later become his Menlo Innovations cofounder) decided to propose an experiment with their software engineers to try out extreme programming as a way to learn Java.

This was back in 1999. They wanted to spread the knowledge of Java around the team, which at the time was about 14 developers, and only 3 had knowledge of Java. They paired in order to spread the learning as quickly as possible.

As their experiment started to progress, they started what he called dynamic re-pairing. To his surprise, “there was actually a productivity to it that we hadn’t expected, and we just started tracking for that…. We paired people for two weeks at a time, and then we just let them sort of dynamically re-pair.”

After a while, they noticed that “cliques were starting to form.” To mitigate that, they started to assign the pairs. They framed it as an experiment: “We started orchestrating the pairs, almost like a square dance because we wanted to make sure, again, that everybody gets a chance to pair with everybody.” People liked that because it took away the social pressure of trying to figure out who they were going to pair with. If you were picked last for a pair it could get very awkward.

The side effect of this pairing system was that people formed new friendships. As Richard said, “Some of them, they have worked with for a decade or more, but they never worked with them quite like they had in this circumstance. So suddenly there was this new energy about getting to know people in the team, and believe me, these were introverted engineers, right? So this was not their natural inclination.”

After interviewing Richard, I reviewed his book, Joy, Inc. He recounts this story there, too. What strikes me from the book is the following passage. Richard wrote about what the atmosphere was like on this team during this experiment: “I couldn’t believe what I saw immediately in this new space: energy, noise, collaboration, progress, work, learning, and fun. In a word, joy. (Although I wouldn’t think of it in those terms until years later).”³

This switch from solo programming to pair programming was a huge, animated contrast. Moreover, the switching of the pairs in particular brought additional fulfillment to the people who were present in that space. When you switch pairs, or teams for that matter, you are exposed to new people and new ideas. You just learn more. That feels good to us as humans.

When I was at AppFolio, especially in the early years, we always kept an anchor when we switched pairs. An anchor is a concept we learned from Pivotal Software, who trained us way back when. One engineer would stay with the work, while another engineer would rotate in. That’s not the only way to apply the switching pattern to pair programming, as this next story, also from Menlo Innovations, illustrates.

Switching Pairs Out Completely for Problem Solving

Another benefit to switching pairs was revealed in a story Richard told me was a “magical moment” for him. It was about two engineers who paired on a bug for two weeks but couldn’t figure it out. When you’re in a situation like that, you feel like you have so much time invested that you might be hesitant to switch out (or split up) the pair. But Richard’s cofounder, James, suggested that they try an experiment. They didn’t just switch in one person in the pair; instead, they reassigned the bug to two different people entirely. The two people switched in were one experienced developer and one junior developer—and those two people wound up solving the bug in an hour.  

“The whole idea of keeping the same people doing the same thing over and over again, which is this fundamental belief from productivity and efficiency and all that sort of thing, is a false premise,” according to Richard. He talked about the pattern he saw when a pair cycled off of some work and a new pair cycled into it: “The people who supposedly didn’t know as much […] were better contributors than the long-standing team members.” In addition, those long-standing team members were excited about having a chance. In his words, “What you saw in them was excitement. You saw human energy. They’re thinking, Oh, I get to learn something new. I’m not doing the same thing over and over and over again.”

The huge insight for Richard is best articulated in his words: “It challenged my thinking as a manager, as a director, as a vice president. And, things I thought were true probably weren’t. […] James and I at that moment were forever changed, and we’ve never varied.”⁴

As I alluded to earlier in this chapter, in my experience at AppFolio it was very rare (at least in the first nine years, from my vantage point) to entirely switch out one pair for another. It was more common for us to keep part of the pair on the story, and switch out one person. So we had the continuity of the original person and the addition of the new “brain” to the mix. Learning this story from Richard really shifted my thinking. There are so many different ways to work. In his book, he talked about the shift from “less I to more we.”  In his words, “If a pair was silently stuck at their computer, staring motionless at the screen, another pair would arrive and ask, What’s going on? It felt safe and nurturing, rather than competitive and tense.”⁵ This is a strong sense of “whole team.”

Switching pairs within a team is one way that the switching pattern shows up in organizations. But that’s not the only level. Sometimes we switch one person from one team to another with the deliberate goal of sharing knowledge, as the next story illustrates.

Deliberate Switching at a Cadence to Share Knowledge

Switching teams to spread knowledge deliberately is also commonplace at Pivotal Software, where the company automates the deployment of “platform as a service” as its business. In fact, it’s built into the organizational strategy, as relayed to me by Evan Willey, director of program management. Using a home-grown tool called Allocations, created while consultants at the other division of their business were on the bench and not on client engagements, engineering managers and leads keep track of their 50+ teams and are able to understand and see who is on which team “now,” and for how long. Evan described Allocations as their “meta-level team creation activity that we do and team engineer rotation tool that we use.”⁶

Evan said, “Our engineering directors and leadership look at Allocations twice a week in set rituals.” They make decisions about who should remain on teams, and who might move to other teams. He explained the context like this:

Let’s see how we can kind of rejigger the overall makeup of the team. It’s fairly incremental. It changes week over week. It depends on factors like where the backlog is going, how critical is that team’s feature set, but also, are there engineers on the team who’ve been there for over nine months who are getting due to rotate out to another team? They’ll keep an eye on those factors as well to make sure that we’re not ending up with silos of information that are growing because somebody’s been on a team for two to three years and just becomes the holder of all knowledge.

Their organizational structure and code organization is designed to match their reteaming. Each team at Pivotal is fairly atomic, and in Evan’s words, “We really try to maintain as much contract-based, API-based separation of concerns between teams as much as we can. We try not to share codebases between teams. All the Git repos for a particular team’s feature are wholly owned by that team, and if another team is going to make an addition or change to that codebase, they’ll either do it with a pull request or through cross-team pairing—where we would kind of send one half of a pair over to the dependency holding team and one half of that team’s pair back to the upstream team to work on that feature.”

Pivotal Software has two levels of deliberate reteaming to spread knowledge. Through its strong pair programming culture, within-team switching is highly encouraged. Pairs are like microteams within teams. Two people are continuously integrating ideas. And then the pairs switch, and knowledge is spread around within the team. “If you don’t have pair rotation within a team, it can get kind of stagnant, and eventually it gets a little frustrating for the folks that are on that team, so we try to keep that from happening,” said Evan. I asked Evan to describe the concept of “stagnation” further. (This is a word that came up across many of my reteaming interviews.) He said he was referring to the collaboration: “You don’t get the variety of interactions that you would if you were more frequently rotating within the team.”

Pair switching is so important in the “Pivotal process” that it’s tied to a role. The “anchor” role on the company’s teams is the developer responsible for the delivery health of their team. This person is also responsible for making sure that their pair rotation within the team is taking place successfully. They are also making sure that the retrospectives take place and that standups are healthy.

The second level of reteaming is cross-team. If one team has a dependency with another team, Evan told me that “those teams may arrange to swap pairs, and somebody might go from one team to another team for a few days or a week to get the feature done.” This is a very functional reteaming with a clear goal.

Besides cross-team switching for getting dependencies completed, they also switch teams to proactively share knowledge. According to Evan, “knowledge sharing generally happens through the ongoing rotation of engineers through all the teams so that they get a variety of different kinds of teams to work with.”

By working with different people on different subject matter, we can learn new things from each other and make the knowledge stickier in our companies. This helps us to deliberately sustain the knowledge. It’s good risk management. It’s quite the opposite of the Tower of Knowledge anti-pattern described by Richard Sheridan in Chapter 10. “We like to build that generalism amongst the entire engineering staff,” Evan told me. “We really believe in generalism and that it leads to empathy. So we aren’t creating my team versus that team because I might be on that team for a month. It helps us outsmart the Mythical Man-Month a little bit as well.⁷ So that if we have a critical project or if we get in the middle of a release and there’s a feature that becomes a long pull, and it’s falling behind and it’s the thing we said is a must have for the release, we do have the option to make the team that’s working on that feature stronger.” Because the team switching happens, it takes less time and effort to switch over and help out another team: “We already have a larger pool of folks that already have familiarity in that team’s domain and feature.”

This reteaming is quite contrary to the now-seemingly antiquated, canonical software organizational advice that encourages us to keep our teams stable or “the same” as a strategy. I’m blown away, frankly, by this deliberate generalism. It’s almost as if they are creating microorganisms that move around within the team and across teams. This brings up visuals of building an organization that really moves. It’s antistagnation. It’s alive.

There are other reasons why we might encourage the switching pattern across our teams, and they’re human ones, discussed next.

Rotating Developers for Friendship and Pairing

I was working once with three teams at AppFolio. The developers pair programmed. When we made the switch from one team to two teams using the grow-and-split pattern discussed earlier in this book, and then added a few team members to form three teams, some of the developers were sad that they could no longer pair program with their friends who were now on “other teams.”

So we started a regular rotation of one engineer from team to team, as shown in Figure 9-2, in order to address that concern and to provide more fulfillment to these engineers. That was pretty dynamic in that context.

Figure 9-2. Rotation of engineers between teams

Comron Sattari reminisced with me about this. In his words: “So eventually you want to rotate people out. But you don’t want to rotate everyone out at once. So what we ended up doing, I think every six weeks or every couple of sprints we would rotate one person out. So three of the team members stayed the same, and we’d take one person from another team and would rotate people out. Eventually the teams would get all mixed up and you’d get that bigger team mentality because you’re working with everybody but you’ve got more focus on the smaller team.”⁸

He elaborated on what this was like for him: “It was really good because you had that momentum with your team. You knew what everyone was working on. We’d sit right next to each other. Communication was super easy. But then every few weeks you get new blood, new ideas, new faces, and they are people you see every day in the office, obviously. I was on a team, I really liked working with Donnie, but Donnie was on another team. But I knew in a couple weeks he might be on my team and we could do something new together.”

There isn’t a one-size-fits-all cadence to use for team rotation. Start somewhere, visualize your reteaming, align on why you’re doing it, and reflect at a regular cadence to grow and evolve to the best situation for your team. And better yet, listen to your developers. See what they need. I love how AppFolio adjusted with the hope of bringing fulfillment to these engineers.

Fulfillment at work is one of the keys to engagement and retention. When we are able to pursue our learning goals within the companies we are working at, it’s like we’ve struck gold because we’ll probably look forward to coming to work each day. This brings us to the next section about switching.

Switching for Personal Growth and Learning

It’s nice when people aren’t stuck in one team forever and when we view people with a growth mindset as opposed to a fixed one.⁹ We can learn and grow and change in our lives. It’s more engaging when we are learning and interacting with different people.

At Jama Software in Portland, Oregon, where at the writing of this book they had around 35 engineers, Cristian Fuentes, an engineering manager, has seen the company grow from about 9 people to 140 people. Cristian told me about how their team members self-select onto different teams depending on work needs and personal interests. People have the opportunity to leave the team they are on now and switch to a different team that matches what they want to learn. He said, “If a team member has been working on an API-type of project […] and they want to learn frontend, for example, they move to one of the teams working on frontend-type features for their own career growth.” When you find the right fit, and you are enjoying your team, you might not change teams. In his words, “Right now we’re at a point where there’s certain teams or team members that have really enjoyed working together—so they stuck together. There are other team members that still move around teams.”¹⁰

At AppFolio, we were organized with feature teams that could really work on any part of our property management application. We had a few more specialized teams when I was there, one that built and maintained the data centers that housed our software, a handful of other teams that focused on noncustomer visible infrastructure projects for customers and others in the engineering team, and a tech support team. I worked with all of these teams throughout the years in an agile coaching capacity.

From time to time, engineers would rotate in and out of infrastructure teams. One engineer told me that working in those teams, as opposed to feature teams, provided different, larger, more systemic problems to solve. And, the product managers were other engineers. That was very motivating to him.

People in our tech support team would leave their team and go work on feature teams from time to time. There, they would gain specialized knowledge of the features they would support when they returned back to their tech support team. There was at least one instance where a tech support engineer left their team and then stayed over in a feature team. It’s nice that the company was flexible to allow for this personal growth and choice.

Enabling switching can be considered a strategic advantage. Mike Boufford, CTO at Greenhouse, views it as a “secret weapon.” When people have been working somewhere for a while, they might just get the itch for change. So when you rotate them to a different team “their itch has been scratched.” He said, “I actually think it’s like a secret weapon in retention to give people the opportunity to move between teams and change their environment a bit.”¹¹

We’ve gone over several different facets of the switching pattern. We’ve seen how it applies when switching pairs within teams as well as across teams. You can apply the switching pattern for knowledge sharing, and to encourage the fulfillment and learning of your people. It also has the potential to enable awesome transformative learning for people to reinvent themselves at work. Sounds good, right? There are also pitfalls to this pattern.

Pitfalls of the Switching Pattern

Keeping the people and their personal development in mind is one aspect of switching. There can be threats to this, which lead us to sometimes want to restrict switching because we want to keep the best people on our teams. Additionally, if there is very low knowledge redundancy on our team, switching can be quite painful, so we might desire to avoid it. Furthermore, if we have single specialist roles on our teams, and when they’re the only ones on our teams, it’s probably more challenging to embark on switching. Let’s explore these three pitfalls, starting with the desire to hoard good team members.