Data-driven is one of those phrases everyone uses and no one defines the same way. Here's how operators at high-growth companies actually build data culture, from early stage through scale.
This piece is adapted from an Operators Guild Focus Session on building a data-driven operating culture, featuring Casey Smirniotopoulos, Karen Chen, and Vishruta Kulkarni. The conversation brought together operators from across company stages to compare notes on what data maturity actually looks like in practice, where teams get stuck, and what separates the companies that use data well from the ones that drown in it. Focus Sessions are small-group, member-only conversations where operators pressure-test decisions, share systems, and surface the realities that rarely show up in frameworks or playbooks.
If you want access to sessions like this, including the recordings, the working examples, and the community behind them, you can apply to join OG.
"Data-driven" is one of those phrases that means something different to everyone. For some teams, it means a dashboard. For others, it means a weekly metrics review. For others still, it means a culture where no one makes a major decision without pulling a report first.
What the operators in this session agreed on: it starts with the decision, not the data.
If you don't know what decision you're trying to make, you don't know what data you need. That framing sounds simple, but it cuts against how most teams approach the problem. They build dashboards, then figure out what to do with them. They hire data people, then define what good looks like. They invest in infrastructure before they've established what questions the business actually needs to answer.
The operators who get this right tend to flip the sequence. Start with the decision. Work backwards to the data.
Data doesn't matter as much as you think at the early stage
This is a hard thing to say, and most data people won't say it. But the operators in this session did.
In the earliest stages of a company, data usually isn't the constraint. The constraint is customers, product, and execution. Founders and operators are moving fast, and the data infrastructure to support that pace hasn't been built yet because it doesn't need to exist yet.
The reckoning comes later, usually when a company hits the scaling phase and starts trying to answer harder questions. How do we double pipeline? Where should we allocate budget? Why is retention dropping in this cohort? These are the questions that data can answer, and they're also the questions that reveal just how much technical debt has accumulated.
The cost of not thinking about data early isn't felt immediately. It compounds.
Start collecting before you know what you need
Even if data isn't your priority at Series A, the decisions you make about architecture and collection will shape what's possible at Series C. Correcting bad historical data is extremely difficult. In many cases, it's impossible.
A few things worth getting right early, even before you have a dedicated data function:
- Assign someone in engineering to own data as part of their job, even if it's a fraction of their time. If no one owns it, it will accumulate in silos.
- Build data tracking into the launch checklist for new features. Every time a team ships something without thinking about how to measure it, they're creating a future blind spot.
- Prioritize recording history. You don't need to know exactly what you'll do with the data. You just need to make sure it exists.
The companies that treat data architecture as a product decision from the beginning tend to be in a much better position when scale forces the conversation.
Getting buy-in when data isn't a priority yet
Even when the business case for better data is clear, getting leadership to invest is rarely straightforward. Most executives want a clean data story. The reality is usually messier than that.
What tends to work: find the question a senior leader already cares about, and use it as the entry point.
If the CEO wants to understand how to double pipeline, that's your moment. Offer to run the analysis. Come back with what you found, including the gaps. Show them what you could answer with better data and what you can't answer without it. Then give them the options and let them make the resource call.
Pilots work for the same reason. They de-risk the ask for your champion. Rather than proposing a six-month data initiative, propose a scoped test that proves the value. When it works, other teams notice, and they want it too.
Directionally right is often good enough
There's a version of data maturity that becomes its own bottleneck. Teams spend months cleaning and consolidating data before making decisions, by which point the decisions have already been made by someone else.
The question worth asking is: how much value does this decision generate, and what does it cost to make it with perfect data versus directionally accurate data?
At an enterprise that had acquired multiple companies, each with their own Salesforce and HubSpot instances, the cost of consolidating everything into a single clean system would have stalled go-to-market motions for months. The better answer was to keep the data separate, compare each dataset on its own terms, and focus on how the data was presented and contextualized to decision-makers.
Perfect data cleanliness is rarely the goal. A clear, well-contextualized story that helps leaders make better decisions faster usually is.
Metric sprawl is real, and you probably can't eliminate it
Most companies eventually end up with multiple versions of the same metric. Some of those variants exist because someone ran a query wrong. Some exist because different teams genuinely need to measure the same thing differently.
Marketing and sales will often disagree on attribution. That's not a data problem. It's an organizational reality. The goal isn't to eliminate every variant. It's to establish a shared source of truth at the top and build clarity from there.
A metrics tree is one of the more practical tools for this. The idea is straightforward: align at the company level on the top metrics that matter, then map how those ladder down into functional and team-level metrics. As long as everyone agrees on the structure and the definitions are documented, teams can have the variants they need without losing the shared language.
One important discipline: if you're going to deviate from a shared definition, name the metric something different. Ambiguity in a meeting room costs more time than almost anything else.
Data ownership needs a clear answer
When data touches every function, ownership can get murky fast. The companies that handle this best tend to have two things: a centralized, unbiased person or team responsible for the data foundation, and a senior sponsor who cares about everyone speaking the same language.
Where that centralized function reports, whether to the CFO, the CTO, or the CEO, matters less than whether they actually have the organizational authority to set and enforce definitions. Someone needs to own the P1 metrics. The ones that the entire company should never be arguing about.
For operational metrics that live closer to the teams using them, ownership can be more distributed. But any change to a shared definition should require buy-in from every team that metric affects. That friction is valuable. It forces the conversation before the inconsistency shows up in a board meeting.
Hiring for data: generalists first, systems thinkers next
At Series A and B, the most important thing a data hire can do is get stuff done. Set up the pipelines. Pull the numbers. Answer the question in front of them. Hiring for speed and agility matters more than technical depth at this stage.
At Series C, and often at late Series B, the profile shifts. You need someone who thinks in systems rather than one-off solutions. Someone who, when asked for a metric, isn't just asking how to pull it today, but how to make sure everyone who needs that answer can get it going forward. Repeatability and scalability become the signal to hire for.
Three questions to ask when you enter a new data environment
When you're new to a company or a function and trying to understand the data landscape, the most useful starting points tend to be the same:
- Who are the decision-makers, and how do they actually make decisions?
- What historical data do we have access to, and where are the gaps?
- What are the most important things the business has visibility into, and more importantly, what does it not?
That last question is often the most revealing. It surfaces the champions, the pain points, and the places where data investment would have the most immediate impact.
Using AI to preserve what people carry in their heads
One of the more underappreciated data problems at growing companies is institutional knowledge. The context for why data looks a certain way, what happened historically, what decisions shaped the current state, tends to live in the heads of the people who were there. When those people leave, it often goes with them.
A few operators in the session are experimenting with AI as a practical tool for this: creating internal GPTs trained on documentation and Q&A, hooking AI tools into codebases to track when specific data collection started or changed, using transcription and conversation summaries to build running logs of how definitions and decisions have evolved over time.
None of these are complete solutions. But they're early signals of what it looks like to treat institutional knowledge as a data problem worth solving.
Join the conversations operators actually need
This session was one example of the work happening inside OG every day.
If you want access to sessions like this one, the recording, the discussion, and the operators comparing notes on what's working across their companies, consider becoming a member.
OG is where senior operators go to learn from peers, pressure-test decisions, and trade the practical insights that help teams and companies move faster.
If you're ready to be part of a community built for operators, you can apply to join OG today.