Inheriting Chaos

I have been the analyst in this story - the humble SQL jockey sitting on the other side of that table, that knew where everything was in the warehouse, ERP, and GA, and what it actually meant and could see, clearly, that the direction the new owners were headed was going to cost them.

I was embedded with a firm taking over a consumer brand I am not going to name, brought in to understand the concentration of high-margin buyers and what it actually cost to acquire them. When we pulled CAC, the number we produced and the number in the firm's playbook did not agree because we had different answers to a more fundamental question: what the business believed a customer actually was.

We could not get to alignment. They hired a firm whose model agreed with their thesis. I left when the politics made the work untenable, and an attribution exercise trumped the playbook that made the firm successful in the first place

The definition was wrong from the start. The infrastructure they built on top of it was clean, well-funded, and pointed in the wrong direction.

That is the thing you are inheriting when you inherit a data environment; it’s not just technical debt, but accumulated assumptions, contested definitions, and occasionally organizational scar tissue from a prior attempt to resolve them that went badly. The analyst who is still there has watched at least one of those attempts fail.

That is part of why they are leaving.

The First Stone to Overturn

Most operators in PE-backed mid-market firms are running some version of the same data environment that include a few core system; an ERP, a CRM, maybe a purpose-built operational platform if the vertical is specialized enough, a BI tool that was purchased during a modernization push, configured to some degree, and then left largely untouched because the person who configured it left and nobody who came after them fully understood what they built. It has become a hazardous waste site for people to dump their point in time analysis that was not tracked as a part of a larger strategy.

And then a layer of spreadsheets and shared drives and email threads that have accumulated around the edges of all of it, doing the work the official systems were supposed to do but never quite did.

There’s a BI analyst who is still there; the dedicated keeper who knows they have job security with their deep knowledge of where all the bodies are buried, and where the duct tape and chicken wire is bound to crack first, but everyone in the firm knows they’ve been one foot out the door for 18 months because the work is thankless and the tooling is bad and every time they build something clean someone upstream changes the source data without telling them.

You, the operator, your first problem is not the data.

It is that the person who understands the data has one foot out the door, and everything they know lives in their head.

Rita Mae Brown Said if First, The Playbook is Wrong.

"Insanity is doing the same thing over and over again and expecting different results.”

The instinct, especially for operating partners who have been through this before, is to move fast on infrastructure and tooling from a prior playbook.

Get a data team in, spin up Snowflake or BigQuery, start piping the 10 most important reports from the legacy BI tool to the new one, and build dashboards that work.

That playbook is not wrong by any means, but the sequence is. The sequence is where most post-acquisition data programs lose 60-90 days they can never get back.

"Let's get the data into Snowflake first, then we can figure out what to measure."

"We'll audit the existing dashboards once the new environment is stood up."

"The analyst is transitioning out anyway, let's just document what we can and move on."

The problem with this sequence is that clean infrastructure built on undefined metrics produces clean infrastructure with undefined metrics.

You have moved the confusion from Excel into a warehouse and called it progress. The board deck still requires someone to manually verify the retention number because nobody trusts the pipeline, and there’s no governance in place because those KPIs were never vetted in due diligence. The weekly ops review still starts with fifteen minutes of reconciling two versions of the same figure because the definition was never resolved, just migrated to a new tool.

The data existed before you showed up, and the system does not reflect how the business actually thinks. That is the thing you are inheriting, and infrastructure alone will never fix it.

The First 30 Days Are a Knowledge Capture Problem

Before you touch the tooling, you need to understand what the tooling is actually doing.

Not at the level of "we have Tableau connected to a Snowflake."

At the level of: what decisions does this organization make every week, who makes them, what information do they use to make them, what are the acceptance criteria, and where does that information actually come from.

This is an interview process, and the data + analytics function is the first and most important interview.

The questions that matter are almost never about technology, they are about definitions, clarity, and understanding of their world.

What does this company mean when it says a customer has churned?

At what point does a lead become a qualified opportunity?

How is gross margin calculated - does it include or exclude fulfillment costs, and has that treatment been consistent?

When the CEO says revenue is up 12% year over year, what is she including in revenue and is that the same thing the CFO includes in their read out?

These definitions are almost never written down anywhere; they live in the institutional memory of the people who have been building and maintaining the reporting environment, and when those people leave, the definitions leave with them. What stays behind is a maze of dashboards that produces numbers everyone uses but nobody fully trusts, because the logic that generated them is no longer accessible, nor commonly understood.

You have 30 days, maybe 45, before the analyst jumps ship - you as the operator have the potential to write them off as the goblin guarding the gates of previous inefficiencies, or use that time to extract what they know and leverage their deep domain expertise to codify the domain before building the infrastructure.

Days 30 to 60 - What You Actually Build

Once you understand how the business currently thinks about its own performance and which metrics it actually uses, how they are defined, where the data comes from, what the known gaps and reliability issues are, you can start building toward something resilient.

This is not the moment to rebuild everything, it’s the moment to codify a source definition of truth for the 10 - 15 metrics that actually drive the operating review, the 15 numbers that leaders actually look at every week and the definitions that make them trustworthy.

A metric is not trustworthy because it comes out of a clean warehouse, but rather because everyone who uses it agrees on what it means and can trace the calculation back to the source data in a DAG. That agreement is a human and organizational problem before it is a technical one, and no amount of dbt modeling resolves it if the definitions were never settled upstream or built into contracts.

The work in days 30 to 60 is to settle those definitions in-writing with stakeholder sign-off, with explicit documentation of what is included and excluded and why; and then build the infrastructure that implements them.

In that order.

Days 60 to 100: World Building

By day 60, if the first two phases have gone well, you have something most acquired companies do not have at this stage: a documented set of business definitions that the operating team has agreed on, and a clear picture of where the data environment is reliable and where it is not.

Now you can build with confidence, as you are building a system that reflects how this business actually thinks, not a generic analytics stack that was configured for some abstract version of a company in this vertical.

This is also when the shadow systems start to become solvable; the Excel file that tracks the pricing exceptions or the Google Sheet where the ops team logs the manual adjustments. These are not problems you can address in the first 30 days because you do not yet know what they contain or why they exist.

By day 60, you should have this understanding.

The question at this point is how to connect them to the system of record so that every decision that happens in those surfaces becomes a durable, queryable record in the environment where the rest of your data lives. The operational tooling is often fine.

The problem is that it was never connected to anything, so the value it generates disappears the moment the work is done.

The Thing That Compounds

Whether you’ve been the analyst or the operating partner who has been through a bad integration, you remember the moment when you realized they were flying blind; when a board questioned you about cohort retention and ran into the fact that nobody actually knew the answer because the data to produce it had never been captured properly or had conflicting meaning across teams, or had been captured in three different ways by three different people who were all using the word "customer" to mean something slightly different, and that simply calculating CAC was a failed $150k project last year.

That moment usually comes around month four or five of the integration. By then, 90 days of decision data has been generated and lost. The people who understood the legacy environment have moved on. The new team is trying to build forward without any foundation underneath them.

The 100-day window is by no means arbitrary, it is the window in which the knowledge is still accessible, the systems are still visible in their original form, morale is closer to it’s original state, and the cost of getting the definitions right is still lower than the cost of living with the wrong ones for the next three years of the hold.

If you get the sequence right, knowledge capture first, definition alignment second, infrastructure third, what you have at day 100 is rare; a system that knows what the business knows, and can compound on it.

If you are navigating a post-acquisition data environment or building the playbook before the next close, we have built a library of 482 business metrics organized by functional domain and industry vertical that is worth starting from. It is not a substitute for the definition work, but it is a useful frame for the conversation.

And if the problem is bigger than metrics - if what you are inheriting is an entire data world that needs to be rebuilt from the business up - that is the work we do →