4 Errors software startups and scaleups should be aware of

Firstly, let us put the scene for this post.

The scenario: Company A builds a software product. It has attracted funding and now needs to invest the capital in developing the product and growing the engineering team. It is a turbulent phase, and one wants to deliver as much as possible product for the given resources. The resources being capital and time.

In this short post we will list 4 pitfalls software startups and scaleups in such situations should be aware of:

1. Over-staffing – when it comes to software, more people does not mean necessarily, faster speed of delivery. On the contrary, due to communication and administrative overheads adding more people might very well slow down the project – see Brook’s law. If you are late on the schedule, just adding more manpower might not fix the problem and might even reinforce it. It is possible that you need to look for more ingenious solutions (we do offer services in this domain!).
2. Underestimate the time a developer needs to become productive – to become really productive a developer needs to understand the business domain, the code base, the software architecture, to get to know the team, familiarise with the engineering process within the company, configure the development environment. It is a lot. Depending from the specific setting in your company, every step might take a bit longer or shorter amount of time, however you should expect that engineers will face ramp-up time. In my experience 6 months might be a rough guideline (admittedly an oversimplified one).
3. Underestimate the communication overhead within a big engineering team – another pitfall one should be aware of is how the number of communication channels grows within an expanding team. If you have a team of n team members, the number of communication channels is described by the formula n(n-1)/2. The number of communication paths grows quadratically with the number of people on the team. For a team of 3 this means 3 paths of communication. For a team of 8 it means 28 paths!
   Thus while growing your engineering team you could face overhead connected to communication. Further since software is abstract, communication in this domain is specifically difficult. You might very well find yourself in looking for solutions for communication related problems.
4. Underestimate the time needed for a team to jell – in order for a software engineering team to really become productive it needs to jell. What does jell mean? It means that the team members are getting more familiar with each other, some process for working starts to emerge and the team starts working more as a group than as individuals in silos. This is when the magic happens. There is no written rule how long does it take for a team to jell. Some teams might never jell. In my experience if a team is going to jell, it usually does after 6 months of working together.

Do you have questions about this article or just want to discuss the topic? Do not hesitate to contact us at

— — —

We put a lot of effort in the content creation in our blog. Multiple information sources are used, we do our own analysis and always double check what we have written down. However, it is still possible that factual or other mistakes occur. If you choose to use what is written on our blog in your own business or personal activities, you do so at your own risk. Be aware that Perelik Soft Ltd. is not liable for any direct or indirect damages you may suffer regarding the use of the content of our blog.