When should you bring on the first manager in your startup?

I’ve been working with a lot of early-stage startups lately, supporting CTOs and Heads of Engineering in scaling their organisation from 5-10 engineers to 40-60, and taking their company from 20 people to 100+. 

One of the biggest inflection points leaders face in this time is going from directly running their teams and operations, to a point where, in order to scale, effective systems will need to be put in place. 

In this post, I’ll outline questions and areas for you to think about, covering:

• How to approach putting management structures in place

• When you should introduce management, and what roles are most suitable

• Whether you should hire or promote from within  

This post is also relevant for similar roles, such as new team leads or senior managers, and anyone else who has people management responsibilities as part of their role. I expand on this topic in the second article in this series article, Pitfalls and traps to avoid during this process. 

Setting the scene: your current situation 

• You’re a technical co-founder, CTO, or Head of/VP Engineering in a small startup/company. You’ve been running your 1-2 teams directly so far. 

• You’ve hired more people recently. Currently, you have 10-20 direct reports, and find it hard to adequately manage them all; at the same time, the team is too big to entirely self-organise. You have plans to hire more people, and you know the current setup won’t work anymore. 

• At the same time, there’s a lot of work that you should be doing, that you barely have time for: Corporate strategy, technical and product strategy, roadmap planning, securing new funding or working towards an acquisition, or even continuing to work directly on your product. 

1. When should I put more leaders in place? 

For many engineering leaders, this situation happens at around 10-20 engineers. Some factors for you to consider: 

• Your role: 

  • Time spent: What are you spending your time on, vs. what you should be spending your time on? 

• Team size: 

  • Contexts: What contexts exist in your team(s)? How can those contexts be aligned with your architectural and product needs?

  • Background: At an early stage, up to ~10-15 engineers, many startup teams effectively operate as one engineering team: It keeps communication and coordination overheads low, and in a time where most team members are generalists, it keeps delivery speed high. Typically, I recommend around 6-8 as a healthy team size for later-stage startups; before Series B, team size needs can vary greatly depending on the product. 

2. What kind of leadership roles should I have in my startup?  

My answer to this question is usually: It depends on 1) what the business needs are, and; 2) what contexts you want to manage. 

1) Assessing your business needs

Look at your team: 

• What skills are missing? 

• Think about your business vision and strategy for the next 6-12 months (any skills you need in up to 6 months, you should already be hiring for!). What skills will you need in order to scale? 

2) Contexts 

My recommendation for any team is to limit context as much as possible, vertically and horizontally.

• Vertical context span: Depth of the strategic vs. tactical purview, from high-level corporate vision and strategy, to daily work of the individual engineers. 

• Horizontal context span: Breadth of the product/platform, including the number of services or user experiences, etc. 

Typically, early-stage startup leaders maintain very broad and deep context. Especially the depth, from corporate vision to daily work of each engineer, typically becomes unmanageable first. Review what contexts you can, and want to, manage. 

3) Your own interests 

As an early-stage, high-level member of the team, and/or even a founder, you should also consider your own role: 

• Interests: What do you want to do? 

• Strengths: What are you good at?  

• Hiring people who are smarter than you: Where can you bring in people who are better than you, in order to accelerate? 
  

There are typically two options for evolving your role from here: 

• Technical path. Your work would be focused on strategy, architecture, coding, and growing technical leaders. Your title would typically be CTO or Chief Architect. 

  • In this case, you would most likely bring in a VP/Head of Engineering to run the operations of the engineering organisation and take care of people.

• People & operational path, but at a higher level. Your work would focus on running the day-to-day of the engineering organisation, including areas like setting vision and strategy, running delivery, managing budgets, and developing people. 

  • In this case, you would most likely bring in engineering managers/team leads for your teams, as well as a Chief Architect relatively soon (at around 20- 30 engineers). 

3. Should I promote from within or hire for these leadership roles? 

Based on your answers to the questions above, you should know what new role(s) you need in your team. I give you a breakdown of the advantages and considerations for hiring vs. promoting below. 

My general recommendation is: While it may make sense to promote from within early on, you will eventually need to hire for more expertise; if you decide to promote now, don’t wait too long until you hire. Delays in skill buildout can get very costly, very fast.  

No matter what path you choose, keep in mind: 

• You will likely feel the urge to micromanage. You may wonder: “What’s the status of the ticket I told them to get the team to work on?”, or “Why is X not done yet?”  Use these questions as a signal: Not (necessarily) a signal that your new lead isn’t doing their job, but that the two of you need to work on visibility and communication. 

• Your new lead will need to continue levelling up their skills and role as the company keeps growing, and so will you. 

Hiring 

• Advantages: 

  • If they have some experience already, they’ll be able to hit the ground running fast. This frees you up for other work much faster. 

  • They will likely need much less immediate support and be able to work more independently.  

• Challenges to expect

  • Onboarding / building context will take time. At this stage, for an experienced engineering manager or VP, you should expect around 3+ months for them to be fully operational. 

  • If reporting lines change, a lot of people will start reporting to the new person instead of to you. This can come with feelings of loss, such as loss of impact, loss of visibility and access to higher-level leadership. This is natural and many people experience this as their organisation grows. You can mitigate this by involving the team members in the hiring process and being as transparent as possible with them. 

• If you choose to hire, you should 

  • Hire someone who has the potential and interest to grow with the company. You’re likely not able to offer the best compensation or benefits, but the opportunity to grow fast. Find someone who wants to keep elevating their role as the company grows. 

  • Set clear expectations for them. 

  • Include them in shaping their role. You’re buying their experience, so make the most use of it! 

  • Let them take as much ownership as possible early on. 

  • Make sure you get the visibility that you need in order to know, with confidence, how things are going. 

Promoting from within 

• Advantages: 

  • Knows the company 

  • Has an existing relationship with the team  

  • Simple onboarding

• Challenges to expect: 

  • Your new lead is going to manage former peers. This scenario is challenging in any case, and even more so when someone is new to management.  

  • They’ll need support from you, and you will need to build capacity for this: Either by coaching and mentoring them yourself, or by e.g. providing training, coaching and resources for them. 

  • You will likely need to stay closely involved with their work for a while. Unless they have prior experience or are very talented, expect that it will likely take them 3-6 months until they effectively operate in their new role.  

  • They will transition from being a very good engineer, to being a new manager. This will likely mean a big adjustment for them and for you. 

• If you choose to promote, you should:  

  • Expect that your relationship will change, and they will need to manage you more actively. 

  • Get them support (books, coaching, training, connections with peers, etc.).

4. What do structures for growth typically look like?

In general, and to allow you to scale your organisation quickly while avoiding bottlenecks, you should expect to have in place: 

• At 10-20 employees: Some leadership layers (engineering managers, team leads, and/or VP/Head of Engineering)    

  • At this stage, you will likely have one team with 2-3 swim lanes, or 2-3 teams. Typically, teams at this stage will be slightly bigger (7-9 members).  

• At 20-30+ employees and around 3-5 teams: A Chief Architect or Principal Engineer level role for technical direction and implementation oversight.

• At 50-60+ employees and around 7-9 teams: A second leadership layer (senior managers, directors) with oversight over 3-7 teams each, ideally these teams are organised in domains or have adjacent contexts. This will give you flexibility to continue scaling for quite a while.  

5. How do others solve this problem? 

Here are some examples that I’ve seen: 

• Startup, Series A, 15 engineers, growing. The CTO promotes 2 engineers with strong management interest to engineering manager roles; the role is a 50/50 mix of technical and people leadership. Teams are structured based on user experiences.   

• Startup, Series A, 10 engineers, growing, no CTO. The CEO promotes an engineer with strong management interest to engineering manager; the role is a 50/50 mix of technical and people leadership.   

• Startup, bootstrapped, 18 engineers, growing, no CTO. The Head of Engineering promotes two strong engineers to tech lead roles and remains the people manager. Teams are structured based on user experiences. 

• Startup, Series A, 20 engineers, growing. The CTO hires a VP Engineering and promotes four long-tenured team members to team lead roles. Teams are structured based on functions (frontend, backend, etc.).   

• Startup, Series A, 15  engineers, growing, no CTO. The Head of Engineering hires two experienced engineering managers as full-time team managers who are responsible for delivery of their teams. Teams are structured based on user experiences in the product.   

• Startup Series A, 15 engineers, no current further growth. The CTO and Head of Engineering hire an experienced engineering manager. The team remains one, with several work streams. 

• Startup, Series B, 17 engineers, growing. The CTO hires a VP Engineering who works with teams directly at first, then promotes and hires engineering managers (100% people managers) over time. Teams are structured along architecture lines and services. 

Deciding if and when to hire new managers, what roles are required and how to hire for them is a challenge for almost all tech organisations as they begin to scale. Remember, keep your business goals and contexts in mind and this will help guide your decision.   

I’m available as a sparring partner and coach if you’d like 1:1 support in expanding your team, or if you decide to promote from within and want to give your new manager access to additional coaching, I can help.

Get in touch to organise an introductory call!