Why your best operations person is your biggest risk

Your best operations person gives two weeks notice. You thank them, wish them well, and then spend the next 48 hours quietly panicking.

Not because they are hard to replace on paper. You can post the job, find someone with the right credentials, and get them seated within a month. The panic is about everything that is not on their resume and not in any manual. Which carrier submissions they handle differently because of an undocumented formatting quirk. What they do when the custodian portal throws a session timeout mid-transaction. The three-step workaround they invented six months ago when a trade break did not match any documented procedure, and that they have been running silently ever since.

That knowledge does not transfer in two weeks. Most of it does not transfer at all.

The numbers behind the problem

Operations and support roles in financial services turn over at roughly 40% per year, according to HDI research. That is not a rounding error. That is nearly half your team cycling out every twelve months.

IDC estimates that Fortune 500 companies lose $31.5 billion annually to knowledge sharing failures. Forty-two percent of institutional knowledge lives with a single person. And new hires in operations roles take, on average, nine months to reach full productivity.

Put those numbers together and you get a picture of an industry that is constantly rebuilding itself from scratch. Every departure takes institutional knowledge out the door. Every hire starts the clock over. The firm that ran smoothly in January is a different organism by December.

Why documentation does not fix this

The standard response is to document everything. Build SOPs. Create training manuals. Make the knowledge explicit so it survives turnover.

The problem is that the people who should be writing documentation are the same people drowning in daily work. A reconciliation analyst who starts her day with 40 exceptions to clear is not writing SOPs at 4pm. The knowledge stays in her head because that is the only place it has ever had room to live.

Even when documentation gets written, it goes stale fast. A carrier changes their portal interface. A custodian updates their file format. The SOP that was accurate in March is quietly wrong by June, and nobody has time to update it. New hires follow the outdated instructions, make mistakes, and either figure it out or ask the person next to them, who learned from someone who also learned informally.

The deeper issue is that procedural documentation captures the wrong kind of knowledge. SOPs tell you the steps. They do not tell you the judgment.

What operational knowledge actually looks like

The knowledge that matters most in operations is not procedural. It is contextual. Situational. Built from hundreds of small corrections and adaptations that never made it into any formal record.

It is not "how to use Redtail." Every new hire can figure out Redtail. It is "when Allianz rejects a beneficiary name, you need to format it as 'Trust, c/o Trustee' not just 'Trustee,' and if you call their ops line before 10am they will push it through same day."

It is not "how to reconcile positions." It is "when Schwab shows a one-day lag on after- hours transfers, we do not flag it as a break. We mark it pending and check again the next morning."

It is the exceptions. The workarounds. The judgment calls that were made once, worked, and then became invisible policy that nobody wrote down. This is the knowledge that walks out the door every time someone leaves. And it is exactly the knowledge that a nine-month ramp-up is trying to reconstruct from scratch.

Capturing knowledge from real work

The firms that solve this problem do not solve it by asking people to document more. They solve it by making documentation a byproduct of doing the work, not a separate project on top of it.

Every time an ops person handles an exception, makes a correction, or applies a workaround, that action contains information. The specific error that triggered it. The steps taken to resolve it. The outcome. If that information is captured as structured data in the moment, it builds a record that did not exist before.

Over time, that record becomes something real. The next person who encounters an Allianz beneficiary rejection can look up what worked last time. The analyst who is new to custodian reconciliation can see the pattern of pending-transfer flags that her predecessor handled. The knowledge that used to live in one person's head now lives somewhere searchable, transferable, and durable.

This is also what makes AI agents useful in operations, not just as automation tools but as knowledge infrastructure. An agent that resolves a support issue does not just resolve it. It records what happened, what it did, and what worked. That resolution becomes a data point. The tenth time the same issue type appears, the agent handles it faster and more accurately because it has seen the pattern. The institutional knowledge compounds instead of resetting.

The compounding advantage

Most firms think about operations headcount as a cost to manage. The firms that will have an advantage in five years are thinking about it differently. They are asking which of our operational knowledge is being captured and which is being lost.

A firm that captures knowledge from every resolution, every correction, every exception handled, ends up with an asset that grows over time. A new hire joins and has access to two years of resolved edge cases. An AI agent handles tier-one issues because the patterns are already documented. The team that used to spend 70% of their time on repetitive resolution work now spends it on the cases that actually require judgment.

Turnover still happens. But its cost drops dramatically when the knowledge stays.

The firms that figure this out will not just retain institutional knowledge. They will compound it. Every year the operation runs, it gets smarter. That is the opposite of what most operations teams experience today, and it is available to any firm willing to treat knowledge as infrastructure rather than a side effect of having good people.