The Ontology of a Business

On what your company actually is, underneath what you have been telling yourself it is.

Every business runs on an answer to a question almost nobody asks: what is this company, structurally, underneath the way I describe it?

The founder usually doesn't ask this because they think the question is settled. They wrote the pitch deck. They have a tagline. They know what they sell. The question feels rhetorical. This is a software company. This is a fleet operator. This is an agency. The category seems obvious, and the obviousness of the category is exactly why the question stops getting asked.

But the category is not the ontology. The category is the label. The ontology is the actual structural reality of what the business is — what exists inside it, what relates to what, what it is primarily doing when you watch it move, and what it is secondarily doing as a side effect. The label and the ontology are usually different. The gap between them is where most business friction lives.

This essay is about how to read that gap. What an ontology actually is, why it drifts, how to surface the version your company is actually running from, and what changes when you do.

What ontology means when applied to a business

Ontology, in philosophy, is the study of what exists. Not what we think exists, not what we say exists — what is actually there. When applied to a business, ontology asks: when you point at this company, what category of thing are you pointing at? Not what does it call itself. Not what does it sell. What is it, structurally, as an operating entity in the world.

This sounds abstract. It is not. Here is how it shows up in practice.

A software company sells software. That is the label. But when you look at what the company actually does day to day — what its operators spend their time on, what its customers reach out about, what determines whether a deal closes or doesn't — the picture often shifts. The software is delivered, yes. But what the customer is actually buying is a relationship with a team that knows their industry and translates that knowledge through a product. The software is the medium. The relationship is the substance. If you took the same software and shipped it without the relationship, the customers would not pay for it. If you took the same relationship and delivered it through a different medium, they would still pay.

The label is "software company." The ontology is "knowledge-transfer service that uses software as the delivery layer." Those are not the same thing. And the difference matters, because every operational decision the company makes will be calibrated to one or the other. If the company believes it is a software company, it will hire engineers, invest in product features, and treat customer success as a cost center. If the company knows it is a knowledge-transfer service, it will hire industry experts, invest in customer onboarding, and treat the software roadmap as in service to the relationship.

These are different companies, even though they have the same product and the same revenue. The label says one thing. The ontology says another. The team operates from whichever one is implicitly believed, regardless of what the website says.

How ontologies drift

Companies do not start with the wrong ontology on purpose. They start with the ontology that was true at founding. The founder has a clear picture of what they are building, and for the first stretch of the company's life, the picture matches the reality. They wrote the deck about what the company is. The team executes against the deck. The customer experiences what the deck promised.

Then the company changes. It always does. Three things drift the ontology:

The customer teaches you what you actually sell. Founders pitch what they think they sell. Customers buy what they actually want. The gap between those two is where the company learns. Over time, the company's revenue is increasingly weighted toward whatever the customer values, not whatever the founder originally pitched. By the time the company has real revenue, the customer has quietly revised the ontology — often without the founder noticing.

The team teaches you what you actually do. The founder's original vision is the company's first ontology. As the team grows, each new operator inherits a slightly different picture of what the company is, because they joined at a different time, took on a different scope, and had to build their own mental model to function. By the time the company has thirty people, there are thirty partially-overlapping pictures of what the company is, and the official picture (the founder's deck) is just one of them.

The market teaches you where you actually fit. The competitive landscape, the regulatory environment, the macro conditions — all of these put pressure on the company to occupy a specific position. The position the company is forced into is often different from the position it was designed for. Over time, the company shapes itself to survive in the market it actually operates in, not the market the founder originally imagined.

These drifts are not failures. They are normal, healthy, even necessary. A company that does not let its ontology evolve is a company that refuses to learn. The problem is not that ontologies drift. The problem is that the official ontology — the one the founder describes, the one the marketing speaks to, the one the org chart implies — usually does not drift with them. The actual ontology moves. The stated ontology stays. The gap between them widens.

What the gap costs

Most businesses I read are operating with a substantial gap between stated and actual ontology. The cost of the gap shows up in specific places.

Hiring decisions. A company that hires for the stated ontology hires the wrong people. Job descriptions are written against the label, not the substance. The candidate gets hired for one set of skills, then walks into a daily reality that requires a different set. They struggle, the team struggles, and nobody can articulate why because nobody has named the gap.

Strategic decisions. Strategy is downstream of ontology — it assumes the question of what we are is settled. If the strategy is built on the stated ontology but the company is operating from the actual one, the strategy will systematically point the company in the wrong direction. Initiatives launch with great clarity and then never quite produce the expected results. Nobody can find the bug, because the bug is at a layer below where the strategy is being executed.

Marketing copy. Marketing speaks the stated ontology because that is what the founder approved. The customer responds to the actual one. The disconnect produces conversion problems, brand confusion, and an inability to articulate why some leads convert and others don't. The good copywriters intuit the actual ontology and write to it. The mediocre ones speak the stated one fluently.

Founder experience. This is the most expensive cost of all. A founder operating with a wide gap between stated and actual ontology feels constantly off. Decisions feel harder than they should. Meetings drift. The work that should be exciting feels heavy. The founder cannot name what is wrong because, from the inside, the company looks like the deck. The deck is correct, on paper. The work is correct, on paper. But the felt experience is wrong, because the founder is daily operating from one picture while running a company that is structurally a different picture.

When the gap is closed — when the actual ontology is named clearly and the company aligns to it — most of these costs disappear. Not because the company changed. Because the company stopped fighting itself. The strategy now matches what the team is actually doing. The hiring now matches what the work actually requires. The marketing now matches what the customer actually buys. The founder now experiences the company they are actually running, instead of the company they think they are supposed to be running.

How to read the actual ontology

The actual ontology is not hidden. It is surfaceable in conversation, if you know what to listen for. Four signals matter most.

What the founder says when nobody is judging. When you ask a founder to describe their company at a board meeting, you get the stated ontology. When you ask the same founder to describe their company over a long dinner, with no agenda, you usually get something different. The version that comes out in private is closer to the actual ontology. The disagreement between public and private descriptions is itself data.

What the operators say when you ask them separately. If three senior operators on the team describe the company to you in three private conversations, and the descriptions diverge, the divergence is information. The actual ontology is somewhere in the overlap of what they all say, plus the things they all mention that the founder didn't.

What the customer says they bought. Not what the customer said when they signed the contract. What they say six months later, when they describe to a friend why they keep paying. The friend version is the actual ontology, expressed from the buyer's side.

What the company does when it is under pressure. When a deal is at risk, when a customer threatens to leave, when an emergency comes up — what does the company actually mobilize? The thing the company mobilizes for is the thing the company actually values. The thing the company lets slide is the thing the company doesn't actually run on, regardless of what the deck says. Behavior under pressure reveals ontology faster than any other diagnostic.

When you triangulate across these four signals, the actual ontology surfaces. Not as a single sentence, but as a shape. A pattern. The thing the company keeps trying to become every time it makes a decision, even when nobody has named it yet.

What changes when the ontology is named

A founder who reads a clear, accurate articulation of their company's actual ontology — for the first time, in writing, by someone outside the company who has no reason to flatter them — typically responds the same way. There is a long pause. Then a quiet sentence that means some version of "yes." Sometimes more specifically: "I have known this for a year and could not say it." Sometimes: "I have been making this decision and avoiding that decision for reasons I could not explain, and now I can explain them."

This is not magic. It is not transformation. It is the structural relief of finally having language for something that was already there. The company was already this. The founder was already operating from this. The only thing that changed is that now it is named, and a named thing can be acted on. An unnamed thing can only be felt.

After the naming, the work becomes obvious. The hiring decisions snap into focus. The strategic priorities reorder themselves. The marketing copy starts to write itself, because there is now a clear thing to write about. The founder begins to experience their own company as the thing it actually is, rather than the thing the deck says it should be.

This is what an ontological audit produces. Not advice. Not strategy. Not a list of recommendations. A written articulation of what the company actually is, delivered to the founder in a form they can read, sit with, and act on. The audit does not change the company. It makes the company visible to the people running it.

The deeper claim

What I want to leave you with is this: most of the problems founders bring to advisors are not strategy problems, hiring problems, or operational problems. They are ontology problems wearing the costume of strategy, hiring, or operational problems.

A founder who cannot decide between two strategic options is often facing a hidden ontological choice — which version of the company do they actually want to be running? A founder who cannot find the right hire is often facing a hidden ontological gap — they are hiring for the stated ontology but need someone who fits the actual one. A founder who is exhausted by operational complexity is often running a company whose stated structure does not match its actual structure, and the friction is the price of operating from two pictures at once.

When you work the ontology layer first, most of the downstream problems either solve themselves or become much easier to solve. Strategy becomes simpler when you know what company you are running strategy for. Hiring becomes clearer when you know what role actually needs to be filled. Operations become smoother when the structure matches the work.

This is the layer the practice works first. Everything else is downstream.