Pitfalls when you’re hiring your first manager in your startup

In part one of this series on hiring new managers, I covered the key things you need to consider when deciding whether to hire your first manager. In part two, I outline the mistakes which are easy to make in this process (and are usually made with the best of intentions!), but that can have major implications as you scale.

By the end of this article you’ll be able to identify warning signs and know how to avoid the common traps startups often fall into when scaling. Drawing on my experience, here are some of the most common pitfalls I’ve witnessed, and how to avoid them.

Title inflation 

The problem: You can’t give people a lot more money, so you give out big titles instead. You likely won’t have an extensive career framework yet for clearly managing roles and responsibilities at all levels. At the same time, you can’t afford to lose people, so you’re in a weak negotiation position. 

How to avoid: This one is tricky, as titles are one of the few assets in negotiation that you have at this stage. My main recommendation is to set clear expectations as much as you can, and use an existing career framework for reference. This is one that I created for CircleCI, and there are many more out there. 

Forcing your best engineers into people management 

The problem: You have a great engineer and you need a manager, so you ask them to take on the role. Unfortunately, unless they’re actively interested in this work, the worst case is you’ll end up losing a good engineer and gain an ineffective manager, and end up with dissatisfied engineers in the process. 

How to avoid: Only ask people to become people managers who actually want to do this work. If you don’t have anyone internally, hire. 

Underestimating time to hire and time to start

The problem: Time to hire gets longer the higher-level or the more specific the role is. In general, expect 4 weeks for lower-level engineers, 3 months for staff or principal roles, and 6-9 months for executive level (VP, Head of, CTO). In Europe in particular, you may need to add another 3 months until people can actually start due to notice periods. 

How to avoid: Your strategic thinking when it comes to growing your organisation should cover the next 6-9 months. Get started on hiring high-leverage roles a bit sooner than you currently feel you may need them - typically, the process drags on and notice periods add up. 

Underestimating time to onboard 

The problem: Even the best experts in their field won’t be at peak productivity from day one at your company, but many leaders plan as if they are. 

How to avoid: Typically, you should plan that it will take 3 months for anyone in a new role to be effective; for higher-level executive roles, this can be 6 months or longer, depending on the state and needs of the organisation. 

Creating too many management layers too early 

The problem: Some startup founders bring in too many management levels too early. Having a well-functioning hierarchical structure requires strong discipline in communication and coordination. But in earlier-stage teams, those muscles aren’t built yet. As a result, founders often end up micromanaging, therefore defeating the purpose of having managers in the first place.  

How to avoid: Avoid adding too many hierarchical management levels too early. Keep the organisation somewhat flat to give yourself time to elevate your own role too. See the examples in part one of this series for how others have solved this. 

Hiring too late for critical leadership roles 

The problem: Many startup founders and early-stage employees want to stay very closely involved and underestimate how much work comes with supporting an increasingly large workforce, and as a result hire additional leaders too late. 

How to avoid: Don’t delay hiring for critical roles, including leadership. Give away your legos.  

Underestimating the overhead that comes with a growing workforce, and the productivity hits 

The problem: If you move from 10 to 20 engineers, you won’t get twice the amount of work done, and the same is true for any other growth stage. We all know this, but it’s easy to forget, and hard to address. I regularly support teams that wonder: We’ve hired so many engineers, why is our output so low? 

How to avoid: As you grow your workforce and add managers, there are some things you can do to maintain visibility and avoid surprises:

• Increase visibility on delivery progress and impediments. Get your project management system to a place where you can start gathering metrics regularly. This means starting to use a system that will scale onwards with the company. If you think migrating tooling sucks now, think about how bad it will be when your team is twice as big.

• Track delivery metrics:

  • Start measuring flow/investment distribution. This allows you to get a clearer sense of where you’re investing team capacity between features, technical debt, maintenance, and escalations/defects. You can simply use the issue type categorisation in tools like Jira for this, which makes it easy for your teams to include.

  • SPACE or basic agile metrics like cycle time and velocity can also be very useful. 

  • No matter what you choose, I always recommend to just start with 1-2 metrics that you actually use, and build on those over time. 

• Give teams key metrics that they can own and drive. 1-2 metrics are sufficient to start with. 

• Reduce cross-team dependencies, these only get worse with time. 

• Resist the “but our first engineer built our first app in 6 weeks! And now we have 50 engineers that we’re paying $money, what are they even doing!” narrative. Eventually, someone will say it, and it will probably be a high-level executive or founder. This is a really important signal, and I recommend getting curious and really trying to understand where those statements are coming from. Often, they stem from one or several of the following: 

  • Low visibility: People don’t understand what your teams are doing.

  • (Perceived) decrease in throughput.  

  • (Perceived) decrease in feature delivery. 

  • Low understanding of increased complexity: At this point, you’re likely dealing with a legacy system, larger customer base, and maybe preparing for further scale already.  

Scaling is hard, and full of opportunities to make, and learn from, mistakes. If you’re actively looking out for and trying to avoid the pitfalls outlined in this article, you’re already on your way to a smoother onboarding of new managers, regardless of whether these roles are hired or promoted. 

The next and final part in this series will provide you with an in-depth guide to onboarding engineering managers.

Check it out here!