When Should You Hire? 🤔
How to figure out if your team needs more engineers — or not.
Hey 👋 this is Luca! Welcome to a new 🔒 weekly edition 🔒 of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
Here are the latest articles you may have missed:
To receive all the full articles and support Refactoring, consider subscribing 👇
You can also learn more about the benefits of a paid plan.
As a former founder, I often spend time with other founders to help them with problems I may have gone through already.
One of such problems — and a big one — is hiring.
In particular, many founders struggle at figuring out when it is the right time to hire more engineers.
If you search online (or talk to people), you often find conflicting advice:
⬅️ You should hire early — before problems get too big.
➡️ You should hire late — to avoid premature scaling and burning money.
This dilemma is particularly high-stakes, for two reasons:
💸 Hiring is extremely expensive — both in terms of compensation money, and time your team will spend on the process.
🙅♂️ Reverting is hard — firing sucks for everybody, so you want to optimize for doing that as least as possible.
So, of course, the solution is to hire just at the right time. But how do you decide? What are the signs that you need more people?
In this article I collected the best of my knowledge about this, and that of the best founders and hiring managers I know. We will cover:
⏱️ Timing — hiring takes time, a lot of it.
⚔️ Opportunities vs bottlenecks — a healthy mental model to think about hiring.
🔨 Signs you should hire engineers — clues that you need more coding power.
💼 Signs you should hire managers — for when the bottleneck is on something else.
For each of these items we will also cover anti-signs, that is, when it is best not to hire and how you may act to de-risk your final decision.