How to grow a team effectively

If five people build a product in four days, how many days would ten people need to build the same product? Apply simple math and you get two days. Unfortunately, this formula is far too simple to capture the complex reality. For one, it underestimates the complexity inherent to team size. Yet, we often rely on this logic to make important decisions in life.

In software product development, team size has a serious impact on productivity. When a small team starts building a new product, their productivity is remarkably high. But as both the team and the software product grow in size, a steep decline in productivity is often observed. Splitting the team up into smaller teams is always a good practice, but this doesn’t immediately solve the productivity challenge.

This shouldn’t come as a surprise. Any team, department or organization can be viewed as a complex dynamic system, with many interactions between its components. In a software product organization, think of these components as people, software components, data entities, etc. Add one person to a group of ten people, and you essentially introduce ten new channels of interaction between them. Additionally, every new software component in the system or every new data entity will contribute to this increased complexity, lower predictability of the system behavior and decreased productivity.

While we can’t avoid this natural pattern, there are some things we can do to tame this systemic complexity and flatten the curve of declining productivity. Here are some key insights I’ve seen work in practice:

1. Recognize when not to grow. The first piece of advice for effective team growth is to recognize when growth isn’t a wise decision. When problems arise, we tend to blame it on not having enough people on board. But think about this, would more people solve the problem? Or should you reorganize your people and processes more effectively? When a project is already behind schedule, adding more people won’t help much. This is nicely captured by Fred Brooks’ observation, “Adding [people] to a late software project makes it later.”

2. Prepare for growth before you grow. Bringing more people on board will inevitably increase the system complexity. So before making it more complex, make sure the processes running in your system are already as efficient and as simplified as possible. Are clear processes defined, is there a structure in place, can certain processes be automated? In software product development, there are many ways to achieve this: automating the test processes, automating building and deployment, standardizing the process of effort estimation or issues prioritization, documenting the essential design decisions, etc. The more mature your development processes are, the more you can benefit from the growth.

3. Minimize dependencies between teams. The growth success highly depends on the quality of your organizational architecture. If you set no rules for how components in your system can interact, chaos will be inevitable. The key to high productivity is to design the system in such a way that a high level of autonomy is achieved. In software product development, the interaction between software teams is largely driven by the software architecture. Any dependency between two software components will likely lead to a communication dependency between the teams maintaining these components. As captured by Conway’s law, the software architecture will often be in line with the team structure. A clean software architecture is therefore the basis to enable growth.

4. Maximize the total value. Having independent teams isn’t sufficient. We often see examples where high team autonomy is achieved, but there’s a lack of clear vision and misalignment between teams. While all teams would then move efficiently to reach their individual goal, they don’t move the whole system forward efficiently since their goals are not aligned. This might look obvious, but it often goes wrong in practice. When building a software product, there are three essential factors to maximize the total value of the product: designate a single person to own the vision of the product, set clear responsibilities among teams, and lay out a clear process that keeps all teams aligned.

Applying these rules in practice is anything but easy. Yet, it’s important to keep these principles in mind when planning to grow. Perhaps, a mindset shift is also necessary: think about how to optimize the productivity of your team or organization and build your system as simply and elegantly as it can be. The growth then naturally follows.