How to scale a team according to product growth.

Last time we covered two approaches to team building. Now, let’s go a bit deeper.

Let’s talk about the size of the team. Team size depends on the amount of work that needs to be done, number of the technologies you want to use, when you want to have it ready and a few other, smaller details.

Most business owners focus on time — deadlines, specifically. Of course, the schedule defines when and if the product is going to earn money. However, time is the most difficult to control. It’s rather resultant of other components. If you start thinking that way, you might see things from a different perspective. Let me show how you can tackle time without even thinking about it.

The most underestimated component when it comes to team size is:

Complexity of the Product.

With every new line of code we make, the system not only gets bigger, but also more complex. Jumping into another feature doesn’t mean we won’t deal with what we have already built. It’s just the opposite. Work cannot be done in one part of the system without having to understand the details in other parts. Generally, this is why the delivery slows down with time.

Developers have tools to fight with this issue, but that doesn’t mean it will disappear completely. In order to simplify the system, sometimes we need to go a few steps back and rewrite some parts in order to move faster in the feature. All of that is normal, but it requires a time investment.

With all of that in mind, I can give you some advice on how to use that knowledge in the context of team size:

Watch carefully how your team performs. There are signs that some action is required — here are a few of them.

If your team focuses 100% on new features, that means they don’t have enough time to plan a strategic approach. It’s possible that the team ignores some of issues in order to move faster. That’s fine in the short term, but will hit you hard if you continue to do so for a longer period.

If your team struggles with new features, things are getting slower and slower, and there are many unexpected issues which causes delays. These are often connected with the complexity of the system.

What can you do about it?

Remove some of the parts from the system to make it less complex.

Make the team bigger to be able to take care of maintenance and new features at the same time.

This comes with a cost too. To scale the team up, you have to invest time of the existing team. That means you have to react before it happens, otherwise you might end up with no progress at all or, even worse, you won’t be able to take care of the issues that may occur in the system, which could ruin your business.

You can think about all of this like taking care of a city. A city has limited space. If you want to build a new shopping center downtown, you have to destroy old buildings in order to make space for it. You don’t increase costs, but you have to sacrifice something.

You can also build it outside the city, but this requires providing electricity, water or public transport to that place. This takes time, which is why it’s good to plan ahead. You increase costs, but you also open the door for new opportunities.

A final piece of advice — If you’re dealing with a complex product, you have three options: accept that your team is going to be big, cut down the scope of work hard (preferably both) or don’t waste your time and money.

Originally published at http://explained.software on February 22, 2021.