What Your First Hires Actually Do

I'm helping a client recruit a COO. Their first senior non-founder hire. We've been at this for a few weeks now. "It's just one person," the CEO said recently. "Can't we move faster?"
I get it. Three weeks feels like forever when you're trying to scale. But this isn't just filling a role. This is the first time someone other than the founders will make major decisions. How the CEO delegates. How leadership works when the founder isn't in the room. This hire starts installing the operating system.
It reminded me of two portfolio companies.
One raised $800K and hired fast. Six months later: wrong people, cash burning on training. Three of six hires already gone.
The other waited too long. Eighteen months in, still doing everything himself. Became the bottleneck.
Both asked me the same question: "When should I have hired?"
I've been thinking about this. Not just with these two founders, but watching dozens of companies make early hiring decisions. Some get it right. Most struggle. And the interesting part? The struggles aren't about finding people. They're about knowing what you're actually trying to accomplish with each hire.
What Early Hires Actually Do
Your first few hires do something you don't always see right away - they install your operating system. How decisions get made. How the team communicates. How people handle disagreements. Whether things move fast or get debated endlessly.
When I worked in large corporations, there were formal systems for everything. As a founder, we had almost nothing - figured it out as we went, hire by hire. Each person shaped how we worked.
I've watched this play out dozens of times. Some founders hire methodically and build teams that work well together. Others hire reactively - filling urgent needs without thinking about fit - and spend the next year dealing with friction.
Which brings me to the pattern that matters most.
Builders vs Operators
Before you write a job description or start looking for people, answer one question: Are you hiring a builder or an operator?
I've watched this play out enough times to see it's the first decision that determines everything else.
Builders figure things out without instructions. They've built things from nothing before. They don't need structure - they create it. Early on, you need people who can operate in chaos and ambiguity.
Operators take what works and scale it. They've managed teams, brought process and systems. They need clarity on what's already working so they can systematize it.
The test: if you're still experimenting with what to build, you need a builder. If you're repeating the same successful process over and over, you need an operator. Most founders are still in builder mode longer than they think.
The mismatch I see most often? Hiring someone great at scaling when you're still figuring out what to build. Or keeping only builders when you need to start systematizing what works.
That COO we're hiring? The founding team are all builders. They need their first operator. But they're struggling to evaluate operators because they think differently. What looks like "too much process" to a builder is "necessary structure" to someone who's scaled before.
We spent an hour mapping what "good" looks like from an operator perspective. Once they could articulate what structure means to someone who's scaled before, evaluating candidates got easier.
The timing question isn't just "when do I hire?" It's "which type of person do I need right now?"
Most founders wait too long to hire. They're worried about cash, or they think they need to figure everything out first. But at some point the founder becomes the constraint - everything waits for their input, decisions pile up, growth slows.
The flip side: hiring too early, before you know what you actually need. That's expensive. Not just in salary, but in time spent managing people who aren't sure what they should be doing.
I've noticed that when founders are about 80% clear on what needs to happen in a role, that's the right time to start looking. Not perfect clarity - you'll never have that. But enough that you can tell whether someone can do what you need.
The Patterns That Keep Showing Up
Some patterns appear in almost every early-stage company I've worked with.
The resume trap. Founder hires someone with an impressive background - worked at Google, or Facebook, or some other big company. Six months later, they're gone. Couldn't handle the chaos, the ambiguity, the need to do everything themselves.
What works better: people who've recently been team leads or directors. Used to responsibility, still close enough to the work for immediate impact.
Hiring too junior. With limited cash, there's temptation to hire junior people - they're cheaper. But if you're still figuring out what you're building, it's hard to train someone when you don't know yourself. You end up spending more time managing and teaching than you get back in work done.
Fit matters more than credentials. Skills you can teach. Work style and values - those either match or they don't. I've seen this in telecom transformations, in mining startups, in pet-tech ventures - technical skills matter less than how someone works with the team they join. I've watched companies where someone is technically good but doesn't fit how the team works. Within months, everything slows down.
The question isn't just "can they do the work?" It's "will they work well with how we operate?"
Not acting fast enough. Here's the hard one - you usually know pretty quickly when a hire isn't working. Sometimes you wait. Give them another chance. Hope they'll adapt. This almost never works.
One of my recurring lessons: "I should have made that decision earlier." This is true for hiring decisions, but also for business pivots, product changes, strategic shifts. We know sooner than we admit.
The companies that scale well make changes fast when something isn't working. The ones that struggle spend months working around the problem.
Finding People
Most founders struggle not with evaluating candidates, but with finding them.
The best hires come through personal networks. Ask people you've worked with: "Who's talented that you worked with?" People who worked well together often share work styles and values.
Look for adjacent experience. You don't need someone who's done your exact job before. You need someone who's solved similar problems in different contexts. When we hired for operations in Chile, we didn't find people with mineral exploration experience. We found people who'd built operations in complex, regulated environments. The skills transferred.
Test for learning ability. At early stage, the role will change. The person who succeeds is the one who learns fast. Ask about past situations, not hypotheticals. Not "How would you handle this?" But "Tell me about a time when you had to figure something out you'd never done before."
If you're in an expensive market, consider talent elsewhere - Eastern Europe for Israel, Latin America for the US. Be thoughtful about time zones and language for real-time work. Professional recruiters make sense for multiple senior hires, but make your first 3-4 hires yourself to learn what good looks like.
But finding the right person only matters if you know what you're actually building.
What This Comes Down To
The founder who hired fast learned to make changes quickly when something wasn't working. Three of six early hires didn't work out. But he got faster at recognizing mismatches and acting on them. Now he's building well.
The founder who waited finally hired his first two people. Immediately felt the pressure lift. Told me he wished he'd done it sooner - but only after he knew what he actually needed them to do.
Both learned the same thing from different directions. The question isn't "when should I hire?" It's "what am I trying to accomplish with this hire?" Not just filling a role. Installing part of your operating system.
That COO search we're running? We're taking the time because this hire doesn't just fill a gap. It teaches the founders how to delegate, how to evaluate senior talent, how to build an executive team. The skills they're learning now matter more than the speed of this one hire.
I've watched this play out enough times to see what works. Early on, you need people who can build without instructions. Later, you need people who can systematize what works. Hire the wrong type for your stage and you create friction. Fit matters more than credentials - technical skills you can teach, work style and values either match or they don't. Your gut about a hire is usually right. When you know it's not working, act fast.
The way your first few people work becomes the way everyone works. The companies that scale well understand this. The ones that struggle are usually still reacting to urgent needs without thinking about what they're building.
That's worth taking time to get right.
I help founders navigate strategy and funding decisions when the path isn't clear. If you're there, let's talk.
If this was useful, I write one of these most weeks.
Subscribe on LinkedIn