Best practices for transitioning from a single development team to multiple development teams
As your organization grows and you hire more developers, you’ll reach a point where you simply have too many developers for a single team. When exactly you reach this point will depend on the nature of your team and your business, but it will happen at some point – it’s simply a fact of life for fast-growing organizations.
And when you do hit this milestone, it’s important to react accordingly by transitioning from a single development team to multiple ones. Making this transition can be intimidating at first, but it’s an important step for continuing to grow your business.
Let’s take a look at exactly why this transition is so important, how to identify when it’s time to make the transition and how to implement the change effectively.
Why it’s important to transition into multiple development teams
The sheer size of your team might necessitate splitting into multiple development teams, but this isn’t something you should do just because you have to. In fact, there are numerous benefits that come with making this transition.
First, introducing multiple teams can help parallelize your development operations so that you can focus on more than one thing at once. Normally, development teams work together around a single task, so having multiple development teams means that you can work on multiple tasks simultaneously.
Second, this type of split allows you to nurture specialities within each team. For instance, one team might have people with a particular skill set that they can continue to hone when working with a highly complex area of the product. This focus allows them to develop a deep knowledge around this area that they can use to work more efficiently and build a smarter end product.
Along the way, you might even consider taking this approach with all of the operations that surround development. One potential configuration is to assign a product manager, designer, QA analyst and even any relevant front end team members to work with a specific development team. Having these roles working with a particular group allows for extremely focused operations so that people in all roles can develop specialities. It also means that these groups work together consistently, which can help increase efficiency and better forecast workload, since any requests will come from a predetermined group (vs. from anyone across the organization).
Finally, it can even help strengthen the dynamics of interpersonal relationships since the same smaller teams will work so closely together day in and day out. The one drawback of this approach is that it becomes harder to get to know people on other teams, but a strong corporate culture can help remedy that.
When to make the transition to multiple development teams
While the benefits of splitting into multiple development teams might be obvious, what’s far less obvious is when to break into separate teams. And the timing of this separation does matter.
Consider Conway’s law, which says that the design of a product or system will reflect the structure of the people that built it. In other words, if you have one homogenous development team, you will likely have a homogenous product. But if you start splitting into varied development teams, you might end up with a system that reflects these divisions.
So when should you separate into multiple development teams? To start, there’s always the ”pizza rule” Jeff Bezos instituted in the early days of Amazon: Every team should be small enough that it can be fed with two pizzas. Typically, this will top out around 10-12 people, but the truth is there’s no magic number.
When you need to break into separate teams depends a lot on the dynamics of the team and the product itself. For example, you might find that you need to make the split earlier if you have a product that has two distinct areas and requires two separate specializations as a result.
But even in the absence of this type of requirement, other clear signs exist that it’s time to break into multiple teams. The biggest one is typically when regular team meetings become difficult to manage, whether that’s because people stop paying as close attention, not as much gets done in the same time or they begin to take longer. Ultimately, you’ll end up with giant meetings that aren’t an efficient use of everyone’s time, and that’s a clear sign that it’s time to break into smaller working groups.
How to make the transition to multiple development teams
Once you identify the need to transition to multiple development teams, how do you actually make it happen?
There are numerous ways to break into different teams. Three of the most common ways include:
- Breaking down based on specialties, which can help strengthen skill sets and allow developers to go deep in more complex areas.
- Introducing teams with a uniform shape, which creates a parallel structure to develop multiple focus areas simultaneously. This may or may not include extending the parallel breakdown to product managers, designers and QA analysts, as this will depend on the size of those teams and the ability to share resources.
- Informally breaking larger team meetings into smaller working groups, which is the simplest place to start since large team meetings are often the first pain point.
Regardless of how exactly you differentiate between the teams, it’s important to remember that everyone is still ultimately on the same team. As a result, you should not establish hardline barriers between the two groups. Instead, it’s important to encourage cross-pollination of ideas and work so that members of different development teams feel comfortable reviewing each other’s work and asking each other questions. Maintaining this type of open communication gives back some of the advantages of working on a single team.
Additionally, while engineering leadership should treat each team the same and encourage direct communication across teams, it’s still important to provide specialized resources as needed. This includes introducing ways to easily identify teams and route assignments accordingly within planning tools. It also involves setting up a separate staging environment for each development team.
Lastly, as each team grows, you’ll need to think through scaling engineering management accordingly. In the long run, having a manager (or lead point of contact) per team will be important, but this doesn’t need to happen immediately after the transition. Immediately hiring a new manager just because you formed a new team can be something of a trap. Instead, the best way to grow the engineering management team is to do so organically and let the managers define their own terms (rather than the team structures dictating this) so that managers can develop natural, high quality relationships with their teams.
Need help scaling your development team?
If your organization is scaling and you need help with the development challenges of a multi-team organization, that’s exactly why we built Spaceship. We built it for large teams that need help scaling their operations and we’re the perfect tool for continuing to grow as your business matures. Contact us today to learn more and get started.