In my experience, organizations rarely fail because people aren't working hard enough. They struggle because the structure they're working inside was never built for where they are now.
Most of the time, the structure wasn't built for growth or scale at all. It was built to solve an immediate need at the time: a workaround, a stopgap, a decision that made complete sense in the moment. Then the company grew around it. The temporary fix quietly became permanent architecture.
That's why so many companies bring in a fractional COO and end up disappointed. Not because the person was wrong, but because there are two very different jobs hiding under the same title.
The operator COO
The operator COO inherits a machine that works and keeps it running. Cadence, KPIs, headcount, vendors, hitting the number. Their job is stability, and stability is a real skill. If your operating model is sound and you simply need discipline and rhythm, this is exactly who you want.
The builder COO
The builder COO is hired when the machine itself is the problem.
The workflows, the handoffs, the decision rights, the way information moves between functions. That's the deliverable. Not managing the structure. Building it. Or rebuilding it, so the issues stop being problems instead of being managed forever.
These are opposite jobs. Operating discipline applied to a broken design produces a very well-run version of the same failure.
A well-run broken system is still a broken system. It just breaks more punctually.
I don't arrive with answers. I arrive with questions.
Before anything gets rebuilt, something has to be understood. Not the org chart. Not the SOPs. The organization that actually exists.
Because those three things are almost never the same. The org chart describes reporting lines. The SOPs describe intentions. The real organization is the one people navigate every day: the informal escalation paths, the person everyone actually asks, the step nobody documents but nothing moves without.
The first question isn't “How do we fix this?” It's “What is actually happening?”
Until that question has been answered, every recommendation is just an educated guess.
So I spend the early work watching how the organization truly functions, tracing workflows and talking to the people doing them, following a piece of work from the moment it enters the business to the moment it leaves. That's where the design shows itself.
How to tell which one you need
A few signals point clearly toward a builder rather than an operator:
The same problem keeps returning in a new costume. You've hired good people into a role and watched them struggle in exactly the same way. Work routinely stalls between departments rather than inside them. Growth made things worse instead of better. And the phrase “we've tried everything” has been said out loud in a leadership meeting.
If those sound familiar, you don't have an execution problem. You have a design problem, and no amount of operating discipline will fix it.
Why this distinction matters
Hiring an operator for a design problem is expensive in a way that's hard to see. The metrics get cleaner. The meetings get tighter. The reporting improves. And eighteen months later, the same fundamental issue resurfaces, because nothing structural ever changed.
Naming what you actually need at the outset is the cheapest decision in the whole process. It usually starts with one honest conversation.
Organizations produce exactly what they're designed to produce.
If the same problem keeps coming back, the design hasn't changed.
If this resonated, I'd love to hear from you.
Most of my work begins with a conversation. If something here mirrors what you're navigating, reach out — no pressure, no pitch.
Start a conversation