Co-Founder at Cora Nexus AI | Startup Ops | Force Multiplier | Project Manager | Strategic Planning | Cross-Functional Systems
· LinkedIn
·
The best co-founders aren't two builders - they're a builder and an execution artist.
I've noticed the teams that struggle early often have the same problem: everyone wants to build. Nobody wants to build the systems around the building.
Which makes sense. Especially in the early stages, momentum feels like everyone sprinting in the same direction. But building the product and building the business are two different jobs.
One person is asking, "What's possible?"
The other is asking, "How do we do this 100 more times without everything catching fire?"
You don't always need another co-founder for that. Sometimes you need someone who can step in, build the operational foundation, and hand owners and founders back the time they're spending putting out fires.
That's my favorite part of the job. Ops isn't known to be glamorous - but dang, it is to me.
P.S. Did I just make up "execution artist"? I'm keeping it. It's either a COO or a Bond villain. Either way, I'm here for it and just wish it looked less sinister on a business card. …more
Founder at Radi8 // Executive Coach // Host of the Inspiring Founders Podcast
· LinkedIn
·
When I built my first startup back in 2007, I had to work in a future that didn't exist yet.
It wasn't a better printing press. We took the old publishing supply chain, broke it into pieces, and rebuilt them digitally — print-on-demand, zero inventory, mass electronic distribution, and integration with the brand-new e-book world. There was no playbook. You can't optimize something that's never been done.
Peter Thiel has a useful name for this. In Zero to One he splits progress into two kinds. Going from 0 to 1 is invention — doing something genuinely new. Going from 1 to n is what he calls globalization: taking something that already works and making more of it, better and faster and cheaper. His point is that a lot of what we call progress is really the second kind, not the first.
Both matter. But they're different jobs, and they reward different people.
I did the 0→1 part. Since then, others made digital publishing better, faster, and cheaper — Amazon's Kindle platform made publishing a book so easy it's almost a crime. The people who built and scaled that are very different from me. And that's exactly how it should be. There's even research behind it: studying 200+ startups, Noam Wasserman found founders often get replaced as their company grows — not for failing, but because succeeding changes the job into a different one. Success exposes the mismatch; it doesn't remove it.
So here's the distinction I'd make after 25 years of this:
A builder makes it exist. An operator makes it bigger. Most good things stall the moment you ask one to be the other.
Two different jobs. Two different kinds of people.
Most stalls I get called into aren't talent problems. They're a mismatch — someone brilliant at one job asked to do the other, or one person trying to do both at once.
So before you hire, or beat yourself up for being stuck: name the job you actually need right now.
Which one is your initiative actually stuck on — building it, or making it bigger? …more
A quick one to close the week.
This week I've been writing about how building something and scaling it are two different jobs — a builder makes it exist, an operator makes it bigger — and how most stalls come from asking one person, or one hire, to do both.
So here's the question I'd actually like you to answer:
The initiative that's stuck right now — is it stuck on building it, or on making it bigger?
Be specific if you can. Is it a 0-to-1 problem, where the thing doesn't fully exist yet and needs someone comfortable inventing in the fog? Or a scaling problem, where it works but won't reliably repeat, and needs someone who builds systems and consistency?
Naming which one it is tends to be half the fix. Drop yours in the comments — I'll read every one and reply.
The initiative that's stuck right now — is it stuck on building it, or on making it bigger?
Building something and scaling it are two different jobs. Naming which one you're missing is usually half the fix.
So which is it?
The biggest mistake I see founders make: assuming every great builder should become an operator.
They're different jobs that reward different instincts.
A builder takes an idea everyone agrees should exist and makes it real. Ambiguity energizes them. A blank page is a playground, not a threat. But ask that same person to run a mature, optimized machine for years and they get restless and bored.
An operator is the opposite. Hand them something that works and they'll make it bigger, tighter, more profitable. They turn a foundation into a franchise. But drop them into a 0→1 mess with no map, and the lack of structure can be paralyzing.
Neither is better. Neither is a flaw. They're built for different phases of the same journey.
The trouble starts when we pretend they're interchangeable — when we promote a brilliant builder into an operating seat and call it growth, or hire a world-class operator to invent something from nothing and wonder why it stalls.
The best ventures I've seen are relay races, not solo runs. A builder gets it standing. An operator makes it soar. The handoff between them is where the real value compounds.
So before you hire — or before you judge yourself for not loving the phase you're in — ask which one you actually are. And then go find the other.
Which one are you?
Founder at Radi8 // Executive Coach // Host of the Inspiring Founders Podcast
· LinkedIn
·
Put a builder in a mature operating role and watch them get restless. Everything already works, so they start breaking things just to have something to invent. Put an operator into a 0-to-1 mess and watch them freeze — there's no system to optimize yet, no data to trust, nothing to make more efficient. Both are talented. Both are miserable. And both look like performance problems when they're really fit problems.
I've watched this play out on team after team. The builder who was electric in the early days becomes the bottleneck once the thing needs to scale. The seasoned operator who took someone else's company from ten million to a hundred can't get a blank page off the ground. Neither failed. They were each asked to do the other one's job.
There's research behind why this is so predictable. Studying 200+ startups, Noam Wasserman found that founders are most likely to be pushed out right after their biggest wins — because success changes the job. What comes next rewards a different set of instincts than what got them there. The person didn't get worse. The job changed under them.
The takeaway isn't "builders are better" or "operators are better." It's that they're different, and the strongest ventures pair them on purpose — an inventor to make it exist, an operator to make it endure. The mistake is expecting one person to be both, or hiring the wrong one for the moment you're actually in.
So before you hire, get honest about which one you are — and which one you're missing.
Are you the builder or the operator on your team? And who's the counterpart you still need? …more
Put a builder in a mature role and they break things just to have something to invent. Put an operator in a 0-to-1 mess and they freeze.
Both are talented. Both look like performance problems. They're fit problems.
Founder at Radi8 // Executive Coach // Host of the Inspiring Founders Podcast
· LinkedIn
·
People ask what I actually "do."
The honest answer: I build something from nothing, get it standing on its own, hand it to someone who can scale it — then go do it again.
That's the whole model. Build, set the foundation, hand off, repeat.
For a long time I didn't have language for it, so I just looked like someone who kept leaving things. Four startups. A university incubator. Products and programs that had been stalled for years. I'd get them working and move on.
It took me a while to see the pattern wasn't restlessness. It was a role.
I'm a 0→1 builder. My job is to take an idea everyone agrees should exist and make it real, durable, and no longer dependent on me. The moment it can run without me is the moment I've done the job — not the moment I've failed at it.
But that model only works because of the other half: an operator who takes the foundation and compounds it. I invent and establish. They scale and optimize. Neither of us does the other's job particularly well — and that's the point.
If you're an operator who loves scaling something someone else started from scratch, that's the other half of this equation. Curious who relates. …more
What I actually do:
Build something from nothing. Get it standing on its own. Hand it to someone who can scale it. Then go do it again.
Build. Set the foundation. Hand off. Repeat.
The handoff isn't me failing. It's the whole point.
I spent years trying to fix what I thought was a flaw in my career.
I'd build something from nothing, get it working, put the right people and processes in place… and eventually someone else would take over.
For a long time, I thought that meant I wasn't a good founder. Now I think it means I was playing a different role.
I don't enjoy running mature organizations. I enjoy creating them.
I love the moment when someone says:
"We've wanted to do this for years, but nobody has been able to make it happen."
That's my favorite sentence in business.
Once it exists — once the systems are in place, once the team knows what they're doing — my instinct is to make sure it no longer depends on me. Ironically, that's often the moment an operator becomes far more valuable than I am.
I've stopped believing every founder should aspire to be a world-class operator. Some of us are wired to invent. Some are wired to scale. Some are wired to optimize. The mistake is thinking those are the same job.
The best thing I've built over the last 25 years isn't a product or a company. It's the ability to turn "someone should build this" into "this now exists."
And the next chapter is always the same: handing it to someone who can make it ten times bigger than I ever could.
Founder at Radi8 // Executive Coach // Host of the Inspiring Founders Podcast
· LinkedIn
·
I do my best work when someone hands me a hard problem and gets out of the way.
For years, I thought that made me hard to manage.
Give me a mature, well-run operation and I get restless. Give me something ambiguous, half-broken, and stuck — with the freedom to figure it out — and I come alive.
I used to treat that as a flaw to fix. Now I understand it's just how builders are wired.
Ambiguity isn't a problem to be managed out of us. It's the exact condition where we're most useful.
The catch is that trust and autonomy aren't perks you hand a builder once they've earned them. They're the preconditions for the work in the first place. Take them away and you don't get a more careful builder — you get a worse one.
So if you've got someone on your team who's restless inside the process but comes alive in front of a blank page: don't tighten the leash. Hand them the hardest, least-defined problem you have, and let them go find the answer.
What conditions actually bring out your best work — and are you giving the builders on your team the same freedom? …more
I do my best work when someone hands me a hard problem and gets out of the way.
For years I thought that made me hard to manage.
Turns out trust and autonomy aren't perks you give a builder once they've earned them.
They're the conditions the work requires.