Ask anyone at your firm why you do something a particular way, how a property gets onboarded, how a lease approval gets routed, how a unit turn gets sequenced, 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 property operation runs. Your operating model feels like a design, a coherent way of running the portfolio 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 a Property Operation's Model Actually Forms

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

The month-end close runs the way it does because of a spreadsheet someone built in the first year to reconcile one portfolio's rent roll that afternoon. The lease-and-spend approval chain is the one designed when you had twenty units and everyone knew each other, and it still routes a two-hundred-dollar repair through the same three people it did then. There's a step in your property-onboarding checklist that exists because of the reporting requirements of an owner you parted ways with three years ago, and nobody ever took it out. You dispatch maintenance a particular way because that's how the first coordinator liked to do it. You structured the chart of accounts to match the first management agreement you ever signed, and every property since has been forced into that shape.

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 operation, because there was no such room. The operating model is the sum of a hundred of these small, reasonable, moment-specific choices, made building by building and owner by owner, 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. As the law-and-economics literature puts it, the lock-in of path dependence is a lock-in to something worse, a lock-out of something better, that persists even when superior alternatives exist and the cost of switching is not high. What you end up running is governed by history, not by what you'd choose if you were deciding fresh today. Your property 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. The onboarding checklist feeds the accounting setup, which feeds the reporting pack; pull one thread and three others move. People have built habits and workarounds around it, the property managers know which fields to ignore, which approvals to route around, which reports to rebuild by hand. Changing any of it means disruption, retraining, and risk across every property at once. 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 on every onboarding, a small delay on every approval, an hour lost on every close, invisible in any single instance. The cost of changing it is concentrated and loud, a project, a budget, a migration, 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 the thin daily tax, multiplied across every property and every month, adds up to far more than the migration ever would.

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 business rather than a decision your firm once made when it was a third of its current size. 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 property management works." 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, at our current size and portfolio, knowing everything we now know, would we do it this way?

Ask it honestly and the answer is often no. Would we really route every minor repair through the same approval chain we designed at twenty units? Would we structure the chart of accounts around a management agreement we no longer hold? Would we keep that onboarding step for an owner who left three years ago? And when the answer is 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 to run the portfolio. 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 the operation. 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, on every property, every month.

Finding Your Unchosen Defaults

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

• 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, an owner you no longer manage for, a property type you exited, a system you replaced. The rule often outlives the reason by years, and it's still shaping how every new property gets set up.

• Steps whose origin nobody can actually explain. If no one on the team knows why an onboarding field or an approval step is there, it's a fossil, not a decision.

• Whatever a newly hired property manager finds strange in their first month. New people can see the accidents everyone else stopped noticing, why does this take four steps, why does that report get rebuilt by hand, 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 constantly reinventing how you run properties 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.

The moment of most leverage is when something forces the question anyway, a system migration, a big new owner, a jump in portfolio size, a restructure. Those are the junctures when switching costs are already being paid, so it costs almost nothing extra to choose the model deliberately instead of carrying the old defaults across into the new setup by reflex. Most operations waste that moment, porting their accidents into the new system unexamined. The firms that use it come out the other side running an operating model they actually chose.

The Takeaway

Nobody designed your operating model. It assembled itself out of a long series of reasonable, moment-specific decisions, made property by property and owner by owner, 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, at your current size.

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, they were just the arrangement that happened to a smaller company years ago, 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 property operation runs 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, an onboarding step here, an approval chain there, a chart of accounts built around an early agreement.

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, designed to stop typewriters jamming and still in use long after the jamming stopped mattering.

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 across the whole portfolio. The cost of keeping a poor default is spread thin and paid quietly on every property and every close, 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 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 owners or property types you've since left behind, and steps whose origin nobody can explain. Also ask newly hired property managers what strikes them as strange in their first month, since they can still see the accumulated accidents that everyone else has stopped noticing. A system migration or a big new owner is the ideal moment to examine them, because the switching cost is already being paid.