After being around VC backed software startups for quite a while now, I’ve noticed a pattern regarding how technical management and leadership happens as the company grows. The most successful startups manage to understand and adapt quickly to those different phases. Others struggle, waste time and energy to eventually fail after they ran out of money.
In this article, I’ll go through the different steps a decently successful, pretty typical, VC backed startup goes through until its Series A.
I’ll simplify a few things for brevity, but you’ll get the general direction. Note that while I witnessed or lived through some of those situations, this is not the story of a specific startup.
The First Steps
Let’s talk about Startup XYZ that wants to build a B2B SaaS.
The company is made up of 3 co-founders. They all have some professional experience in their field, but it’s their first time building a company. The CTO is a successful software engineer with 5 years experience building products but with no real leadership experience so far.
Building the first MVP
At the beginning, there is nothing except an idea and a team.
The founders are working together, focused on building whatever vision they want to achieve. Everyone is doing a bit of everything and is very hands on. The CTO is coding, setting up servers, drafting designs and doing whatever is needed to get something in front of customers.
There is no real need for management since it’s just the founders. Communication is simple if they get along, and the company will probably fail if they don’t.
Getting the first customers, hiring the first employees
Now that the product is publicly available, the company is getting both money and feedback from customers. This validation helps them get some seed funding.
With this money, they hire a few people. At the very beginning, they don’t have much to sell and a lot to build, so they decide to add a few developers to move faster. Money is tight, so the new hires tend to be quite junior, but they are very motivated by the startup experience and building up their resume.
At that point the CTO is still coding a lot, but they now have a small team to manage. Of course, since the product is far from product market fit and they now have investors waiting on them to deliver, the CTO prioritizes building over everything else. The hierarchy is pretty much flat, and the first engineers don’t even feel like they have a manager, and they often don’t care. It’s even seen as a positive as it gives them a lot of freedom and autonomy.
All is going well and everything is progressing very quickly. The code produced is pretty bad, but no one really cares.
Pre-Series A, the first technical leads
After a few months like this, the founders start seeing the end of the seed funding runway. The next step is therefore to raise more funds to keep going and scale up production.
At that point, the CTO is the most productive and senior engineer in the team, so their presence is very much needed for delivery and guidance. On top of this, the team have grown a bit more in anticipation of the next funding round, adding more responsibility to the CTO in terms of hiring and dealing with people related problems. Overall, there are still around 5 to 10 engineers building software that start to need some guidance and direction.
The problem is that, as a founder, the CTO needs to be involved in fund raising, meaning that they will have less time to work alongside the team.
At that point, the CTO names two “technical leads” to fix this issue. They are both early employees that are a bit more junior than most tech leads are, but they are very invested in the company and know the technical stack very well. Given the organisational gap with the CTO being more busy, they stepped in naturally into a leadership position, so the company recognises it by making it official.
It’s worth noting that those technical leads do not have any previous experience nor training in this role. They were just the best coder at that startup at that time. The CTO is busy building and raising funds, so they won’t have much time to coach them into their new role either.
Still, everything is going smoothly because the team is highly motivated and focused on iterating on the product to find product market fit. They have everything to prove and everyone sees this brand new SaaS as their baby. The fact that the team is still quite small means that alignment is quickly reached and disagreements are clarified quickly over coffee.
Series A, ambitious hiring objectives and change in perception
The company managed to do a successful round of funding! Let’s say something around 7M€. Everyone is happy and energised, the company gets recognition by the startup scene and every LinkedIn post about the funding gets many claps, thumbs up and hearts.
The CTO goes back to building with the team, but they now have even more pressure to go fast. VCs are not bringing millions to the table to have the money sit in a bank account somewhere. It will mean different things for the different departments, but for the engineer team it means hiring a lot more people. The plan is to almost triple the team within a year.
At that point, the CTO wants to hire more senior engineers. The initial hires were juniors due to a lack of money, not a want to build such a team. They were still successful, but the company now feels the pressure to hire people with more credentials and experience.
However, things changed with the Series A and the company is perceived differently. For instance, since the startup now has millions available, the expectations are raised from everyone, including the employees. What was fine for early hires, like very little perks, small offices and so on, becomes a problem for the new people joining the team.
This is a pivotal moment.
The problems start to appear
Here, I’ll describe a scenario I’ve seen happen many time. It’s avoidable, and there are many ways to prevent most of the issues. I’ll assume the company does everything “wrong” regarding leadership to showcase the different possible problems that I’ve seen occur.
The new hires, the first technical leadership issues
The company hires many engineers, often more senior than the ones already in place. They are being told something along the lines of:
“We were scrappy so far, taking a lot of shortcuts with the code. Now that we have funding we want to go fast and improve our ways of working and quality. This is why we are hiring someone like you, with your experience you’ll be able to get us to the next level”
Beyond this, they often don’t get a proper onboarding, because so far the company was so small that people could just figure it out on their own.
The vague mission and the lack of in-depth onboarding creates tensions between first employees and new ones, as it can be perceived that the new hires are here to “fix” the current state. The codebase is seen as legacy and not given the respect it deserves. A lot of debates are starting regarding coding practices, tooling and technologies used. Processes are being added to increase quality, but they also bring in red tape that is very frustrating to a team used to moving really fast.
On top of this, some of the new hires have much higher starting salaries than existing employees. This is a pragmatic solution to find people quickly. The early team members tend to have better stock options, but this is more “theoretical” money. This gap creates additional tension inside the team.
The technical leads are overwhelmed by the amount of things going on at the same time, both on the technical side and the people side. They are more junior than some of the new hires, and struggle to find legitimacy. As none of them have any training or experience in leading teams, some just give up pushing for their technical vision, others are fighting more and more with other employees. This creates tensions inside the technical team.
The CTO is now managing around 20 people directly. They valued autonomy and a flat organisation, but they are now spending all their time in meetings, often coding at night to catch up. Just like the tech leads, they are not trained nor have experience in leading teams, so they are quite inefficient at it. This means they spend a lot of time to handle sometimes simple management tasks, and make management mistakes that are then costly to fix.
At that point the CTO is exhausted, working too much and dealing with negative feedback from everyone. The first employees are complaining about a change of culture, useless processes, low pay and too many meetings. The new employees are frustrated by a lack of clarity, a difficulty to take ownership and the need to refactor everything. The rest of the company is worried about the velocity stagnating despite hiring many more people.
Setting up a management layer
Given the situation, the CTO decides to add managers to help handling the people side of operations. What seems logical at that point is to give management responsibilities to the two tech leads. Developers are split into feature teams. A team is given to each lead, and another team remains reporting to the CTO because it wouldn’t make sense to only have 2 people reporting to him.
At that point the CTO is in a weird spot, in between roles. They are:
- A founder, responsible for driving the company vision, hiring accross the company, talking to investor and much more.
- A line manager, handling a team of engineers building features. This means showing up to standups, refining tickets, reviewing PRs…
- A manager of managers, dealing with two people that very recently jumped into this new role.
- A software engineer, still coding here and there to help out and make things move faster.
All these roles can be conflicting. For instance as a founder seeing parts of the organisation slowing down, they could decide to step in and code instead of the more long term approach of coaching the team.
At the same time, the two tech leads turned managers are struggling. Their role was defined in a rush and they didn’t really know what they were signing up for. The expectations are not clear because they are the first engineering managers of the startup, so they can’t really look at any internal examples or follow any playbook.
There is still a lot to do, as the pressure is on post Series-A. So not only the tech leads need to learn what being a manager means, they are also very much needed in their previous technical role as individual contributors. They are reviewing PRs, defining architecture, coding features, firefighting when there is an outage… and at the same time conducting 1:1s, discovering salary negotiations, screening candidates and more.
They can’t really step back and think about how they want to approach their new role, so they power through. Their old colleagues are understanding and respect everything they brought to the company so far. However, the new hires start to be surprised by their manager who doesn’t really seem to know what they are doing regarding management and are stretched thin. They can appreciate that they are very technical, but they don’t feel as supported as they thought they would be.
Both the CTO and the leads see their workload and stress increase progressively for a few months. They are shifting their focus drastically depending on the latest issue and no one really has the mental space to find a solution. Everyone is noticing how much their role changed and wonder if they enjoy this new situation.
Things are falling apart
Fast forward a year. The tech team kept growing and there are now around 30 engineers. Each tech lead manages 8 people, a new manager has been named internally managing 4. The CTO is managing the rest of the team.
The cost increase is noticed by everyone, but the company is not seeing the return on investment they expected. The delivery seems to be slower compared to when they were only 10 engineers. The developers are talking about technical debt slowing them down, processes that are unclear, progression paths that are inexistent.
On top of this, releasing is getting more complicated. The codebase grew quickly, but the tooling is not quite there yet and no one knows how to prioritise this properly. The testing strategy is also unclear and any new feature pushed to production breaks something. This leads to customers being unhappy and even to some churn explicitly linked to the constant bugs and general slowness of the platform.
Some of the early engineers left recently citing a change in culture. “It became really hard to do anything here”. “We don’t have any time to tackle technical debt”. “We have too many meetings”. “We don’t know everyone in the company anymore”. A couple of new hires left before the end of their first year, saying that it wasn’t how they thought it would be.
Hiring now feels like filling a leaky bucket, so the CTO and tech leads are working a crazy amount of hours to compensate. It seems counter intuitive because at the same time some engineers are complaining about not having enough to do.
Bringing in “adults”
This is clearly not sustainable and everyone agrees. The CTO is told by the board and their co-founders to “bring in adults”, people with “experience in scale ups” to solve this. This seems to make sense, so they start looking for a VP of Engineering.
The search takes a very long time and requires significant energy from many people. While this is happening, the technical team is struggling more and more. They are promised that they are looking for someone that will improve the situation. Finally, after 6 months of search, they find someone that fit their expectation and they join the company as a VP of Engineering.
They are very good at what they do, but they do it quite differently from the existing team. After a period couple of months of observation, they start changing things around. For some it is a relief, for others it’s deep disappointment which leads to a wave of departures.
After all of this
I could keep going, but I’ll stop the story there. Maybe the VP fixes everything. Maybe they don’t stick around. Maybe the company gets acquired. Maybe everything falls apart. There are many different startup stories and many different outcomes, but I hope this story painted a picture of the problem that many will encounter.
Mitigating This Problem
You can still be successful despite those problems
Of course, the startup of this story can be very successful despite all these struggles.
There are many companies starting like this who end with tremendous success. What I wanted to emphasis there was that the company lost an incredible amount of energy and time struggling with their organisation and management structure. This cost them valuable employees, money, opportunities and customers.
While there are no one size fits all solution, there are actions that taken to increase the chances of success… or at least reduce the amount of pain for everyone involved.
A big part of this mess is inevitable. VC backed startups, by design, have to move very fast. It is futile to try to expect perfect order in that context. However, you can acknowledge the situation and make sure everyone is aware of the situation and the consequences. Then you can do some things, even small, to mitigate the problem.
Use what you have
It would be nice to have an internal coaching program already in place, talented senior executives with years of experience ready to help and a lot of time available to train the staff. Reality is that, as everything is moving fast, you need to adjust as you go - often with very limited time and resources.
Just like you don’t reach for a massive distributed architecture to build your very first MVP, you should not setup a complete internal leadership program with a 10k/day external firm the second you encounter any pain.
Instead look internally who has experience and could help. Talk to peers to compare experience. Introduce light processes progressively and see if they are positively impacting the team or not.
If you start early enough, you should be able to very progressively improve and not face a wall down the line.
Some improvement ideas
In this section I’ll share some ideas I’ve seen helping companies facing growth pain. Don’t hesitate to try some, or be inspired by the general direction and define your own small changes.
Accompany moves to management
It’s very valuable to grow leaders inside the company and not only bring external talent. Insiders will have the historical knowledge, expertise and the required relationships to be successful. However, new managers always need some form of coaching to succeed.
For instance, in this story, when the technical leads get their management responsibilities the CTO could have:
- Provided them with some external mentoring/coaching to help them grow in their new role. This will take a bit of time and money, but this will help them be more efficient mid term.
- Anticipated by getting more people filling in the “tech lead” role for some specific part of the product. This way, when they needed to step back to handle people and organisation matters, some engineers could easily fill in the gaps without their involvement.
- Had discussions with the tech leads to see if they even wanted to manage people instead of changing their role. Some people just don’t enjoy management position and will step back into writing code when faced with difficult HR problems. Not everyone needs to become a manager and that’s fine.
- Get some coaching themselves as they will become manager of managers which is quite different from what they were doing before.
Change processes gradually and measure
It’s important to change things progressively and measure as you go. Any significant adjustment should have some form of definition of success and should be rolled back or at least adjusted if it is not met.
For instance in this situation, the CTO named two managers at the same time. It would have been better to name only one, gather feedback from both the team and the new manager and then name the second manager. This process doesn’t need to be very long, a couple of months maybe.
Invest in onboarding early
It’s always very important to have a great onboarding process. You spend a lot of time interviewing candidates, vetting that they can do the job properly. It feels logical to make sure that you help them get up to speed as fast as possible while making them part of the team.
In the early days, it happens naturally. First employees have lunch with the founders who tend to be obsessed with the project and share their vision constantly.
As the company grow, it’s important to keep this culture but recognise that it will not happen organically anymore. Onboarding processes should be reviewed regularly and all new hires should give feedback on their own experience starting at the company.
Bring in managerial experience earlier
I personally disagree with the absolute need to “bring in adults”. However it can be nice to bring in some people with management experience early on. In this story, instead of moving the two tech leads to a management position, the CTO could have only moved one to management and hired an external engineering manager to bring in some managerial expertise.
Focus and choice
There is a point in the story where the CTO was doing everything at the same time. Coding, managing, leading… and it was not sustainable.
Usually CTOs focus on strategy, organisation and more long term thinking. In this story this is at odds with directly managing a team. This means that the CTO should look into delegating this part of their work, maybe only keeping one or two senior engineers reporting directly to them.
It’s worth mentioning that a co-founder is different from “just” a CTO. As an entrepreneur, they might not want to fit in the usual role of a CTO. This is fine, but choices still need to be made and shared explicitely so that everyone can figure out their place in the organisation.
Sustainable team growth
Post funding, the company will get a lot of pressure for growing fast and for engineering teams that means hiring many people. However it will not always be the most efficient approach.
Here are some ideas:
- Instead of tripling the team in one year, just double it but make sure everyone is perfectly onboarded.
- Instead of only hiring engineers to build features, add a couple of people building tools and improving the developer experience.
- Instead of big and expensive team building events, invest in smaller scale but more regular things to build cohesion.
There’s more
Of course there is much more you can do: being more available as a leader, building small systems for more effective communication, understanding the concept of force multipliers … it’s an endless list of ideas you can try.
If you are around your Series A, I hope this helps you and you’ll pay attention to your leadership group!
Since you scrolled this far, you might be interested in some other things I wrote: