Ask ten CEOs what their operating model is and eight of them will pull up an org chart. The other two will show you a process map nobody has opened since the day it was drawn. Neither one is an operating model, and the gap between what they think they have and what they actually have is bigger than most of them realize.
This is not a semantic argument. A company can have a clean org chart, a fully documented set of processes, and still have no functioning operating model at all. We see it constantly. The paperwork exists. The behavior it is supposed to describe does not.
That confusion is not free. Companies buy software, hire consultants, and redraw boxes on a chart to fix a problem that was never a structure problem in the first place.
Strip away the consulting language and an operating model is simple. It is the actual mechanism by which a decision gets made, who is allowed to make it, and how the people who need to know find out. That is the entire definition.
Everything else, the org chart, the process documentation, the software stack, is an artifact that describes or supports that mechanism. None of those artifacts is the mechanism itself. You can change every box on an org chart and leave the way decisions actually get made completely untouched.
This is why reorganizations so often change nothing that matters. The names on the boxes moved. The way a decision actually travels through the company did not.
An org chart answers one question: who is whose boss. It does not answer who can approve a discount, who can greenlight a hire, or who gets consulted before a customer commitment changes.
Those are the questions that actually determine whether a company runs well. A manager can sit three boxes up from the front line on a chart and still have zero real authority, because every meaningful call still routes to the owner's desk before it becomes final.
That is decision concentration, decisions queuing behind one person because they are the only one permitted to make them, not the only one capable of making them. It shows up on no org chart anywhere, because an org chart was never designed to capture it.
A process map is a snapshot of how work is supposed to flow on a good day. It is genuinely useful for training and for spotting obvious bottlenecks. It was never built to answer the harder question underneath it.
Who owns this process. Who can change it when it stops working. What happens when two departments each think they own the same handoff and both are technically right.
A process map without a named owner just becomes a historical document, accurate on the day someone drew it and quietly wrong six months later. Nobody updates it because updating it was never anyone's job. That is process dependency in a different costume, processes that exist in individuals' memory rather than in the system, measured by what breaks if a named person leaves. A document does not fix that. It just moves the same fragility somewhere less visible.
The first is what we call an entrepreneurial operating model, an operating model that runs on proximity. Information moves because everyone can see everything. It is fast, it carries no overhead, and it has a hard ceiling.
Small companies run on this by default, and it works well for exactly as long as one person can hold the whole business in their head. Nobody designed it. It is just what happens naturally when a handful of people sit near each other and talk constantly.
The second is a scalable operating model, an operating model that runs on structure, decisions owned by outcome owners, process that lives in the system rather than in individuals. Nobody drifts into this one by accident. It has to be built on purpose, which is precisely why most companies never get past the first model even after they have badly outgrown it.
Pick five decisions that happened in the company last week. For each one, ask who actually made the call and how the people affected by it found out. Not who was supposed to, according to the chart. Who actually did.
If the honest answer keeps landing on the same one or two names regardless of what the org chart says, you are running an entrepreneurial operating model with a scalable operating model's paperwork sitting on top of it for appearances. That mismatch is more common than either version running cleanly on its own.
Most leadership teams find this exercise more uncomfortable than they expect. The chart says one thing. The actual behavior of the company says another. Only one of those two is true.
The instinct, once a company sees this clearly, is to redraw the org chart or rewrite the process documentation. That treats the artifact as the problem. The artifact was never the problem. It was just the thing that made the real problem visible.
The actual fix is naming, category by category, who owns which decisions, the same discipline behind moving a founder from owner or expert into actually building the thing that decides, and building the reporting and cadence that lets them own it without routing back through the founder for approval. This is most of what an engagement with us actually looks like, and it is also the part almost nobody wants to do first, because a new chart feels like progress and reassigning real authority feels like risk.
Once decision rights exist on paper and in practice, the org chart and the process map become useful again. They describe a mechanism that is actually running the way they say it is, instead of describing an intention nobody enforces.
None of this makes an org chart or a process map worthless. Both are useful artifacts once the actual mechanism underneath them is real.
They just were never going to fix anything on their own, because they were never the thing that was broken.
Isn't an operating model just another word for our processes?
No. Processes describe steps. An operating model describes who decides, who owns the outcome, and how information reaches the people who need it. A company can have excellent process documentation and a completely broken operating model.
How do I know if my operating model is entrepreneurial or scalable?
Trace five real decisions from last week back to the person who actually made the call, not the person the chart says should have. If it keeps landing on you or one other person regardless of the org chart, you are still running an entrepreneurial model.
Do I need to redesign my org chart to fix this?
Usually not first. Redesign decision rights first, then let the chart and the process documentation catch up to reflect what is actually true. A new chart on top of the old decision pattern just relabels the same bottleneck.
Can a small company have a scalable operating model?
Yes, and the ones that build it early scale further before they hit real trouble. Size determines when the entrepreneurial model stops working. It does not determine when you are allowed to start building the one that replaces it.