Ask anyone at your firm why you do something a particular way, how a property gets onboarded, how an approval gets routed, how the month gets closed, and the honest answer is usually some version of "that's just how we've always done it." Which is a polite way of saying nobody remembers choosing it.

That's worth sitting with, because it's true of almost everything in how a company operates. Your operating model feels like a design, a coherent way of running the business that someone worked out. It's mostly not. It's an accumulation: a pile of decisions made at different moments, for reasons that may be long gone, that hardened into "how we do things." Very little of it was ever chosen as a whole. It accreted, one expedient at a time, and then it stuck.

How An Operating Model Actually Forms

Trace a few pieces of yours back to where they came from, and the pattern shows up fast.

The reporting process exists in its current shape because of a spreadsheet someone built in the first year to solve a problem that afternoon. The approval chain is the one designed when you had twenty properties and everyone knew each other. You use a particular tool because a founder had used it at a previous company and brought it along. There's a step in your onboarding that's there because of the requirements of a client you parted ways with three years ago, and nobody ever took it out.

Each of those was a sensible local decision at the time. That's the important part. Nobody made a bad call. But nobody was ever in a room deciding the shape of the whole thing, because there was no such room. The operating model is the sum of a hundred of these small, reasonable, moment-specific choices, and the sum itself was never designed by anyone.

This Has a Name

Economists have a term for how outcomes get shaped by their own history rather than by what's optimal: path dependence. It came from Paul David's 1985 work on, of all things, the keyboard you're probably reading this on.

There's a clear overview of path dependence here.

The QWERTY layout was arranged the way it was to deal with a very specific problem: the mechanical arms on early typewriters jammed if popular letters sat too close together, so the design spread them out. That problem vanished decades ago. Nothing about a modern keyboard jams. And yet we all still type on QWERTY, not because anyone sat down and decided it's the best possible layout, but because by the time the original constraint disappeared, too much had been built on top of it. Everyone had learned it. Every keyboard used it. The cost of switching outran the benefit, so the accident stuck.

David's point generalizes far beyond keyboards. Early choices, sometimes driven by conditions that no longer exist or even by chance, set a path. Then switching costs quietly lock that path in. What you end up running is governed by history, not by what you'd choose if you were deciding fresh today. Your operating model is a textbook case.

Why The Defaults Outlive Their Reasons

Here's the mechanism that keeps you on the old path even after the reasons for it are gone.

Every piece of an accreted operating model gets held in place by switching costs. Other processes now depend on it. People have built habits and workarounds around it. Changing it means disruption, retraining, and risk. So the moment a default is established, inertia starts protecting it, and it protects it regardless of whether the original justification still holds.

There's an asymmetry that makes this almost automatic. The cost of keeping a bad default is spread thin and paid quietly, a little friction here, a small inefficiency there, invisible in any single instance. The cost of changing it is concentrated and loud, a project, a budget, a disruption you can see coming. Faced with a diffuse invisible cost on one side and a sharp visible cost on the other, firms keep choosing the invisible one, over and over, which means they keep choosing the old path by default. Not because it's better. Because leaving it feels expensive and staying feels free, even when it isn't.

The Real Problem Isn't The Defaults, It's That They're Invisible

The danger here isn't that inherited defaults are necessarily bad. Plenty of them are fine, and some are genuinely good. The danger is subtler: they've stopped looking like choices at all.

"How we do things" sounds permanent. It sounds, almost, like a fact about the world rather than a decision your company once made. And that framing is exactly what stops anyone from questioning it. You can interrogate a choice. You can't easily interrogate what feels like a law of nature. So the accreted defaults sit there, unexamined, precisely because they've been reclassified in everyone's mind from "something we decided" to "just how it is." An operating model you can't see as a set of decisions is an operating model you can't deliberately improve.

The Question That Turns a Default Back Into a Choice

There's one question that breaks the spell, and it's simple. For any process, any rule, any tool, ask: if we were building this today, from scratch, knowing everything we now know, would we do it this way?

Ask it honestly and the answer is often no. And when it's no, the follow-up matters even more: then why are we still doing it? Usually the only honest answer is switching cost and habit, not merit. The process isn't there because it's the best way. It's there because it's the way that happened, and nobody has paid the cost to change it.

That question is powerful because it re-frames the default as what it actually is, a decision, one that can be revisited, rather than a fixed feature of reality. It doesn't commit you to changing anything. It just moves the thing from "given" back to "choice," which is the only place improvement can start.

How It Feels Versus What It Is

The left column is how it's experienced by everyone inside it. The right column is what it is when you look at it honestly, and the gap between the two is where a lot of unnecessary friction quietly lives.

Finding Your Unchosen Defaults

You can surface these without a formal audit. A few places they hide:

• Any process whose only defense is "we've always done it this way." That phrase is a flag, not a justification.

• Any rule that references conditions you've since left behind, a client you no longer serve, a market you exited, a tool you replaced. The rule often outlives the reason by years.

• Steps whose origin nobody can actually explain. If no one knows why it's there, it's a fossil, not a decision.

• Whatever a new hire finds strange in their first month. New people can see the accidents everyone else stopped noticing, right up until they get acclimatized and stop noticing too. That window is worth using.

The Way To Think About It

None of this is an argument for tearing everything up. Most of your defaults are probably fine, and constant reinvention is its own kind of dysfunction. The shift being suggested is narrower and more useful: move from inheriting your operating model to choosing it, at least once. Look at the defaults deliberately, keep the ones that still earn their place, and consciously redesign the ones that are only there because of history.

This is related to, but not the same as, the cost of shortcuts piling up over time. That's the subject of the cost of an operating model shows up late, which is about the compounding bill from expedient decisions. This is the layer underneath it: the recognition that the whole model was inherited rather than designed, and that you're allowed to choose it on purpose. What a deliberately chosen operating model actually looks like is covered in how property management becomes an operating system, and a platform like RIOO exists partly to make that deliberate operating model something you can actually run, rather than a set of accidents you maintain.

The Takeaway

Nobody designed your operating model. It assembled itself out of a long series of reasonable, moment-specific decisions, and then hardened into something that feels permanent and unquestionable. That's path dependence at work: what you run today is shaped by its own history and held in place by switching costs, not by what you'd pick if you were starting now.

The most valuable thing you can do about it isn't a transformation program. It's a change in how you see the thing. The moment you recognize that "how we do things" is really "how things ended up," every default becomes a question you're allowed to ask again. Most will survive the asking. The ones that don't were never chosen in the first place, and you can finally choose to leave them behind.

FAQ

1. What does "your operating model is a series of defaults nobody chose" mean?
It means the way your company operates wasn't designed as a whole. It accumulated from many separate decisions made at different times, each sensible in its moment, that hardened into standard practice. No one deliberately chose the overall shape, so what feels like a coherent design is really an accretion of historical defaults.

2. What is path dependence?
Path dependence, a concept from economist Paul David, describes how outcomes are shaped by their own history rather than by what's optimal. Early choices, sometimes driven by conditions that no longer exist, set a path, and switching costs lock it in, so a practice persists because of legacy rather than because anyone re-decided it was best. His famous example is the QWERTY keyboard.

3. Why do outdated processes stick around even when the reason for them is gone?
Because switching costs protect them. Once a process exists, other things depend on it, people build habits around it, and changing it is disruptive. The cost of keeping a poor default is spread thin and paid quietly, while the cost of changing it is concentrated and visible, so firms keep choosing to leave it in place even after its original purpose has disappeared.

4. How is this different from technical or operational debt?
Operational debt is about the compounding cost of expedient shortcuts and the need to eventually refactor. Path dependence is about something prior: the recognition that the operating model was never deliberately chosen at all, but inherited from accumulated history, and that you have the agency to examine and re-choose it. One is about accumulated cost; this is about unexamined inheritance.

5. How do I identify the unchosen defaults in my operation?
Look for processes justified only by "we've always done it this way," rules that reference conditions you've since left behind, and steps whose origin nobody can explain. Also ask new hires what strikes them as strange in their first month, since they can still see the accumulated accidents that everyone else has stopped noticing.