Jen Can Never Leave: When the Expert Is the Single Point of Failure

TV
Thiago Victorino
7 min read
Jen Can Never Leave: When the Expert Is the Single Point of Failure

Jen worked at Reed Group, now Alight Absence Management. Her job sounds boring on paper. She processed payroll files with two-letter codes in columns called “Action” and “Action Reason Code.” A combination like PAY/SRT meant nothing to a new analyst. To Jen, it meant a partial leave with a specific compliance treatment, and she could spot the case in three seconds across a spreadsheet of thousands.

Nobody else could.

That last sentence is the entire problem. Jason Cole, the CTO who tells Jen’s story on the darthealth blog, frames it without melodrama. Jen could not take real vacations. Not the kind where you stop reading email. Because every time something unusual came through the payroll pipeline, the system did not flag it. Jen did. And if Jen was at the beach, the unusual case sat in a queue, or worse, was processed wrong.

This is the texture of a governance failure that does not look like one. There is no breach. No audit finding. No regulator knocking. There is just one human being who has become a load-bearing wall, and a company that has quietly accepted that the wall can never be repaired without bringing down the building.

The Diagnostic Question

When you find a Jen in your operation, the instinct is to treat it as a staffing problem. Hire two more Jens. Cross-train juniors. Pay her a retention bonus large enough to buy her loyalty through the next fiscal year.

None of that solves anything. Cross-training assumes the knowledge can be transferred in a conversation. It cannot. Jen’s pattern recognition was not in her PowerPoint. It was in her hands, built over thousands of files where she had seen what happened when PAY/SRT was misclassified two quarters later. Hiring more Jens assumes the labor market produces them. It does not. Jen is the artifact of a specific company’s specific history, processed through one specific person’s specific career.

The right diagnostic question is the one Cole asked. Not “how do we replace Jen,” but “why does the company depend on Jen in the first place?” The answer is that the payroll system never encoded what the payroll system actually did. The codes were never documented because the people who used them did not need documentation. The patterns were never written down because the patterns lived in the muscle memory of the team that read them.

That is technical debt. It just happens to be carried by a person instead of a Confluence page.

Documentation Is a Photograph

Here is the line from Cole that earns the price of admission. “Documentation is a snapshot of what someone remembered on the day they wrote it. Wisdom is knowing what to do when data with the same smell but a different look shows up next time.”

Read that twice. The implication is brutal for any organization that has spent the last decade running knowledge management initiatives. The runbook is a photograph of a moment. The wisdom is the photographer’s eye, which the runbook can never capture. Every audit trail, every standard operating procedure, every onboarding deck is necessarily incomplete in the same way. The unusual case, the one that smells like PAY/SRT but is not quite PAY/SRT, is exactly the case the documentation cannot cover.

This is why the standard response to a Jen problem fails. You write the runbook. The runbook captures the cases Jen has seen often. The next unusual case shows up. The runbook does not cover it. Jen still has to look at it. Jen still cannot go on vacation. The runbook has solved nothing for the cases that actually matter, which are the ones that needed Jen’s judgment in the first place.

The trap is treating documentation as the destination. Documentation is a way station. The destination is a system that can do what Jen does, which is recognize that something is unusual and then know what to do about it. Or, in the cases where it cannot do the second part, at least know how to escalate the first.

What Cole Actually Built

Reed Group’s answer was something Cole calls the Data Nexus. The architecture is less important than the operational behavior. The Nexus learns Jen’s pattern recognition. It looks at the payroll file and applies the same heuristics Jen built over years. When it sees a familiar pattern, it processes the case. When it sees something ambiguous, something with the same smell but a different look, it does not guess. It flags the record for human review and tells the human what made it suspicious.

The system handles the cases that have a precedent. Jen handles the cases that do not. That single change rewires the entire economics of the role.

Cole’s framing is worth quoting directly. “Jen with the Data Nexus becomes Dr. House, only consulting on the really interesting cases while the system learns.” House did not see every patient who walked into Princeton-Plainsboro. He saw the patients who had defeated the standard diagnostic pipeline. That is a specialist’s job. Jen, before the Nexus, was doing the equivalent of every diagnosis from strep throat to lupus, all day, every day. The Nexus did not replace Jen. It promoted her.

This is the governance pattern. Encode the tacit knowledge that already has precedent. Escalate the novel cases to the human who has the judgment to handle them. The system gets faster at the routine work over time. The human gets paid for the work that requires actual expertise. And the human, finally, gets to go on vacation, because the routine queue keeps moving without her.

Why This Is a 2026 Pattern, Not a 2018 One

We have been telling this story wrong for a decade. The version we kept telling was “AI will replace knowledge workers.” That story was always too simple, and the people doing the actual operational work could feel it was too simple. Replace Jen with what? A model that has never seen a Reed Group payroll file? A vendor SaaS that does not know what PAY/SRT means in your specific compliance context?

The 2026 version of the story is different. The Nexus is not a generic model. It is a system that was built around Jen, that learned from Jen, and that runs alongside Jen as her instrument. It only exists because Jen existed first. The institutional knowledge was the input, not the output to be deleted.

The transferable pattern is this. Every “we have one person who knows X” sentence in your organization is technical debt. Not a charming quirk. Not a sign of strong culture. Debt. It has a carrying cost (vacation that the person cannot take, knowledge that walks out the door when they do, queues that back up when they are sick) and a refinancing cost (the project that finally encodes the knowledge into a system). Right now, in 2026, the refinancing cost is cheaper than it has ever been, because the underlying tools to capture, encode, and escalate are commodity.

The companies that will operate AI well over the next three years are the ones that go looking for their Jens deliberately. Not to replace them. To finally pay back the debt they have been carrying on their backs.

Do This Now

Pick one operation in your business and ask a single question. If this one person were to take three weeks of vacation, no email, no Slack, what would back up in the queue and what would get processed wrong?

That answer is your candidate Jen. The next question is what fraction of her work has precedent (encode it) and what fraction is genuinely novel (escalate it). Treat the encoding as a software project, not a documentation project. Treat the escalation as a workflow design problem, not a hiring problem. And put the human in the seat that requires her actual judgment, not the seat that requires her to do the same recognition task ten thousand times in a row.

Then send her on vacation. The system you built will tell you whether you actually finished the job.


This analysis synthesizes Jen Can Never Leave by Jason Cole (Reed Group, May 2026).

Victorino Group helps operations leaders convert single-expert dependencies into governed AI-augmented workflows, turning the Jen on your team into the expert who finally takes a real vacation. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation