Don't hire engineers until you have product market fit
The bigger team, the bigger the challenge.
This is kind of a followup to “The cost of saying Yes to feature ideas”. If you like this post, you’ll like that one too.
Recently I have talked to a few companies that are at an extremely exciting stage. The company is just the co-founders, they’ve built a product, and they’re signing on their first customers. And those customers are paying them money!
It’s an exciting time, because the world is their oyster. Even if the the customers aren’t paying them much, they have some validation coming in. They have heaps of product feedback coming in. And they probably are getting heaps of ideas for what to build next. At the same time, they aren’t so far down the track that the product is set in stone. It’s inevitable not every idea will be a great one and it’s not super clear how to prioritise them just yet.
Another thing these co-founders have in common is they all have the same idea that will ruin their momentum: “We want to hire a bunch of engineers so we can move faster!”
This being a bad idea sounds counter-intuitive. Surely hiring more engineers means you’ll get more stuff done?1 Sometimes that is the case, but it’s absolutely not the case before you have product-market fit.2 In fact, in the early days, every extra hire you make will you get you further from success.
The job to be done, is no longer the job being done
What great co-founders don’t often realise is that regardless of what they think they are doing, they are actually in a single minded pursuit of product-market fit. They’ll describe it in all sorts of different ways - trying to find the next customer, building something a customer asked for that sounds sensible, making the next deal easier to implement… it’s all inching towards the smooth simplicity that comes when you find the fit. Because this seems so obvious to the people working on it, it goes unsaid. You just do what needs to be done to win the next customer and make them happy.
If you’ve been working as a core team for a long time, slowly working towards this nirvana, and then you add someone new to the team, you have to hand over a LOT of context for them to start working in the same mould. This never really happens. Instead what tends to happen is you’ll hire a new engineer and then be like “shit, now I have to give them tasks”. They’re new, and you’re too busy to train them, so you give them a task that’s not too hard to work out on their own. Incidentally, this task is in a not-too-critical part of the product, building a not-too-essential feature that just sounds nice.
Repeat this a few times, and you’ve got the co-founders still trying desperately to perfectly solve the core problem customers have, while a bunch of engineers add random nice-to-have features. If you’re lucky (sometimes you will be) some of those random features are big winners, and you’ll feel like a genius. But most of the time you’ll have a feeling in the back of your mind that “we aren’t getting any closer to the target”.
It’s time to scale!
There’s plenty of other challenges that come with growing an engineering team, and a few others that you really don’t want to have to deal with too soon. The most obvious is HR. Even if you work with the most motivated, relaxed, and easy going people ever (and I am pretty sure I do!), HR is still a thing. That means, recruiting, interviewing, negotiating offers, doing catchups, reviewing salaries, giving feedback, getting feedback, and a bunch of other stuff. It’s all super necessary to have a great team. It takes a lot of time, usually from co-founders. And none of it is getting you closer to product-market fit.
It’s all super necessary… And none of it is getting you closer to product-market fit.
When you are in these catchups, something you’ll hear a lot of is about how it’s time to start making the code more scalable. This is just inevitable; the more engineers work on the same codebase, the more they will want to improve internal systems, make code faster, and make architecture more flexible. Engineers are drawn to these challenges like mice to cheese. But it’s very rare that completing them gets you any closer to building something people want.
Good engineering leaders are able to control these impulses and point them toward useful tasks. If you are busy being a co-founder trying to build the right product, you don’t have time to be a good engineering leader too.
This advice can be extrapolated to everything
It’s not just engineers. You should be cautious about hiring anyone until you have product-market fit.
“We should hire someone to help us with marketing.” → If you don’t have P-M fit, they’ll probably be good at producing lots of content, but it won’t say anything that resonates.
“We should hire some sales people.” → The founders should do all the sales until it’s practical to write scripts for it. If you’re saying broadly the same things in all your sales conversations and it’s working, that’s a big positive sign for P-M fit.
“We should hire a product manager to tell us what to build next.” → The founders came up with the idea for the product, and obsessed over customers for years, and became world experts at the problem you are solving. Now you want to give all that away?
“We should hire someone to help with finance.” → Don’t overoptimise your financial acumen until you have people paying you constantly. (That said, discrete tasks like invoicing and bookkeeping are good candidates for outsourcing, if you can do it in a way that actually saves you time.)
“We should hire a designer.” → Actually, having *one* designer who can also code is a pretty good idea from a very early stage. It’s much easier to win new customers if you can quickly mock up what they want, make it look really pretty, and then fast track it being built. Never hire designers who only can (or only want to) draw things in Figma.
We made this mistake when launching Workforce.com in the US. We’d been operating successfully in other countries for years, and we thought that would successfully transfer over, so we aggressively hired a great team. It took a few extra years for the product-market fit to come.
tl;dr
One day I’ll write a post about how you’ll know when you have product-market fit. (Subscribe and you’ll get an email when I do!) But for now, a simple way of thinking about it is that when you have P/M fit, it’s really really obvious what needs to be done next, for basically every role in the company.
Next time you think about making a hire, ask yourself: on day 1, will it be obvious what this person should work on?
There’s evidence this isn’t true, for projects that are already overdue. There’s a book everyone quotes that says so. But that isn’t really what I’m talking about here.
One day I’ll write a post about what this actually means, but for now the Wikipedia article is okay. I think a good rule of thumb is that once you have it, it’s obvious what should be worked on next, for almost every role in the company.
Looking forward to one day
"One day I’ll write a post about how you’ll know when you have product-market fit."