Ask a COO what their operation runs on and you will hear about process, systems, standard operating procedures. Ask what actually keeps a bad night from becoming a bad quarter, and the honest answer is usually a name. The regional who knows which of forty buildings has the boiler that trips in the first hard freeze. The maintenance lead who remembers the shutoff behind the unmarked panel in the parking garage. The accountant who knows that one owner wants the variance explained before the report lands, not after.

That knowledge is real. It is valuable. And almost none of it is written down anywhere you could find it under pressure. You do not think of it as a risk. You think of it as depth, as a seasoned bench, as the reason your portfolio runs quieter than the one down the street. That instinct is the mistake, and it is worth being precise about why.

Institutional knowledge is concentration risk wearing a compliment

You already know how to think about a single point of failure. One vendor supplying a critical part. One data center with no failover. One signatory who has to approve every wire. In every one of those cases you would flag the exposure, price it, and build a hedge, because you understand that resilience is not about how well the thing runs on a good day. It is about what happens the day the single point is gone.

Tribal knowledge is exactly that exposure, applied to the most important asset you have, which is knowing how your own operation actually works. The difference is that you have never named it as a risk, so you have never hedged it. The knowledge that runs your buildings sits in a small number of heads, undocumented, uninsured, and free to walk out the door on two weeks' notice or none at all. Calling it experience does not change what it is. It just keeps it off the register.

It stays invisible because it has no cost until the day it does

Most operational risks announce themselves. A late close, a failed inspection, a spike in turnover, all of these show up in a number someone reviews. Knowledge concentration has a strange property: it is completely free right up until the moment it is catastrophic. There is no line item on any report that says "we now depend on one person to reconcile the intercompany entries, and he is sixty-three." The exposure grows silently for years, and the only event that reveals it is the exit itself.

By then you are not managing a risk, you are managing an incident. The replacement cannot be onboarded into the role, because the role was never written down, it was lived. This is where the cost stops being abstract. SHRM puts the cost of replacing an employee at 50 to 200 percent of their annual salary, with the range climbing sharply for senior and specialized roles. Note what that figure is really measuring. The recruiting fee is the small part. The large part is the months where the work is done worse, slower, or not at all, because the knowledge that made it fast left before the documentation that should have replaced it ever existed. Payactiv

Property operations is close to the worst possible place for this to live

Every industry has tribal knowledge. Yours has a specific set of conditions that concentrate it harder than most, and as COO you sit on top of all of them at once.

The knowledge is physical and site-specific. A software company's institutional knowledge is at least born in a system, in tickets and repos and docs. Yours is born standing in a mechanical room. The quirk of a particular chiller, the reason a specific unit floods, the workaround for an elevator controller two versions out of support: none of that is captured anywhere by default, because the work that produces it happens away from any keyboard.

The operation is distributed and relational. Knowledge does not just live in your people, it lives in the relationships they hold. Which subcontractor actually shows up. Which inspector is a stickler about one code section. Which tenant escalates straight to the owner. That is portable in exactly one direction, out, when the person leaves, and it is almost never transferred in.

And the workforce holding it is aging out. This is the part that turns a chronic risk into a timed one. The Pew Research Center, analyzing Bureau of Labor Statistics projections, expects workers 65 and older to grow from 6.6 percent of the labor force in 2022 to 8.6 percent by 2032, and to account for roughly 57 percent of all labor force growth over that decade. The most experienced people in property operations, the ones carrying the most undocumented knowledge, are disproportionately the ones nearing the exit. You are not facing a possibility. You are facing a schedule. U.S. News & World Report

Add the daily tax on top of the exit risk. McKinsey's Global Institute found that the interaction workers who run operations lose close to a full day out of every workweek just looking for internal information or tracking down the colleague who has it. Not a fifth of some abstract total: a whole working day, every week, gone to retrieval. When knowledge lives in people instead of systems, every answer is a meeting, and every answer that only one person can give is a bottleneck you are paying for whether or not that person ever quits. Medium

The honest part: the obvious fix does not work

Here is where most versions of this argument go wrong, so I want to concede it plainly. The instinctive response is "we need to document everything." Stand up a wiki, mandate SOPs, ask everyone to write down what they know. That project fails almost every time, and it fails for reasons worth respecting rather than waving away.

Documentation written as a separate task rots immediately. The property changes, the vendor changes, the workaround changes, and the document does not, because updating it is nobody's actual job. Within a year you have a knowledge base that people have learned not to trust, which is worse than none, because now the tribal knowledge is back in heads and there is a stale system claiming otherwise.

There is also a human reason people resist. Asking an expert to fully document what they know can read as asking them to make themselves replaceable. In an aging, tight labor market, some of your most knowledgeable people quietly understand that being the only one who knows is job security. A documentation mandate fights that incentive head on, and the incentive usually wins.

So the fix is not "write more down." The fix is to change where the knowledge lands by default, so that capturing it is a byproduct of doing the work rather than a second job layered on top. When the maintenance history, the vendor, the unit, the cost, and the resolution are recorded because that is simply how the work order gets closed and paid, the knowledge accumulates in the system whether or not anyone feels like documenting. The person is still expert. But the operation no longer depends on their memory, because the system remembers with them.

This is the real argument for consolidating operations onto the same record that carries the financials, rather than keeping property data in one place and the money in another. When the operational history and the ledger are the same record, the knowledge stops being a personal asset and becomes an institutional one. RIOO is built directly on NetSuite for exactly this reason: the work order, the unit history, the vendor, and the financial entry live in one system, so the record of how the portfolio actually runs is captured as the work happens, not reconstructed after someone leaves.

What this actually asks of you

The move is not a tooling decision first. It is a reclassification. Tribal knowledge belongs on your operational risk register, named, with an owner, alongside the vendor concentrations and the compliance exposures you already track. Once it is a named risk, the rest follows: you can ask where the single points of knowledge are, which roles carry undocumented dependencies, and which of those people are closest to the door. You will not like some of the answers. That is the point. A risk you can see is one you can hedge. The one you keep calling depth is the one that will surprise you.

FAQs

Q1. Isn't tribal knowledge just experience? Why frame something valuable as a liability?
The experience is an asset. The concentration of it in one undocumented place is the liability. Those are separate things. You want the experience and you want it to survive the person who holds it. Naming the risk does not devalue your people, it protects the operation from depending on any single one of them.

Q2. How is this different from a documentation problem?
Documentation is the fix people reach for, and on its own it usually fails. The deeper problem is structural: knowledge is being generated away from any system, so it never lands anywhere durable. Treating it as a documentation project puts the burden on individuals to write things down as extra work. The better framing is to capture knowledge as a byproduct of the work itself.

Q3. We already have SOPs. Doesn't that cover it?
SOPs cover the repeatable, general case. Tribal knowledge is the specific, local, and exceptional: this building, this vendor, this owner's preference, this piece of equipment past its support window. SOPs are necessary and they do not touch the part that actually creates the exposure.

Q4. How do I even find where the concentration is?
Start with a simple question per critical process: if this person were unavailable for a month starting tomorrow, what breaks and who could cover it? Where the honest answer is "no one," you have found a single point of knowledge. Rank those by how close the holder is to leaving, retiring, or being poached.

Q5. Won't asking people to document their knowledge make them feel replaceable?
It can, which is why a documentation mandate often meets quiet resistance. The way around it is to stop asking for documentation as a separate act and instead capture the knowledge through the systems people already use to do and close their work. Recognition helps too: the people who build institutional memory should be valued for it, not quietly retired once the knowledge is extracted.

Q6. Who should own this risk, HR or operations?
Operations. HR owns retention and succession, which are related, but the exposure here is operational continuity, and that sits with the COO. The risk register it belongs on is yours, not HR's.

Q7. Can't AI solve this? Point a model at our data and let it answer questions.
Only to the degree the knowledge is in your systems to begin with. A model cannot retrieve what was never captured, and if your operational history lives in people's heads, an AI has nothing to read. This is why the systems question comes first and the AI question comes second. Get the knowledge into a durable record first. Only then does AI turn your operational history into a working assistant instead of a digital mirror of the same gaps.

Q8. Does higher pay or better retention fix it?
It reduces the frequency of the triggering event, which helps, but it does not remove the exposure. Even loyal, well-paid people retire, get sick, or move on eventually. Retention buys you time. It does not convert a personal asset into an institutional one, and time spent without doing that conversion is time the risk keeps growing.

Q9. What is the single first move if I have limited time and budget?
Put knowledge concentration on your risk register this quarter and assign it an owner. That one act changes it from an invisible dependency into a managed exposure, and it forces the questions above to get asked. Everything else, the systems work included, follows from having named the thing.