When I led the software division at Reed Group (now Alight Absence Management), the bane of our existence was the dreaded "Action/Action Reason Code" file, a complex payroll output that broke employee time into a series of very specific segments. We avoided this format whenever we could, but sometimes it was the only way to get information about employees' leaves, and a large, insistent customer would force the issue. That's when we brought in Jen.

Jen had been at Reed Group longer than just about anyone. She knew how everything worked. More importantly, she also knew what didn't work and what to do about it. She was the only person who could make sense of the Action/Action Reason Code format and build a spec to pull the data we actually needed out of it.

She knew that most leaves came with the "LOA" action code, but she also knew that you sometimes had to look for the "PAY/SRT" combo when an employer changed an employee's pay but forgot to enter their reduced hours as a partial leave. She knew which employers always sent retroactive terms three weeks late, and which ones used the same code to mean different things depending on which division the file came from. No matter how hard we tried to document these idiosyncrasies, our only real source of truth was Jen's memory.

All of this meant Jen could never be fully out of reach or take a real vacation. And when she needed to prepare for maternity leave, we had to figure out how to get this knowledge out of her head. So she trained someone else to manage the Action/Action Reason Code files, which didn't really solve the problem; she just designated an heir.

The Jen Conundrum

Every benefits provider has a Jen. If you're running engineering at a growth-stage benefits company, and you don't know who your Jen is, then you probably are Jen. This person is critical to your team's success, but they're also a single point of failure. If they're unavailable when there's a problem with a complex feed, then you just aren't getting the data that day.

The obvious solution is to write it down: put it in Notion or give the code to an AI and ask it to draft a handbook. You can capture the LOA rule that way and maybe another 100 rules besides.

‍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.

What you can't capture is the judgment that says which rule applies when two codes contradict, or which interpretation is right when the employer's data is internally inconsistent, or how to tell whether this month's weirdness is a new pattern vs. a one-off mistake. That wisdom lives in the application that processes the data, or it lives in Jen.

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.

Don't designate an heir: build one

At Reed Group, we solved the Jen Conundrum by "cloning" her, but that didn't address the underlying problem, which was that the data processor couldn't learn from experience. Two weeks ago I wrote about how a learning system can solve something as unexpected as twins with the same first and last names. The same principle applies to the Jen problem.

A learning system like the Data Nexus uses AI to understand what it can handle confidently, without asking anyone. When confidence drops below a threshold, instead of guessing, it surfaces the ambiguity to a human with full context attached. The human resolves the case, then the system encodes the answer as a rule it can apply to the next instance, along with the context to recognize "similar but different" cases. As the human-in-the-loop solves more special cases, the number of cases that require help drops.

A learning system converts Jen from a single point of failure into a force multiplier. Jen supporting a simple data ingestion tool is shackled to it forever, as every escalation routes to her, over and over. Jen with the Data Nexus becomes Dr. House, only consulting on the really interesting cases while the system learns how to handle the next case on its own.

‍Jen with the Data Nexus becomes Dr. House, only consulting on the really interesting cases while the system learns how to handle the next case on its own.

Your experts are critical to your success. They have better things to do than babysit a data feed every week.

You need Jen too much for her to ever leave. Now make her want to stay.