Executive Summary
Your best data contractor has just left, and it turns out nobody else knows how the key reports are built, or what the metrics really mean.
Things slow down considerably. You can't be confident in the numbers for board meetings or investor updates. Your valuation might be at risk because your data has become a bit of a black box.
It's time to stop renting knowledge and start building a company asset. The answer isn't just another contractor. It's a shift in how you work: documenting as you go, setting up a governed semantic layer, and creating a reliable self-serve hub.
What happens when your main data person leaves
It's a pattern I've seen in quite a few scale-ups. Things are moving quickly. You hired a capable data contractor who became the go-to person for every query, dashboard, and metric definition. They were incredibly productive, a 'data hero' who built your reporting suite almost single-handedly. The business, quite rightly, valued their speed.
And then they hand in their notice.
Suddenly, what you thought was an asset turns out to be a significant liability. A key dashboard breaks. Finance asks for a small change to the monthly investor report. Nobody is quite sure where the logic lives. Is it in the BI tool, a SQL script, or a forgotten Google Sheet? The knowledge wasn't transferred; it simply walked out of the door with them. It's an uncomfortable realisation that you haven't built a data function, you've just been renting one person's brain.
This isn't the contractor's fault. It's a systemic issue. You have likely moved to the cloud and hired smart people. But you may have just moved your existing problems to a new system, only faster. Automating a broken process just produces unreliable data at speed, and relying on one person to manage that is a problem waiting to happen.
The cost of undocumented knowledge
Key person dependency is one of the most significant, yet common, of all Scale-up Data Challenges. It feels efficient in the short term, but the long-term cost can be very high. When that person leaves, you are often left with a portfolio of data assets with very little documentation, no real governance, and diminishing trust.
I worked with a Series C company that was preparing for an acquisition. Their analyst, who had built their entire Looker instance, left for a better offer two months before due diligence was due to start. The data room requests came in, and the leadership team couldn't answer basic questions about their own cohort definitions. The deal was delayed by a full quarter while we helped them reverse-engineer the whole system. The lack of a clear Data Strategy put their valuation at risk.
Your business has likely invested in tools like Snowflake, dbt, or Looker, but may have under-invested in the processes that make them resilient. The problem isn't the technology; it's that the business logic, the 'why' behind the numbers, is locked away in one person's head.
Moving from people to systems
The only way I've seen to prevent this is to shift from relying on people to relying on a system. This usually means adopting a documentation-first approach. It's not about writing thousand-page documents that nobody reads; it's about building the knowledge into the workflow itself. This is at the heart of a sustainable Founder Data Strategy.
1. Create a governed semantic layer The first step is to stop defining metrics in slide decks or one-off SQL queries. All your core business logic, your official definitions of 'Active User', 'Net Revenue', or 'Churn', needs to be defined in code, in one place. A well-managed Semantic Layer acts as the single rulebook for your data. It ensures that when someone asks for revenue, they get the same number, every time, regardless of who is pulling the report. This is the foundation of a Single Source of Truth.
2. Set up a self-serve hub Think of this as your company's internal library for data. A straightforward space in Notion or Confluence with simple guides for your core data assets. It should answer basic questions: Where does this data come from? When was it last refreshed? Who is the business owner? What are the known limitations? This hub becomes a key part of your Data Onboarding for every new employee, which should reduce the number of 'Can you just show me where...' messages that data teams often receive.
3. Introduce light governance This isn't about bureaucracy; it's about putting up guardrails. I find light governance works best when it's built into workflows, not managed by committees. For example, using pull requests in GitHub to approve any changes to a core metric definition. This creates an audit trail automatically and encourages peer review. It means no single person can change a vital calculation without anyone else knowing. This helps turn your data from a fragile liability into a reliable asset, which is important for your Exit Strategy.
Accepting the initial slowdown
I should be clear: implementing this will feel slow at first. Your team is used to the quick answers they get from asking your 'data hero' a question on Slack. Asking them to consult a self-serve hub or wait for a pull request to be approved is a significant change. You can expect some resistance.
This is the difficult part that many companies, understandably, tend to put off. It's often politically easier to hire another contractor than it is to get the Head of Sales and Head of Finance to agree on a single, codified definition of 'ARR'. But that work, which is as much about people as it is about data, is what solves the problem for the long term. You have to move a bit slower for one quarter to move much faster for the next three years.
The result: a more resilient business
By building a system that doesn't depend on any one person, you make the business fundamentally less risky. Your data becomes a resilient, documented asset, rather than a fragile dependency. Board meetings become more productive because you're debating the strategy, not the validity of the numbers. Due diligence becomes a much smoother process. And, perhaps most importantly, you can be more confident that if a key person leaves, the company's intelligence doesn't leave with them.