Nobody documented what Lucy did.
That wasn't an oversight. It was invisible. She'd been running the inventory group at Finish Line for decades, and in that time she had become something the org didn't have a name for: the gap between what the systems said and what was actually true.
She knew which applications would spit bad data and quietly corrected it before anyone downstream ever saw it. She could look at a store's books and know when the numbers didn't tell the real story - dollar-correct, but the unit counts didn't add up. She could see what the systems couldn't, and she fixed what the systems wouldn't, and she did almost all of it off-book, off-system, in her head.
Then she retired.
What followed wasn't a transition. It was a flood. The problems she'd been quietly managing for years surfaced all at once, and nobody fully understood the shape of what she'd been doing. I was on the store systems side at the time, supporting POS and its connections into inventory. We'd worked with Lucy chasing down inventory discrepancies at the store level, so we had a piece of it. But only a piece. The scramble had already started by the time it landed on everyone's desk. We spent months just trying to stop drowning.
This is the Jane Phenomenon. I didn't name it after Lucy - I named it after every person like her I've found since, at every company, always under a different name. Lucy is just the one who taught me to see it.
It doesn't announce itself. Nobody builds a process around one person on purpose. It happens incrementally, in any organization that has someone quietly managing complexity the systems were never designed to handle, through experience, pattern recognition, and institutional memory that exists nowhere else. Jane fixes something the system should have caught. Then she fixes it again. Over time, the organization stops noticing the problem because Jane is handling it - and eventually stops noticing Jane is handling it, because it's just how things work.
The knowledge doesn't disappear when Jane leaves. The org just finds out it never owned it.
Retirement is the cleanest version of this story. Most of the time Jane doesn't retire - she gets promoted, laid off, burns out, or just stops absorbing the damage one day. Either way, it surfaces the same way: all at once.
After the months of drowning came two years of treading water - rebuilding inventory systems, trying to capture in software what Lucy had been doing in her mind. Trying to make the implicit explicit. Trying to bake institutional knowledge into a process that could survive the next retirement.
We got there. Eventually. But the cost - in time, in bad data, in decisions made on information that wasn't as clean as anyone thought - was real. And the ending wasn't clean either.
Three things to do the moment you spot your own Jane.
If you've read Issue 1, you already know the first move. Find your cranks.
One: find the cranks - not just in IT, everywhere in the company. The people constrained by the system or by leadership, doing more than their role technically allows because the alternative is watching something break. Set them loose on two questions: what's happening right now that nobody officially sees, and what process exists today that shouldn't exist at all. They already know both answers. Nobody's asked them yet.
Two: give them the resources to dig it out, not just permission to look. Finding your cranks and nodding at their insight isn't the job. Pair them with the time, the access, and the people it takes to actually move what's living in someone's head into documentation, working practice, and controls someone else can run. And name an owner to keep it current - documentation nobody updates just becomes tomorrow's Jane Phenomenon.
Three: let the mess come out before you try to clean it up. This step is going to be uglier than anyone in the room wants it to be, and that's the point. Every workaround, every manual correction, every "we've just always done it that way" has to surface before you touch a single system. Skip this and you'll build a beautiful, expensive, well-architected version of the exact same blind spot. That doesn't mean every workaround deserves to survive. It means you can't tell which ones do until you've seen all of them. The pain has to come before the cure. A band-aid was never going to fix this.
Once you understand how painful lost institutional knowledge can be, the instinct is to solve it permanently. Immediately. For us that meant an enterprise ERP system - the kind that's supposed to bake best practices into the platform and eliminate the Lucy problem at the root. We skipped one and two and jumped straight to the cure. We never drained anything first. We just paid for a very expensive band-aid we thought would fix the problem.
It didn't work out that way, but that's another issue...