Earlier this week I posted two seemingly opposing views about hiring within a few hours of each other. One said that if you start solo, you should not plan to stay solo forever. The other said most founders hire too soon and pay for it in speed, money, and operational debt. A few people noticed and asked, reasonably, which one I actually believe.
So here is the clarity I owe them. Over the year and a half I spent building Shezaar, I hired nine people and let four of them go.
Why The Advice Fails
The standard advice splits into two camps that both sound right. Hire slow, protect your culture, wait for the right person. Or hire the most talented person you can afford and move fast. Founders pick the camp that matches their current stage and then feel principled about it.
Neither camp tells you what you are actually screening for. When I let someone go at Shezaar, it was almost never because they could not do the job.
My first three hires were a content creator, a full-stack engineer, and an intern to help me run day-to-day operations. That was what I thought I needed help with. All three were capable. I let all three go inside a couple of months, and I lost real time and real money doing it.
The problem was not them. The problem was that I hired for the job I assumed I had instead of the one I actually had.
I needed someone editing my content, not producing more of it. I did not need a full-stack engineer, because I had taught myself to vibe code in a few days and I wanted to focus more on defining the product. And I did not need an operations hire either. I needed to prioritize my goals so that most of the “operational tasks” simply disappeared. I had gone looking for hands before I knew what the work actually was.
Three capable people, gone, because I treated hiring as the answer to a question I had not finished asking.
Gate, Then Dial
The five people I hired after that were the best I have worked with. The first thing I changed was the order of operations.
Before I wrote a single job description the second time, I automated everything that could be automated and systematized everything that could not. I only went looking for a person once I knew exactly which part of the work could not be handed to a tool or a process. And just like that, hiring became the last step instead of the first.
Then I changed what I screened for. I started treating culture as a gate and skill as a dial. A gate is pass or fail. Either someone is honest when something breaks, takes ownership without being asked, and works the way the team actually works, or they do not, and no amount of talent teaches them culture.
A dial is a question of degree. How senior, how fast, and how polished. You only reach for the dial once someone has cleared the gate.
I made the process slower and less flattering to match. Most senior people do not want to work at a two-person startup, and plenty of them cannot, because not everyone can hold that much ambiguity at once. So I screened for it directly. I made the interview longer. I added a video round. I ran at least two conversations, and for the technical roles I had the candidates do a small piece of real work before any offer went out.
Once I built the system first and knew what I did not want, I finally hired the team I should have been looking for all along.
Skill Can Be Taught
The reason gate-then-dial works is asymmetry. Skill is teachable. Culture is not.
You can teach someone your stack, your process, your customer, your way of doing things. People grow into roles all the time, and watching it happen is one of the real joys of building something.
What you cannot do is retrofit values into an adult who does not share them. You cannot coach someone into caring about what you care about, or into treating a fragile early team the way it needs to be treated.
This is why treating Skill and Culture as if they have an equal weight is the most expensive mistake you can make. You meet someone with obvious skill and a couple of quiet warning signs, and you let the skill pull the average up past your bar.
A brilliant hire who corrodes how your team works is not a net positive with an asterisk. They are a cost you pay a premium for.
None of this, though, is what sank my first three hires. Those were not gate failures. They cleared on character. I simply had not built the right things for them to do yet.
The order problem and the gate problem are two different problems, and I managed to make both.
The Rule I Broke
That fourth one that I had to let go is the part I am least proud of. It was a mistake I made knowingly.
Mid way in the lifecycle, the product hit a bottleneck only an ML engineer could clear. I had the occasional help but this time I need someone full-time. I interviewed at least twenty of them and I found one inside my budget, which at our stage was close to a miracle. He was the most skilled person I talked to for that role. He was also, clearly, not a fit for the team, and I knew it in the first interview.
I hired him anyway. The product could not wait, and I told myself the work was worth the risk. I had a whole framework for this exact mistake. I had just screened four people through it. But I was desperate.
Three weeks in, that one hire had nearly single-handedly dismantled the culture of ownership the rest of us had spent months building. Nothing dramatic. Just the steady friction of someone excellent at the job and wrong for the room. That friction was teaching everyone around him to stop caring too.
Knowing the “framework” of gate and dial did not save me.
I broke it the moment someone was skilled enough, on a week scary enough, to make me want to.
Some Rules Are Not Meant To Be Broken
Before you hire anyone, automate the thing that hire is meant to run and systematize everything around it. Hiring is the last step, not the first. When you finally do go looking for a person, you want to be filling a real gap, not buying yourself the feeling of progress.
And the moment you decide to hire, write your gate down before you ever write a job description. Three or four non-negotiables about how a person operates, not what they can do.
For me they were are they honesty when something breaks? Do they have a sense of ownership nobody had to ask for? Can they work with the specific way my team works with each other?
And no matter what, you do not let skill, however dazzling, talk you into ignoring your non-negotiables. Cause believe me, the most talented person you ever interview will be the one who tests this, usually on the week you can least afford to hold down the fort.
Hold it anyway.
It cost me three months and a lot of money to learn this. Hopefully you won’t be needing that.
If you have made a hire you regretted, reply and tell me what you missed.



"Knowing the framework did not save me" is the part that stuck. I run everything as systems precisely because I don't trust myself to hold the line when I'm desperate — good to know even a clear gate doesn't fully protect against that.
I agree with the order here: systemise first, then hire. So many founders hire to escape the chaos instead of mapping it first and then leave the new person to inherit a mess nobody fully understands, hoping that they'll systemise the work for them. Frequently stressful for the person and very wasteful for the founder.