The Ops Person Who Holds It All Together Is About to Quit

There is a specific person in your organization that this article is about. You probably already know who they are. They might be reading this.

They have a title like Operations Manager, Office Manager, Client Services Lead, or Senior Account Coordinator. The title undersells the job. What they actually do is hold together a collection of disconnected systems, undocumented processes, and organizational gaps through sheer force of competence and institutional memory.

They are the person who knows that the commission report from Carrier X always has the wrong date format in column G, and you have to fix it before importing. They know that Client Y's account is structured differently from everyone else's because of a deal struck in 2022 that nobody documented. They know that the CRM does not track renewal dates correctly for certain product types, so they maintain a separate spreadsheet. They know that when the approval process breaks - and it breaks every Thursday because of a batch job conflict nobody has fixed - you have to restart it manually from step 3, not from the beginning.

Nobody taught them most of this. They learned it by being the person who stayed late to figure out why things broke, and then kept showing up to make sure they did not break again.

The accumulation problem

This person did not start as a single point of failure. They started as a good employee who solved problems. Over time, each solved problem became a maintained workaround, and each maintained workaround became a dependency.

Year one: they learned the systems and the processes. They were efficient and helpful. Management noticed.

Year two: they started identifying gaps - things the systems did not handle, processes that broke under edge cases, handoffs that dropped. They built workarounds. Spreadsheet trackers, manual reminders, cheat sheets for the team. They became the go-to person for operational questions.

Year three: the workarounds hardened into the actual operating procedure. New hires were trained on "ask [this person]" as a process step. The official documentation, if it existed, was two years out of date. The actual process lived in this person's head, their spreadsheets, and their email templates.

By year three, they are not doing their original job anymore. They are running an informal systems administration function for a collection of tools and processes that were never designed to work together, held in alignment by their memory and their willingness to do the work nobody else can.

Why they are burning out

The work that made this person valuable is the same work that is destroying their engagement. There are four specific dynamics at play.

The complexity only grows. Every new client, new product, new regulation, new carrier, and new tool adds another exception to manage. The number of workarounds in their portfolio increases every quarter. Nothing is ever retired. Nothing is ever properly systematized. The pile only gets taller.

The work is invisible. Nobody sees them fix the commission import at 6:45 AM before anyone else logs in. Nobody knows they spend two hours every Monday reconciling data between three systems so the weekly report is accurate. The work is preventive - they stop problems from happening. The absence of problems is invisible. The presence of a problem, when they take a day off and something breaks, is the only time anyone notices what they do.

They have been asking for investment. Most operations glue people have suggested improvements - a better tool, an integration, a process redesign, a dedicated resource for the thing they are doing on top of their actual job. These suggestions were acknowledged, added to a list, and deprioritized in favor of revenue-generating initiatives. After the third or fourth time, they stopped suggesting.

What their departure looks like

When this person gives two weeks' notice, the first reaction is panic. The second reaction is a counteroffer - a raise, a title change, a promise that things will get better. Sometimes the counteroffer works. Usually it does not, because the root cause is not money. The root cause is that the job has become unsustainable, and a raise does not make an unsustainable job sustainable.

What happens next follows a predictable sequence.

Weeks 1 - 2: The departing person tries to document what they do. They write a 40-page document that covers maybe 60% of their knowledge. The other 40% is the contextual judgment they apply hundreds of times per week - "this particular carrier always does it this way," "this client needs to be handled differently because of their contract terms," "when this error appears, it actually means something else." That knowledge cannot be transferred in two weeks.

Weeks 3 - 8: The team absorbs the obvious responsibilities. Things mostly work. The exceptions start to pile up because nobody knows the workarounds. Small errors begin appearing in reports, reconciliations, and client communications. Each error takes longer to diagnose because the person who would have caught it in two seconds is gone.

Weeks 8 - 16: The accumulated exceptions become operational drag. The team is spending increasing time on firefighting. Client satisfaction metrics soften. Internal SLAs slip. Someone discovers a spreadsheet on the shared drive that nobody understands but that apparently feeds a monthly report the CFO relies on. A replacement has been hired but is still ramping, and the ramp is taking longer than expected because the documentation does not cover half the job.

What to do before that happens

The fix is not a retention bonus or a title upgrade - though both might buy time. The fix is investing in the systems and documentation that make the operation resilient before the key person leaves.

Step 1: Acknowledge the problem. The person who holds the operation together knows they hold the operation together. They know it is not sustainable. Having a conversation that acknowledges the risk - "we know too much of this depends on you, and that is not fair to you or safe for us" - is the first step toward solving it. It also signals that you see what they do, which matters more than most leaders realize.

Step 2: Map what they actually do. Not "ask them to document their job." That produces a document that reflects 60% of the reality. Instead, observe: shadow them for a week, log every workaround, every judgment call, every exception they handle. The output is a process map that reflects the actual operation - not the org chart version, not the policy manual version, the real one.

Step 3: Prioritize what to systematize. Not everything they do needs to be automated. Some of it needs to be documented. Some of it needs to be cross-trained to a second person. Some of it needs to be eliminated - the workaround for a bug that nobody ever reported to the vendor. And some of it - the high-volume, high-cost, high-repetition work - needs to become a system.

Step 4: Build the systems. Start with the highest-risk dependencies - the processes that would break most severely in this person's absence. A four to six week engineering engagement can typically systematize the top three to five critical workarounds, document the rest, and cross-train at least one additional person.

The investment pays for itself in three ways: it reduces the key-person risk, it frees the key person's time for higher-value work (which improves their engagement and retention), and it makes the operation more scalable. But the most important payoff is this: it makes the business resilient to the departure that is going to happen eventually, whether in two months or two years.

The conversation worth having this week

Find the person this article is about. Ask them: "If you took three weeks off starting tomorrow, what would break?" Listen to the answer. That is your risk exposure.

Then ask: "What would need to change for your job to be sustainable for the next three years?" Listen to that answer too. It is usually not "more money." It is usually "stop making me hold everything together with spreadsheets and email."

That second answer is a project brief. And the cost of acting on it is a fraction of the cost of ignoring it.