September 16, 2026
Here's a scenario that plays out in athletic departments more often than anyone likes to admit.
A sharp young staffer, an assistant, a GA, a sports scientist who's good with computers, builds the program a data system. It pulls the numbers together, spits out clean reports, and for a season or two it works beautifully. The staff comes to rely on it. It becomes part of how decisions get made.
Then that person gets a better job. Because they're good, and good people get promoted. They leave with the department's blessing and a genuine round of congratulations.
And the system dies with their departure. Not immediately, but inevitably. The first time it breaks, no one can fix it. The logic lived in their head. The workarounds were never written down. Within months, the thing everyone depended on is a black box nobody can open, and the program is worse off than before it existed, because now the old habits are gone too.
This is the risk that gets underweighted in every build-it-yourself decision, and in sports, it's not a remote possibility. It's close to a certainty.
In most industries, you can build an internal tool and reasonably assume the person who built it will be around for a while. Sports doesn't work that way.
Coaching and performance staffs turn over constantly. Assistants move up. Coordinators get head jobs. A strong performance hire at a mid-major is a target for a Power program; a strong one at a Power program is a target for the pros. The entire career structure of the field is built on upward movement, which means your most talented people, exactly the ones capable of building a system, are also the ones most likely to leave.
So when you hand the keys of a critical system to one talented person, you're not making a bet that they'll stay. You're making a bet against the fundamental nature of the profession. That bet loses more often than it wins.
When a person builds something themselves, the working understanding of how it actually operates rarely makes it out of their head.
Not the tidy version in a document, if a document even exists. The real version, the one that knows why this integration is held together with a particular workaround, why that number needs a manual adjustment every Monday, which part breaks if you touch the wrong setting. That knowledge is tacit. It's earned through building the thing, and it walks out the door wearing the same shoes as the person who earned it.
This is what makes a homegrown system fundamentally different from a piece of equipment. If your best coach leaves, the weight room still works. If the person who built your data system leaves, the data system slowly stops working, and no one left behind knows enough to save it. You didn't lose a staff member. You lost the only operating manual, and it was never written down.
Consider a program, one of many with a version of this story, that had its data platform built by undergraduate data-science students. Bright kids, a few hours a day, working in a common business-analytics tool. They built something real, and for a while it did the job.
Then it crashed. And a year later, it still hadn't been rebuilt.
But the lost dashboard was the smallest part of the damage. Two things mattered more. First, the students who built it were gone, graduated, moved on, and with them went any hope of a quick fix and any of the learning the project was supposed to provide. Second, and worse: the system had become the connective tissue between the strength staff and the sports medicine staff. It was how they stayed on the same page about who was available and who was at risk. When it went dark, that communication didn't route around the outage. It just stopped. Two critical departments went back to operating with less visibility into each other than they'd had before the system was ever built.
That's the real shape of this failure. It's not "the dashboard went down." It's "the way we worked together went down, and the people who could rebuild it are gone."
Here's the part that makes this risk so easy to ignore: nobody wants to plan for their best person leaving, because it feels like planning for betrayal.
But that's the wrong frame. Your talented staffer should pursue the promotion. You'd be happy for them, you'd write the recommendation, you'd celebrate the move. Their leaving isn't a failure of loyalty. It's the system working exactly as it's supposed to.
Which is exactly why building critical infrastructure around one person is such a quiet trap. You're not guarding against a villain. You're guarding against a good outcome, one you actively want for the people you've invested in. The question was never "will they betray us." It's "when this person we're rooting for moves up, what are we left holding?"
If the honest answer is "a system nobody else can run," then the build made your program's continuity depend on a single career staying frozen in place, which is the one thing you know won't happen.
The antidote to key-person risk isn't finding someone who'll never leave. There's no such person. It's making sure the system doesn't depend on any one person in the first place.
That means the operating knowledge can't live in a single head. It has to be documented, maintained, and owned by an entity that persists through staff changes, so that when someone moves on, the system doesn't move on with them. A new hire should be able to step in and keep working, not spend six months reverse-engineering what their predecessor built, or worse, quietly give up and go back to spreadsheets.
This is one of the underrated advantages of buying a platform rather than building one. The platform doesn't quit. It doesn't take a job at a bigger program. When your staff turns over, and it will, the system keeps running, the data stays accessible, the reports keep generating, and the new person inherits a working tool instead of a mystery. The institutional knowledge lives with the vendor, not with whoever happened to build it, so a promotion becomes a celebration instead of a slow-motion operational crisis.
Before a program builds its own system, the four-question framework we've laid out [elsewhere] still applies, but this one deserves to be asked out loud, plainly:
When the person building this gets the promotion they deserve, what happens to everything they built?
If the answer is "someone else can maintain it, it's documented, we're fine," then you've genuinely solved for continuity, and building may make sense. If the answer is a pause, or "we'd figure it out," or "honestly, we'd be stuck," then you've found the real cost of the build, and it's not measured in dollars. It's measured in the season you spend rebuilding what you already had, right after losing the one person who knew how.
The goal isn't to keep good people from leaving. It's to build a program that stays strong when they do.
What is key-person risk in sports technology? It's the risk that a critical system depends entirely on one person's knowledge. When a homegrown data platform is built by a single staffer, the understanding of how it works lives in their head. If they leave, no one else can maintain, fix, or fully operate it, so the system degrades and often fails.
Why is turnover such a big factor for homegrown sports systems? Because turnover in coaching and performance staffs is constant and upward. The most talented people, the ones capable of building a system, are also the most likely to be recruited elsewhere. Building critical infrastructure around one person is effectively a bet that they'll stay, which runs against how the profession works.
What happens to the data when the builder leaves? Often it becomes inaccessible. The system keeps running until it breaks, and when it breaks, no one remaining understands it well enough to fix it. Programs have been left with seasons of athlete data locked inside a tool no current staff member can open, along with the loss of any workflows that depended on it.
How do you protect against this risk? Ensure no single person is the only one who can run the system. That means documentation, maintainability, and ownership by an entity that persists through staff changes. Buying a platform is one way to achieve this, since the vendor maintains continuity regardless of your staff turnover.
Isn't it disloyal to plan for a staff member leaving? No, it's realistic and, honestly, supportive. Your best people should pursue promotions, and you'd want them to. Planning for their eventual move isn't guarding against betrayal, it's making sure their success doesn't leave the program in a hole. Good succession planning lets you celebrate a departure instead of dreading it.
