Chapter 6. Grow-and-Split Pattern

A natural consequence of a lot of one-by-one reteaming is the grow-and-split pattern. The more people you add to existing teams, the bigger those teams get. At times with growth like this, you might experience some drag in the system. Things feel like they are taking longer than they used to because there are so many more people. Decision making might be stalled, and you might need to apply some new tactics to move forward. Then the grow-and-split pattern kicks in, to structurally split the large team into two or more smaller teams, as shown in Figure 6-1.

Grow-and-split pattern
Figure 6-1. Grow-and-split pattern

It could also be the case that you feel that the dynamics present on the existing team need to be shifted. Maybe the team has hit a stagnation or a rigidity trap, as we learned about in Chapter 1. Things aren’t working like they used to, it feels like the energy is not there, and you decide that, in theory at least, you might want to rejigger the team energy by splitting up the team.

So how do you know when to split a team? Let’s look at some signals that tell you when your team might be too big.

Signs That You Might Want to Split Your Team

I’ve noticed four key signs that lead up to teams splitting: meetings get longer, decision making is harder, the work diverges, and it’s harder to keep track of who is actually on the team. Sometimes these indicators brew for a while before someone decides to take action. The more this happens in a context, the more people wake up to the concept of morphing larger teams into smaller ones.

Are Your Meetings Getting Longer?

Grow and split is a pattern that many startups face early in their history, and it’s a memorable occasion when the first split happens. Comron Sattari, who was a software engineer at AppFolio during the early years, recalls:

When we were a really small startup early on, there were only four engineers, or five engineers. The communication was easy, the standups were short, and things like that. But when we got to be 12, 16, 20 people, all of the sudden we couldn’t do standups in 15 minutes anymore. The team communication was a lot of overhead. You were working on so many disparate things that you would switch to pair with someone else and would be a week behind, because you hadn’t worked with them in over a week. So they didn’t know what you were working on, or you didn’t know what they were working on. There was a lot of ramp-up that had to happen when the team got big.1

This was really the inception of having different feature teams at AppFolio, as he recalled, “We split into two, then three teams. Each of the teams was four or five engineers. I think at that point we had QA float around and help us, but eventually we had one QA person per team…those teams were given specific sections of the upcoming backlog, of the upcoming product plan. Instead of saying, OK team of 20 people, let’s do features one, two, three, four, and five, it was a team of four people, let’s do feature one.”

The downside was less pair programming variety for the engineers. As Comron put it, “All of a sudden you’re not working with the 10 other people on your engineering team.” That feels different and makes less possibility to learn from other people like you did before. Small teams are not the universal panacea for effectiveness. This particular team solved that by enacting a regular switching pattern a bit later in its development. See Chapter 9.

Besides the feel of longer meetings and overhead to keep up on what is going on, another signal that tells you the grow-and-split pattern has kicked in relates to decision making.

Is Decision Making Becoming More Difficult?

If your team is used to making decisions by consensus, as you add more and more people to your team, it will definitely become more challenging to do that. As Paige Garnick, an engineering manager from Procore Technologies told me, “We could be in a retro, and we’d want to try something new, and a majority of the people would say yes, but then there would be three or four people who would say no, and when you have three or four people who say no, the debate can last a long time. It was really hard to make decisions just for improving our processes.”2

When teams get big and they’re still together, in order to make decisions they might choose to apply a myriad of facilitation techniques to get through it. Creative facilitation can be applied to help larger teams work.3

In addition to decision making becoming more challenging when your team grows large, another challenge is that the work can become unrelated, and team members diverge into different directions.

Has the Work of the Team Become Unrelated?

When teams get larger, it feels like you have more capacity to get additional work done. This is probably why you grew bigger in the first place—you thought that if you hire more people, you can accomplish more.

When teams get too big, you might notice subgroups forming within teams, working on items that don’t necessarily pertain to the whole team at large. In her team, which grew to more than 10 people, Paige talked about the organic ways the team would try to manage its work. She said, “There were like two or maybe three projects going on at a time. And there would be eight to ten people that were working on it; they would split into groups of two or three focusing on the different things.” This was a natural divergence of the team. This splitting in order to handle divergent work is a tactic I’ve seen with teams that grow big, diverge into these “strike teams,” get the unrelated work done, and then return back to the larger team.

Moreover, in distributed teams, when the team grows, you might have the additional challenge of remembering who is on the team.

Are You Forgetting Who Is on Your Distributed Team?

Imagine everyone on a phone call with videos turned off. Even though everyone is likely on the call, you might have pockets of silence. You might notice less participation from some of the people on team during your team meetings. They were likely more included and engaged before the team grew so big.

Agile coach Mark Kilby, who works with purely distributed teams at a DevOps tooling company, experienced this situation and said, “If you’ve got team members forgetting who else is in the meeting, that’s usually a signal right there, or if you realize that you haven’t really heard from a team member in the last two or three standups, it’s maybe a signal that the team is too big. I want to make sure everyone has a chance to have their voice in conversations.”4 I can relate to what Mark is saying from my experiences in teams that have grown big. During meetings, it’s not uncommon for only a few people to speak, and everyone else remains silent. If the team is distributed, the problem is just compounded and you can’t necessarily “see” the people unless you’re all connected with video.

The first step in splitting your team is realizing the challenges described previously and coming to the conclusion that splitting the team is a valid option to consider. Executing the split is another story.

You’ve Decided to Split, Here’s How to Do It

Don’t just declare a split without consulting the team. Have respect for the people. Splitting a team without its involvement can cause a lot of resentment. Instead, coach the team to drive its own reteaming.

Include the Team in the Decision

So how do you go about splitting a team so you’re not just executing a top-down change without the team’s buy-in? Bring the team along, like Kristian Lindwall did at Spotify. He told me a story about a team split at his company.

He chose to bring up the split with one team by saying, “I’ve started noticing some changes and how involved people are in our standups in the morning. It seems like you guys are essentially forming subteams in the team. It seems like we are wasting some people’s time in our common meetings and stuff. Do you agree? Have you seen this? How do you feel about this?”5

Just asking a powerful question to teams about their structure can get the gears turning so they become participants in solving their problems and not just the recipients of a team change conceived by someone else.

Furthermore, socializing the idea that it’s OK to talk about changing our teams is another way you can create a culture that acknowledges that team change is normal, and that it’s just another lever to pull during the pursuit of effectiveness. I like to encourage teams to talk about their structure during regular retrospective meetings. In this way they can come up with ideas of how to shift their structure to better work together.

At any rate, once you’ve decided that, yes, we will split the team, there are many considerations to keep in mind. Splitting can be emotional and highly charged, as detailed in “The Emotional Challenge of Splitting Teams”. You need to proceed with caution. The “easiest” splits in my experience are the ones that were determined by the team itself. But sometimes that’s not the case, and someone from outside the team tries to influence it. Here are some guidelines.

Articulate Why You Are Splitting the Team

Why are you splitting the team? Being able to articulate the reason is important. Those around the team will want to know why this is happening. It might be because new work is coming in, and you have decided to have one team continue on existing work and the other pursue the new work. It could also be that the team just feels too big. Things are taking too long and you have decided you want to split the team in order to be more effective in how you go about work. Whatever the reason, get your “elevator pitch” together and align on it as a team so that everyone can socialize the idea inside and outside of the team.

Figure Out the Missions of the New Teams

Teams need a reason to exist, and that is typically connected to the work they are doing as a team. You can articulate their focus using mission statements. The mission is the “North Star goal.” Mission statements explain the why of the mission—one or two sentences describing why it’s important. When talking about Spotify teams, Kristian Lindwall shared some examples from his company, which makes software related to music playback. One of the features of its software is for users to put songs into playlists. He said, “One mission could have been Create a rewarding experience for the user to shape their Spotify identity through playlists.” A different example is from the Holistic Experience team, whose mission was to “Empower other squads to shift into a higher quality, coherent user experience.”

It’s important to partner with other team members to create the missions. Kristian described this:

I was coaching the team, and there was also the product owner who was driving the whole area. So we had a couple of conversations and the product owner in this situation, then drafted a few suggestions for missions that this broader mission could be split into. We then brought in the whole team—everyone—to look at those. Some were challenged and changed heavily, and others were just refined. We ended up with three that would kind of still solve the bigger problem, the bigger mission, and in this case we then said, “Okay, so these are the missions, now we need to figure out how to split this team into this.”6

You might be figuring out which people will go onto each team in the course of having discussions about the missions. So how do you assign people to work on these missions?

Determine Who Will Go on Each Team

In the case of the Spotify example, what happened next was a brainstorming session in front of a whiteboard to encourage people to choose their own teams. Kristian said, “We just crafted the missions, drew circles on a whiteboard with the new teams, and put everyone’s face as an avatar up on the board and said, ‘So in a couple of days, let’s try to have these teams.’ And we started out by people just putting their face where they wanted to be. People started talking to each other. We were there to support the conversations, and, yes, after a couple of days we had a new team structure.”

I think it’s a good idea to give the people some choice in which team they will move into, like this example shows. Taking the situation to the team for problem solving can be very powerful. They’ve likely solved harder problems than team composition before.

I’ve also witnessed managers figuring out who will go on each team, and then working out the team assignments via one-on-ones with team members, and then all together in a group to make it official. There are different degrees of openness used to approach team change, as described in Chapter 3.

Once you’ve figured out who is going on each team, it’s a good idea to figure out the physical implications of this change, such as where the new teams are going to sit—that is, assuming that they are in the same location.

Come Up with a New Seating Plan for the Resulting Teams

Teams that are colocated should sit in the same area. They can have their own team space that, ideally, they can customize to express who they are as a team system. Once you decide to split teams, you need to figure out these logistics, and work with the appropriate people in your company to make these physical changes a reality.

You might not have the luxury in your setting to actually sit together in your team. If that is the case, some teams set up separate “team rooms” where they can go and have their meetings and events, and then they go back to their desks, wherever they may be. I’ve found that being not only colocated but also coseated—that is, sitting in the same area—is much more encouraging for collaboration.

None of this matters if your teams are distributed. If they are, there are tools and systems that you will need to update with your team split, as described later. See “Not Involving Your Facilities and Technology Groups Early Enough”.

Claiming who you are as a team system is something that I love to encourage teams to figure out, and we will explore this in the next section.

Figure out the Team Names

Naming your team is an expression of team identity and ownership. I’ve seen teams that are named after the tools that they create or the components that they build, and I’ve seen completely made-up, silly names dreamed up by the team members.

At AppFolio, it was a trend for years for the teams to name themselves. There was a trend to name the teams a combination of music band names and nerdy concepts. For instance, the first two teams were named Diff Leppard and Hex Pistols. The third team was called the Fu Fighters. Years later, teams branched out to movie names like Saving Private Repo, Ace of Rebase, or whatever else they wanted.

As the years went on, these team names lived on, too. People would move into these teams and out of these teams. Work would be assigned to the teams, changing based on company priority as the years went on. When the company grew, new people would be added to teams using the one-by-one pattern, as described in Chapter 5.

Typically, when the changes to the team were one by one, the teams would keep their existing team names. When the changes were larger or involved splitting to create more than one team, the result was two team names. One might have kept the original name while the other received a new one. Following that name change, the team would let other teams know.

Tell Others About the Resulting Team Assignment

The membership on each of the resulting teams after the split should be made clear to everyone, using the communication channels that exist in your company. Meaning, you should make it explicit and write out who is on each team to clear up any potential confusion about team composition. You could even draw a before and after picture on a whiteboard to depict who is on each of the two teams (or more if you’re splitting beyond that). See Chapter 12 for a visual of what a before and after picture might look like. Besides telling others about the reteaming, you can choose a date on the calendar to start up the new teams, with a formal kickoff event.

Formally Kick Off the New Teams

I like having team calibration sessions to get the new teams going. In these events—which could occur in as little as two hours, in my experience—you can discuss how you want to work together as a new team, talk about the mission and content of your work, and define what success and excellence looks like from the standpoint of how you work together as a team. There is a lot that can be considered for a team calibration, and it really depends on how much time you want to devote to it. For ideas, see “Team Calibration Sessions”.

I’ve witnessed many teams growing and splitting in different companies through the years. When you split a team, you are disrupting the team dynamic with the hope that it will result in a better situation. The best splits I’ve seen have been decided by the people in the team, usually after having many discussions about the possibility. But splitting teams is not an instant panacea for all of your team challenges. There are some difficulties that may come up.

Pitfalls of the Grow-and-Split Pattern

Sometimes when you split, if you’re not careful, you might trade one set of problems for another. Here are some pitfalls that have been challenging for the teams, and some ways you might mitigate them.

Shared People Across Teams

I often see teams that split and then share specialist roles like product manager, UX designer, and quality assurance engineer. This is a shift that takes a great deal of consideration because if you do have shared team members, they need to attend twice as many meetings (most likely), and that can be very challenging. The more shared people, the more it might feel like you’re just one big team, which defeats the purpose of the team split.

I’ve also seen teams that acknowledge this, and then get the approval to hire people to fill the slots on the resulting teams. It can sometimes take months to hire. If you do this, align with the team on how you will cope with this situation, and try to work across roles in order to move the work forward. The alternative is staying as a larger team until the hiring is complete and then splitting.

In addition to the pitfall of having shared people across teams, splitting in half might result in dependencies across the team, which bring another set of challenges.

Dealing with Dependencies Between Teams as a Result of the Split

Ideally, the work of the resulting teams is separate, and each of the teams can operate autonomously without having to consult excessively with another team. If the work is shared between the two teams, which is typical if you’re dealing with a monolith where all the code is together in the same codebase, you need to work out some way to keep the information flowing between the two teams so a change in one team doesn’t break code for the other team. There are different approaches to managing this type of situation, and people have written books covering just this. I will give a few pointers here.

First, you might consider applying ideas inspired by the Large-Scale Scrum (LeSS) Framework. In particular, there are planning sessions, retrospectives, and sprint reviews for each team individually and then across the teams. For example, in the case of one team that splits in half with a lot of dependencies, what might result is planning individually for both teams, and then an overall planning where point people from each team get together and share what is going on. The same can happen with retrospectives, and with sprint reviews, where you demonstrate the working software created in the iteration. This is a very simple application of the concept that is worked out in depth in the book Large-Scale Scrum.7

Second, a different approach is to follow the lead of Pivotal Software and AppFolio and apply the switching pattern, where team members pair across team boundaries to take care of dependencies (see Chapter 9). With this approach, which necessarily is coupled with writing test-driven, self-testing code, code ownership is more distributed and shared, and we work across boundaries to get things done. There is so much that I like about this approach because it also focuses deliberately on code quality.

Third, I’ve seen other companies rely on specific people to manage the cross-team dependencies. I’ve personally hired, managed, and grown technical project management groups as dependency managers across a multitude of teams. That can work, too, if the technical project managers have the mindset of being servant leaders aimed at helping the teams succeed. It really depends on hiring, training, and ongoing feedback to ensure that the technical project managers remain productive and successful. I’ve also witnessed managers serving in the role, acting kind of like “glue” between teams.

Carefully consider whether it’s actually a good idea to split a team if it results in shared work between the two teams. It might be less overhead and easier for the people if you keep them together due to the intertwined work.

If you do keep them together, you could lean into the art of facilitation to help a large team become more effective. Consider applying the facilitation patterns from Liberating Structures, which are designed to bring out full participation inside your teams. Another resource to dig into is the Facilitator’s Guide to Participatory Decision-Making, by Sam Kaner, for ideas on how to get better at building consensus and agreement on teams but also how to include others in decision making.8

One message I want you to get from this book is that we don’t change teams for the sake of changing teams, and we should not take it lightly or flippantly. You need to apply critical thinking and envision how things might play out after you reteam. Study and apply the planning techniques in Chapter 12.

Besides dependencies as a pitfall to splitting teams, there are other things to consider, such as how you time the team split.

Dragging Out the Split

Teams that decide to split sometimes make the agreement but then stagnate on that decision for a while. Maybe it’s because they do not choose a point person to be the “lead” of the split. Or maybe it’s because they are too busy doing their day-to-day work, and this idea of splitting takes effort and they haven’t yet devoted the time to it.

To all of this I say the following: Don’t let the team split drag on forever. Choose a date on the calendar for doing the split. Celebrate and have a party around the time that you change desks. Do it virtually if you are distributed. Get creative. Bring in a cake or some food to help commemorate the split and celebrate the end of the large team, if you are colocated. If you turn this into an event, it pushes it forward and makes it happen. I can’t emphasize this enough. Make it a point in time in which the change is acknowledged and felt to be real. Have all the logistics in place so that the team can really begin as a new team at that point. The teams can also use that time to come up with their team names that you can announce to the rest of the teams and department after the event.

I also like to encourage teams to create a schedule with milestones for the split. Especially if you have to coordinate with other groups to make your split happen, which is often the case in larger buildings with facilities and IT departments, as described in the next section. Don’t forget to line up these groups so that your split is not stalled.

Not Involving Your Facilities and Technology Groups Early Enough

Another pitfall to splitting your team is not involving others at the right time. So when you need them, they are not available. You don’t want delays when you choose to transform your teams. Instead, plan it in.

Why do we involve these groups? Well, we want to make sure any of your tooling is updated in advance of your team split event. Some teams need to update or create a new project in their work-tracking tool (like Jira). Other teams need to update tools (like GitHub). Maybe you need a new channel in your chat program (like Slack). New calendars or email addresses might need to be created for the teams. The smaller your company, the more likely you have direct access and control to manage the internal systems that your teams need. But as you grow larger, all of these things become more formal and are controlled by someone else.

I encourage you to determine the facilities implications for your team split in addition to the IT things, if you work in a colocated environment. Are your desks easily movable and reconfigurable? Do you need to schedule a desk move or reconfiguration with your facilities and IT groups? That could take some time, so plan for it.

In addition to these pitfalls, another that you might not think about in advance is the emotional impact and challenge of splitting teams.

The Emotional Challenge of Splitting Teams

It’s not always easy to split into different teams, and for at least one engineer I talked with, there was a feeling of sadness about not being able to work with the same people in quite the same way as before. At AppFolio, the office at the time was one large room. The engineers would still see each other within the physical space of the same room after the first team split in half, but that was not the same as working together on the code. It was a loss. Coming from a humanistic stance, as coaches, managers, and caring teammates we can pay attention to how people are feeling when teams split, giving extra time to listen and encouraging people to talk about what’s going on so that we can figure out the best way to support them.

It can be quite scary and emotional to split up a team, especially when it is the first team at the company, like the previous story from AppFolio. A similar sentiment happened, as recounted by Rachel Davies, a coach and development lead at Unruly, a London-based company that is in the digital advertising space. She told me about how their original team split into two teams. It was a highly significant event for the colocated team. Its identity was strong, as demonstrated by this story:

The large team decided that it had grown to a size where they might benefit from splitting. So they did split. But it was much more of a socially considered split, and what was interesting was they had a big retrospective about all their worries about splitting […] one of the team members even made a cake, and it was like a Lord of the Rings cake; it was a chocolate volcano with Lego figures on it, and it was the breaking of this fellowship. So they obviously felt emotional about breaking. Because a lot of the people had joined the company very early on in their career and then they had been there for quite a long time and they felt like, “Oh now we are splitting.”

Rachel explained that this split felt even more emotional and scary to the team because when many of these developers joined the company, the development team had been led by the CTO. This split also marked the time that the CTO went away from the team to work more closely with the business and to help foster the development of its new analytics product. So it went beyond being “just a team split.” It really represented a broader organizational change that impacted the people.

As it turned out later, the split put the team in a better place. As Rachel said, “There was a big surprise because they were much happier…we could get loads more done, and the standup was quicker.” Although the teams were worried about the change going into this, they were able to get more done with a narrower focus after the split. This split worked out so well that less than nine months later, one of the teams split in two again, in order to enable some specific, focused feature development work on their initial product. Team splitting was starting to become a pattern for Unruly.

Paige Garnick shared with me that when you feel such ownership and attachment to your code, it’s really hard to let it go. And that can slow down when a team splits. She said this when thinking of her experience: “The split took longer than we wanted it to because of that issue of letting go of code, you know, personal attachment.”9 The strength of code ownership can be an inhibitor of reteaming and is one of the constraints detailed later in Chapter 11.

In addition to team splits as described thus far, the grow-and-split pattern of dynamic reteaming can happen at levels beyond the cross-functional software team. It can happen at the tribe, or team-of-teams level, as stories in the next section describe.

Larger-Scale Splits

As I mentioned in “Panarchy”, team changes happen at different levels in organizations. It’s not just at the lowest team level. It can happen across multiple teams. It can happen in department, division, and company levels. Here are a some stories of these kinds of team splits.

Grow and Split at the Tribe Level

AppFolio consisted of cross-functional teams within its research and development (R&D) organization. They were grouped together, often around three to five teams each, into structures that they called colleges, which I will refer to as tribes in this book. This is similar to the structural concept of squads and tribes popularized by the company Spotify years ago.10

Tribes would sit together in the same region of the building, separated into different team areas. Engineers in each tribe were managed by one engineering tribe director, or a hands-on tech lead within the tribe, if it was a larger size. Other roles like QA engineer, UX designer, agile coach, or product manager had a different reporting structure, but sat in the same area with their teams.

The work that was done by the teams in the tribes, at least at the writing of this book, was pulled into the teams by choice from themed backlogs. This work used to be pushed out to the teams, but after feedback from the engineers that they wanted more choice, the organization made a shift to more of a pull system. Having collective code ownership gave this organization and the people in it flexibility on what they worked on, and didn’t corner them to working in only one area of the app.

As the company got bigger, it had a deliberate way to grow new tribes. As the teams multiplied, engineers were promoted to be tribe directors. When hiring someone from the outside to be a director, which would also happen, that person would first join an existing tribe and be part of a team as regular code contributor, as shown in Figure 6-2.

Grow and split at the tribe level
Figure 6-2. Grow and split at the tribe level

The existing tribe director was their mentor, teaching them the ins and outs of what it meant to be a director at this company. The new director would pair program with other team members on the regular work of the team. Team members knew that this new director was on their way to becoming the director of a new tribe. It could take several months for this to happen. This in-the-trenches experience helps the engineering directors build credibility and gain essential domain knowledge with the products as well as learn the characteristics of successful management in this context.

This also reduces the risk of bringing an outsider into a leadership role that might not be the right fit after getting to know them. Having a gradual entry in this way helps to manage that risk by making the person’s sphere of potential impact smaller until they get up to speed.

When up to speed, that director and their team break away to spawn a new, separate tribe. To grow this tribe, new people will be added, or people from another part of the engineering team will join. How is that done? It could be by using the grow-and-split pattern or by seeding the new team with members of the tribe’s original team so that the mentorship system can be present, as detailed in Chapter 5.

Tribes facilitate localized community and culture building. Having social events is a part of AppFolio’s culture, and it was not uncommon for each tribe to have a certain amount of money allocated for each team (and each tribe) to do team-building activities, including team dinners, short local excursions, wine tasting, or even events like Segway tours in their city of Santa Barbara.

This tribe structure helps you feel like you are at a smaller company even as your company grows in size. It’s a proactive way to combat Dunbar’s number, which is the theory that you can only successfully maintain relationships with around 150 people.11 People get to know others in their tribes, which facilitates future reteaming within their tribes. If you subscribe to the “forming, storming, norming, performing” philosophy of team development from Bruce Tuckman,12 in many ways, planned socialization at the tribe level proactively starts up some of that before the people change and are part of their new teams. It’s like priming for reteaming.

Besides growing and splitting at the tribe level with the onboarding of a new leader, as we just explored, there are other ways that larger-scale splits happen in our companies in order to attain particular goals. Next is a story from Greenhouse Software, where the company reteamed for a different type of goal—to realign its code ownership.

Grow and Split to Drive Code Ownership

At Greenhouse Software in New York, I spoke with Mike Boufford, CTO, as well as Andrew Lister, who is their senior director of engineering. They told me stories of how Greenhouse grew and scaled. At one point, when their team grew to about 60 engineers, they realized that they needed to reorganize so that they had more specific code ownership. Until that point, everyone would work on every part of the codebase, and so the owner of any area of code was really just “the last person who touched it.” As a result, there were many areas that didn’t have clear owners. Mike said, “We started realizing that everyone was kind of working on everything, and we hadn’t done a good job of carving up the work into bits and pieces that allowed for clear lines of ownership and accountability.”13

As their codebase grew, and as they added people—they went from 40 engineers to 60 in one year—the onboarding cognitive load grew as well. People felt like they needed to learn everything in order to be ramped up. The time needed to onboard new engineers grew with the size of their codebase, so they knew they’d run into challenges during the next phase of growth.

Furthermore, at Greenhouse they believe that engineers should be able to rotate from one squad to another—to work with different people, to keep up social connections, and to feel refreshed. The problem with their current structure was that, since every team would work on every part of the codebase, when someone changed teams it felt to engineers that they were expressing a preference for one manager over another, rather than one area of the codebase over another. This issue was compounded by the fact that the teams were named after their managers. Mike described this as feeling like “emotional friction to changing teams.” They really wanted to break out of this pattern as well.

So they decided that they needed some kind of reteaming to solve problems like these. They envisioned a reorg. It happened in the way that many reteamings happen. Someone thinks about it and writes down some ideas. In this case, that is what Andy did. He wrote up a document and proposed what their new structure might look like—centered around customer domains and personas, each team ideally having a dedicated product manager, designer, engineering manager, quality assurance engineer, data scientist, and software engineers. He and Mike discussed, and then they met with their product leadership, who really liked the idea as well. With buy-in from key stakeholders, they went back to their organization with their proposal. Andy told me, “We had one-on-ones with all the members of the teams, started shopping the idea around, and went through all the engineering managers. I went through every single person on the team and just showed them the idea. We tried and encouraged people to move teams. In having these domains now, people could actually start to focus on different areas.”14 In the end they just picked a day—which was the start of 2019—on which they shifted to their new structure.

They have been in their new, customer domain–focused organizational structure for about a year. They’re glad they shifted and have reaped some benefits. A few benefits in particular stood out in our interview.

Now that the engineers have greater levels of code ownership of specific areas, they have noticed that people are starting to see opportunities for how to evolve their architecture. Andy said, “People are actually now saying things like, Okay, could this become a separate service? Maybe it should become a separate library? or a gem?” Evidence of Conway’s law at work.15

In addition to this ownership and a more focused view of the codebase, their new structure has also helped engineering leaders to connect the work of the engineers to the amount of dollars they wanted to invest into each problem area. They felt that this would help them to explain their resource allocation and spending, as we all must do in our organizations at some point. It felt like their new structure had a closer connection to that spend. As Mike put it, “Team organization is our most effective lever in figuring out how to allocate spend efficiently across the group.”

And finally, when people ask to switch teams, they no longer have the stigma of “wanting to leave their manager.” This ability to change teams is what Mike calls a “secret weapon in retention.” He said, “After a few years at any job, people just want something to feel different; they get an itch for change, and this strategy helps to address that need. It’s not that a person considering other opportunities is necessarily unhappy with their job. We all want to just feel movement and growth in our lives.”

After a lot of movement and growth, not only as individuals, but also as companies, things start to feel different. Reteaming after reteaming occurs as we scale, and it can be even more pronounced during hypergrowth phases where hiring is rampant. The culture shifts and evolves, and people start to notice that. It can become uncomfortable. Let’s take a deeper look into this in the next section.

What It Means When You’re Asked, “How Do We Maintain Our Culture?”

Thus far, we’ve explored reteaming patterns related to growth, including the one-by-one pattern and the grow-and-split pattern. After some time has passed and your company has grown in these ways, things start to feel different and the people around you might ask, “How do we maintain our culture?” I feel like it’s almost a trick question when this is asked, because it means that your culture has already shifted into something else.

When I joined one of the startups I was at, I found myself in the position of advising and coaching a handful of engineers who were early employees at the company. There were about eight hundred employees at the time and probably two hundred in engineering. These early hires were concerned that the company was changing—they could see it and feel it with all of the new hires around them. At that time, we were all in one large open office with the capacity to hold around three hundred people. You would walk in our development area and come across so many people you didn’t know. It became hard to remember and match names with faces. It’s like you’re living in an example of Dunbar’s number—where so many new people have been hired to such a degree that you don’t have the ability to have relationships with all of them—there are just so many more people.

This growth continued for years. Some might call it the hypergrowth phase—applying the term that, to my knowledge, originated in a Harvard Business Review article by Alexander V. Izosimov, CEO of the telecommunications company VimpelCom, in which he wrote about the growth of cell phone markets.16 I’m applying it here to label the time at the company when you’re hiring like crazy. You have a mandate to grow. You have all of these open positions. It’s a very distinct time in the growth of a company. There is a lot of reteaming that is happening—mostly the one-by-one pattern and the grow-and-split pattern, in my experience. Splits and reorgs happen at higher levels than the teams as well. All of this going on all around you feels very dynamic and changeable—hence, dynamic reteaming.

Yet while all this is happening some things feel like they are getting slower. Decision making might take longer due to having more people. You feel less nimble than you did during startup days. More process is developed. How you did it before is different now. Maybe there was more freedom and autonomy before, but now it’s changing. You need to use software that you didn’t use before. Things are “rolled out” across the company. There’s a greater need to track employee data since there are so many more employees. I’ve been at three startups that grew, and at all three I was there on the day employee badges were given out with everyone’s name and photo, and they started locking the doors because of security concerns. You just don’t know everyone anymore. It’s a visceral experience. It’s a milestone. It’s another signal that the company has grown.

Furthermore, during this type of culture change, power is shifted around. All three startups I’ve been at were founded by technical people. Engineering always felt like the center or hub of the company. We had the funding, and we seemed to have the power. With time, in my experience, this shifts out, and things are driven by outside forces like finance and HR. When these things happen it feels quite different, again, because it is. We have new rules to follow that are given to us from outside our department. People try to standardize human systems, like performance management practices and career ladders, across all different departments. The freedom to do things as you want in your own department is now part of a wider discussion. Resource allocation is discussed. Work gets capitalized or expensed. You have all-hands talks about the ratio of revenue to expenses. The hiring slows to help you get to a better ratio. Hypergrowth takes a new form—a new stage of being efficient and “doing more with what we have.”

All of this change is not for everyone. When startups grow and shift forward into larger companies, people start leaving. Some of the early employees might feel like the company has changed too much for them, so they need to go find another job or start something themselves. When this happens I think it’s a good sign. People self-select out. If they do not, and they don’t like the buildup of process around them, they might add drag to the system, doing things that are counterproductive to what the company must become. So we send them off in a positive light—we thank them in public for their contribution and wish them well.

In her book, Powerful, Patty McCord, who served as chief talent officer at Netflix, talks about hiring people for the future company you want to have. She says, “Identify the problem you want to solve, the time frame in which you want to solve it, the kinds of people who will be successful at that, and what they need to know how to do, then ask yourself, What do we need to do to be ready and able, and whom do we need to bring in?”17 I think that there’s a lot of truth to this perspective. Your current team might not have the skills, the interest, and the gumption to do the work of the future state of the company. Some of them might, though, and re-roleing into something else still might work. You need to take this human by human to see what they are doing now, what their future goals are, and what they want to grow into. You need to decide whether you want to support them on that journey and provide opportunities or whether someone else might be better suited for that role. You need to look out for the business entity while at the same time considering the humans that are already there. It’s not always easy.

People might experience a false sense of loyalty at companies and feel invincible. Just because you were there at the beginning doesn’t mean you have the skill set to help the company to thrive at scale. This is where tough decisions come in, to do what’s best for the company and where it is growing.

When you’re at a startup and you’re in love with it, it’s hard to see it grow and change. But it’s what it must do if the goal is to develop a large, global company that is out to change the world. You need to hire in people who are along for that ride. Nostalgia for the past startup days is a trap that I’ve fallen into, at least in my second startup. You need people who can propel the thing forward.

So, when people ask, “How do we maintain our culture?” you need to pay attention to them. Meet with them. Listen. Maybe they are ready to move on. Or maybe they are ready for a new role that they see as beneficial to helping the company morph—because it has changed, and it will continue to change. That’s the nature of the beast.

Dynamic reteaming is driven by growth, and it’s also driven by the desire to work on new things, in new teams. In the next chapter, we will take a look at the isolation pattern, which is typically driven by new areas of work.

1 Comron Sattari, in an interview with the author, March 2016.

2 Paige Garnick, in an interview with the author, January 2020.

3 If you need ideas on how to better facilitate decision making, consult the book A Facilitator’s Guide to Participatory Decision-Making by Sam Kaner. In addition, to get better discussions to happen in larger teams, consult The Surprising Power of Liberating Structures by Keith McCandless and Henri Lipmanowicz.

4 Mark Kilby, in an interview with the author, October 2016.

5 Kristian Lindwall, in an interview with the author, September 2016.

6 Kristian Lindwall, in an interview with the author, September 2016.

7 I don’t mean to trivialize LeSS with my application described here because it has a lot more depth. The book Large-Scale Scrum: More with LeSS, by Craig Larman and Bas Vodde, has an interesting strategy for managing multiple teams and the dependencies that are present, and is worth a read. Their workshops are also very inspiring.

8 See McCandless et al., Liberating Structures, and Kaner, Facilitator’s Guide.

9 Paige Garnick, in an interview with the author, January 2020.

10 For background on this concept, see Spotify Engineering Culture videos at its website. It is quite common to tell people not to copy the Spotify model in cut-and-paste style when transforming organizations. We did not cut and paste at AppFolio from an existing structure into that structure, but we grew into it, starting with our first team of 10, after applying what I now call the one-by-one and grow-and-split patterns. That is a key difference, and that resulting tribe and squad structure suited us quite well.

11 Dunbar, “Coevolution of Neocortical Size,” 686.

12 Tuckman, “Developmental Sequence in Small Groups,” 6.

13 Mike Boufford, in an interview with the author, January 2020.

14 Andrew Lister, in an interview with the author, January 2020.

15 Conway’s law states: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

16 Izosimov, “Managing Hypergrowth.”

17 McCord, Powerful, 78.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.190.153.63