A property company doubles its unit count, and everyone celebrates the unit count. That was never the number that was going to hurt. Go from two owners to two hundred and you do not just have more units, you have more legal entities, more bank accounts, more reporting obligations, more jurisdictions, each with its own rules. Nothing about the buildings changed. The operating model underneath them did, and nobody scheduled a moment to notice.

That is the pattern worth naming. Operating model debt does not arrive as an event. It accumulates the way sediment does, one reasonable decision at a time, until the channel is too shallow for the water it now has to carry.

Why debt is the right word

Every growing company inherits an operating model designed for a smaller, simpler version of itself. Approval chains, reporting cadences, who signs off on what: these were built to solve real problems at the time. They worked. That is exactly why nobody revisits them later. Clayton Christensen made this observation the center of The Innovator's Solution: the processes and values that make an organization successful at one stage of growth become the very things that constrain it at the next. The mechanism is not failure. It is success, aging badly.

Technology debt has a discipline built around it. Engineering teams track it, budget for it, and schedule time to pay it down. Operating model debt rarely gets the same treatment. There is no line item for "the intercompany approval process we built for three entities is now strangling us at thirty." So it compounds quietly: a longer close, a director spending Tuesday mornings reconciling instead of deciding, an escalation path designed for a simpler business now adding friction to routine work. Individually, each of these looks like a staffing problem or a training gap. Collectively, they are the operating model telling you it was sized for an organization that no longer exists.

McKinsey's research puts a number to the general cost of this misalignment: even top-performing companies capture only about 70 percent of their strategy's full potential, with the shortfall tied in no small part to shortcomings in the operating model itself. That gap does not show up on a dashboard. It shows up as a hundred small frictions that everyone has learned to route around.

Why property operations concentrate this faster than most industries

Most businesses scale by adding customers or units of the same basic shape. Property portfolios scale by adding a different kind of complexity with every acquisition: a new legal entity, a new ownership structure, a new jurisdiction's tax and compliance rules, sometimes a new asset class entirely. A logistics company doubling its warehouse count is still managing warehouses. A property operator doubling its unit count is managing a doubling number of ownership relationships, each with its own reporting obligations and often its own bank account.

This is why the strain rarely shows up where you are looking. It does not appear first in leasing or maintenance, the visible parts of the business. It appears in accounting, the part built earliest and touched least often, precisely because it had been working fine for years.

There is a structural reason this keeps happening, one that predates any software conversation. Melvin Conway's 1967 observation, since shortened to Conway's Law, holds that technical systems end up mirroring the organizational structures that build them. Flip that around and it explains the drift just as well: an organizational structure that grew organically will keep leaning on whatever technical structure it started with, long after that structure stopped matching how the business actually operates. The org chart moved. The chart of accounts did not get the memo.

The operational audit: check the seams

Operating model debt leaves footprints. It shows up first at the transition points where data changes hands, well before it reaches the income statement.

The handoff. Where leasing velocity outpaces the accounting team's capacity to set up security deposits and recurring charges.

The onboarding. The number of manual steps, external spreadsheets, and phone calls it takes to integrate a newly acquired entity or ownership group.

The assembly. The literal hours spent extracting, normalizing, and pasting data from multiple systems just to build a single, coherent owner statement.

None of these look urgent in isolation. A COO who checks all three at once usually finds the same root cause behind all of them.

Why the standard fixes make it worse

When the friction becomes undeniable, the instinct is to add something: a new headcount to manage the reconciliation, a point solution to patch the gap, a consultant to redraw the org chart. McKinsey's research on operating model redesigns is blunt about why this does not work: technology change and structural change are interlinked enough that organizations trying to fix one without the other tend to get stuck in a chicken-and-egg problem, waiting years for a legacy project to finish before they touch the structure that depends on it.

Automating a broken process does not fix the process. It just lets the business run the same friction at higher volume. A new approval layer bolted onto an already-strained one adds coordination cost without removing the reason the strain existed. The honest fix is rarely additive. It is the harder work of asking whether a given governance layer, approval chain, or reporting cadence was designed for the business you run today, or the one you ran three growth stages ago.

The decision sequence a COO actually faces

The instinct to wait for a "quieter quarter" to address this is understandable and wrong, because the debt keeps compounding while you wait. The instinct to solve it purely through reorganization, moving boxes and lines on a chart, is also wrong. Documented redesign case studies bear this out: organizations that adjusted reporting structures without first clarifying process ownership and decision rights found it did not fix slow decision-making. The improvement came only after root-cause work on who actually owned each process, with structural change following afterward.

What tends to work is sequencing the diagnosis before the redesign: identify where decision rights and system capability have drifted apart, then decide whether structure or technology needs to move first to close that specific gap, rather than assuming one general fix applies everywhere. This is unglamorous work. It rarely produces a satisfying before-and-after slide. But Gartner's 2026 research on operating models found a sharper version of this same misalignment happening right now at the technology layer: 71 percent of CEOs say their IT operating model is not fit for the age of AI, while only 24 percent of CIOs believe their current model can adapt to changing business needs. That is not a technology adoption problem. It is the same operating model drift, measured from a different seat.

What actually changes when the model catches up

None of this argues for constant reorganization. Christensen's point cuts both ways: a stable operating model is an asset, not a liability, right up until the business it was built for stops existing. The goal is not to redesign the operating model every year. It is to build the habit of checking, on a cadence, whether the model still matches the business, the way a mature organization already checks whether its technical debt still matches its product.

RIOO exists because we kept seeing this exact gap in property operations: an operating model that had grown past what its underlying financial system could see or support in a single, coherent way. That is a narrower claim than "buy new software." It is closer to the argument above: the fix has to address structure and system together, or it just moves the friction somewhere else.

FAQs

Q1. What is operating model debt?
It is the accumulated mismatch between how an organization actually needs to work today and the governance structures, approval chains, and reporting cadences it built for an earlier, simpler version of itself. Like technical debt, it compounds quietly until it forces a rework nobody budgeted for.

Q2. How is this different from just being understaffed?
Understaffing is a symptom people notice quickly and can measure. Operating model debt hides behind it: adding headcount to compensate for a broken process buys time but does not remove the underlying mismatch, so the friction returns at the next growth stage.

Q3. Why does this show up faster in property management than in other industries?
Because portfolio growth in real estate multiplies ownership entities, jurisdictions, and compliance obligations, not just transaction volume. A logistics company scaling up is still managing the same kind of unit. A property operator scaling up is managing a growing number of distinct legal and financial relationships.

Q4. Is this primarily a technology problem or an organizational one?
Both, and separately. Technology and structure are interlinked enough that fixing only one usually leaves organizations stuck waiting on the other. The diagnosis has to look at both before deciding which one moves first.

Q5. What is the first sign a COO should watch for?
Friction at the seams: onboarding a new entity, closing the books across multiple owners, or assembling a single owner statement from more than one system. These seams show strain long before it reaches a P&L line.

Q6. Does reorganizing the team fix this?
Not by itself. Restructuring without first clarifying process ownership and decision rights tends to underperform. Organizations typically see improvement only after fixing root-cause process issues, with structural change following afterward.

Q7. How often should an operating model be reassessed?
There is no universal cadence, but the discipline matters more than the frequency. The point is to build a repeatable habit of checking the model against the current business, rather than only revisiting it when a crisis forces the question.

Q8. Does this apply only to larger portfolios?
No. The pattern starts earlier than most operators expect, often around the first time a portfolio adds multiple ownership entities or crosses into a new jurisdiction, well before headcount or unit count would suggest the business has "grown up."