Reteaming Decreases the Development of Knowledge Silos

The notion of “bus count” or “bus factor” is not new in the software industry. If you increase your bus count, which is the number of people who know about something—like a specialized technology in your company—you are safer.¹ If one of those people leaves, someone else knows enough about the technology to carry it on into the future, hopefully without too much pain. It’s building in redundancy of knowledge, which is better for your company—kind of like a group memory.

But it’s not good enough to just add people to teams to be safe. After all, you don’t want your individual teams to be too big because that can bring other problems unless managed and facilitated well. These problems might include longer meetings where not everyone speaks or is engaged, lack of visibility on work, difficulty making decisions, and poor coordination.

Within a team, pair programming and test-driven development (TDD) are ways to facilitate a more effective bus count within a team. The quality of interactions on the bus matters! If all the people are sitting on the bus in separate seats with their headphones on working alone, it’s quite different than when they are in rows of two people sitting side-by-side working with each other, like pairing. Switching pairing seats on the bus is even better because each mind learns from other perspectives. It’s even more diverse and probably safer when all the people on the bus are collaborating with each other, like in mob programming.

On a team-to-team level, you can reduce the risk of developing knowledge silos by reteaming. Spreading knowledge out from one team to another is a great way to keep your company safer and your developers less siloed. We had collective code ownership at AppFolio. As the years went on, pockets of specialization emerged on teams. Trends would develop. Team A would get assigned work on the same feature set over and over again. The members became the experts in that feature set. It was a critical feature set. After a while, we started reteaming to spread the knowledge out deliberately so that Team B could work on the feature set, too. It gave the organization more flexibility and safety.

There is a tension here, however. You want enough code ownership so that people can progress quickly on their work and care about the bigger picture, but you don’t want to typecast people or teams so that they are stuck working on “that feature” only. Silos are emergent. Be mindful of them and notice when they occur so that you can proactively reteam.

Beneficial silos are another story. You want to create them for a different purpose. See Chapter 7 for more on this.

Reteaming Reduces Team Member Attrition by Providing Career Growth Opportunities

Your organization can become “stickier,” and people might be less likely to leave it, if you provide people with opportunities to learn from others by reteaming and re-roleing.

At AppFolio, engineers had the opportunity to switch into other teams from time to time to provide anti–career stagnation. For example, engineers could leave a feature team and then go over to the data center development team to learn something completely different. Or they could move over to an infrastructure team to work on some systemic code challenges. Tech support engineers could spend time over on feature development teams as well. Some of the engineers who explored something different decided to go back to their original teams, while others stayed in their new team.

Sandy Mamoli talks about how tribes reteamed every six months at Trade Me in New Zealand. Even if there was still work continuing on at that six-month marker, people had the opportunity to work on a completely different team and mission if they so desired. It anchored with their company’s important value of autonomy. William Them, who worked within a particular tribe at Trade Me, shared how they do that in his teams every few weeks, which I discuss in more detail in Chapter 8.

As humans, we change with time. If we have the mindset of lifelong learning, we are never really “finished” developing ourselves. Companies can be compatible with visions like this and enable team and role movement for their people. It helps retain them. Why wouldn’t we want to retain good people in our companies?

Reteaming Decreases Inter-Team Competition, Fostering a Whole-Team Mentality

The last thing you want in your company is to have multiple teams at war with each other, competing and comparing themselves. We need to work together across our teams. Especially if we share a huge codebase that has cross-team dependencies that need to be worked out with close collaboration.

Having the ability to switch teams and work across them is important, according to Comron Sattari, who reflected on his time at AppFolio. As he recalled to me, “Mixing up team members all the time is important. You don’t want to break up the overall engineering teams into the smaller teams, and then have this tribal warfare where this team gets good projects because there are senior members in it. For example, like allowing one team to work on database stuff while the other team doesn’t. So if you mix them around there is not necessarily team loyalty so much, and it just makes communication easier.”² You decrease the notion of us versus them with reteaming. You can foster a greater sense of a whole collective team.

At Pivotal Software, Evan Willey also talked about how reteaming helps to reduce inter-team competition via its ability to help teams build empathy for each other. When switching teams and working on different areas of the codebase, you help to build generalism—that is, the opposite of being a specialist in only one area of the code. He said, “Generalism also leads to empathy. So we are not creating my team versus that team because I might be on that team in a month.”³ So beyond sharing code, we share the sense of being on the same team.

Reteaming Yields Teams That Aren’t Ossified, Making It Potentially Easier to Integrate Newcomers

New teams made up of people who don’t know each other are a challenge because you want the teams to gel and collaborate well to accomplish their goals. The opposite challenge is when teams are together too long. In that case, you have a greater chance of people having stronger bonds and being less open to change. The team culture is more solidified. People know what to expect, have “inside jokes,” and share a history. This is an obstacle to integrating new people into the team system. It’s hard to break into the culture that has formed.⁴

During periods of hypergrowth in a company, when reteaming might feel rampant, this problem seems to take care of itself. The reteaming feels commonplace, as detailed in examples in this book from AppFolio in particular.

We’ll see later on that companies such as Pivotal Software and Menlo Innovations, which both deliberately reteam either at regular cadences or due to the emergence of new work, might have an easier time assimilating new employees because of these practices. The change cadence is baked in.

Regardless, as time passes, teams age and change, so preparing for it is key.

Reteaming Is Going to Happen

In this section we’ve gone over how reteaming helps decrease knowledge silos, reduces attrition, provides career growth opportunities, decreases inter-team competition, and makes it potentially easier to integrate new hires. These are all good reasons for why we might catalyze or start team change to reduce the risk that we will lose people or have challenging situations later. However, this is only part of the story of dynamic reteaming. Reteaming becomes riskier when you’re impacting more than one person. Proceed with extreme caution when attempting a batch reteaming, such as a reorganization of hundreds of people or more. See Chapter 12 for ideas on how to approach this challenge.

In the words of scholars Ruth Wageman, Heidi Gardner, and Mark Mortensen, "Bounded and stable membership is less and less the norm as teams become more dynamic and are frequently overlapping.”⁵ I’ve seen this for 20 years, and it shows up in predictable patterns described in this book. People are going to come and go from teams due to their own life circumstances. Your company could get acquired by another company, and through a reorg, you might suddenly find yourself on a different team. Your company might change directions next quarter, and you might get reassigned to work on something different. You might even catalyze team change for yourself. Whatever the case, team change is inevitable. You need to prepare for it. This book is your guide. Study the patterns and stories we’ll cover next in Part II, and get ready for dynamic reteaming.