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.

Outsourcing Software – the Pros and a few tips on how to find a good partner.

In the last post, I shared my thoughts on building an in-house team. This time, let me discuss an alternative.

If your business isn’t strictly about the software, e.g., you aren’t building a dating or social app, it probably makes sense to outsource the development.

What are the pros of outsourcing?

• You benefit from the knowledge gathered by the agency over the years. They might have solved similar issues before. The team shares the knowledge and experience not only within your project but across the whole company.

• The entry cost might be significantly lower. You don’t deal with the recruitment, hardware, onboarding, etc.

• You are able to scale the team quickly.

• The team is built by professionals. They are able to suggest the team size, competencies and roles according to your needs.

• You are able to focus on the business instead of dealing with the day-to-day problems, like days off, team rotation and so on.

• You don’t struggle with the technical issues so much. In the case of issues, someone from another project might get involved in finding a solution for your team. This is related to the knowledge sharing in the company.

There are plenty of software houses and development agencies out there.

How do you choose the right partner?

A few things to consider:

1. There is something more important than recognizable brands in the portfolio – The success of individual projects.

Ask about success stories, about the user-base and size of the products that they are most proud of. Check how long they’ve been cooperating with the clients.

It’s not the number of completed projects, but their success which makes a software company good. In the end, you also want to succeed, right? Not just build and release the product.

  1. Since the first contact, you’ve received plenty of signals indicating whether the company is right for you.

The sooner you speak to the technical people, the better. The reason for this is that you can evaluate your idea from the technical perspective. You will get feedback about complexity of the project and potential obstacles that can occur. You’ll also be able to evaluate if the team understands your goal and whether the team is eager to build the product that will succeed.

3. Make sure that you will have direct contact with the team.

Not just through the manager. The closer to the team you can be, the better. You are the one that has the most context. The more of that you can provide to the team, the better software they can build. Teams are eager to cooperate with the client. They want to have a positive impact on your products. That’s what drives them!

  1. Every company has its own technology stack that they offer.

Does it fit all the projects? No. Is it offered to every project? Yes.

Does that mean you should choose the technology first and then find a company?

No. Most modern technologies can handle a majority of applications. The reason that a software house offers technology X and not Y is because they have a specialist in this area, which allows them to build products quickly and keep the quality on a certain level.

I would rather rely on the experience of a given company than the technology they offer. Ask the company about the limitations of the technology they use. Experts will be open to speak about it.

  1. People working in software houses deal with multiple products from different industries.

They know how to sustain a good quality team and how to maintain big systems. That is the foundation of good software companies, so double check if that is the case.

In the next post, I will help you understand how you can make sure that cooperation with the selected company goes smoothly.

Is the In-house developer’s team cheaper than outsourcing?

It’s not just a good idea, but great products that make winners.

Basically, there is no great product without a great team.

You might invest your time in building a team, but for sure

there are plenty of things you might invest this time in

to make sure your company succeeds.

You’ve probably already checked the rates of the developers and compared that to the rates of the software houses in your area. Hiring a team looks like a good option for your budget. If you consider the per-hour developer rate, it does seem to be the case. But there’s more to it than that.

Recruitment, laptops, health Insurance, office space, paid leave – these are industry standards that you cannot compete without.

Still with us? We’ve barely touched on the topic.

One of the biggest costs you can pay is time.

Time that you need to invest in building knowledge, best practices, team culture or the processes. Here are the things you should consider before you decide to build a development team:

A developer rate for experienced developers won’t be lower than a software house’s.

Less experienced workers need to gain knowledge first. This means that it’s up to your team to invest time in their growth.

Domain knowledge needs to be acquired by new people joining the team.

A new person needs to learn the way the team develops the product, what servers the team uses, how to deploy a new version and what tools the team uses.

Hopefully, they’ll learn all of that quickly. But, they also might not consider these industry standards or important elements to learn, and they might decide to leave your team in favor of another better paid offer.

It requires a lot of time to make sure that what you have to offer is attractive to potential employees, unless you’re already a well-known brand.

All of that might take so much of your attention that you’ll spend more time focusing on that instead of building the product.

If you still consider this a good idea, I have one piece of advice. Find a leader. Someone who has enough experience and technical knowledge. Someone that you can build the team around. It won’t solve all the issues that I mentioned, but it will minimize the risk of the failure.

What other options do you have? I’ll cover that in the next edition.


Every Startup Owner struggles with the Software Team. Software development is full of disappointments and unpredictable situations.

Missed deadlines, wasted time and money.

Is it because of your team does not have enough competency to build the product? Or it’s your fault because you did something wrong? I can help you understand how Software Team operates. How to communicate with them so you can get better results and have your product running earlier than later.

For the last decade, I was involved in many IT projects. Investigating mistakes and looking for improvements in

Client ↔ Tech-Team relation.

I am more than happy to help you start or improve your existing cooperation in the area of Software Development .

You will get to know how to find the best contractor for the Product you want to build. You will learn how to work with the Team so you can get best results in a short time. Finally I am going to share bad practices so you can discover them and avoid in the future.