"We're a data-driven company" is one of the most frequently stated and least frequently true claims in business. Most organisations have data. They have dashboards. They have a BI tool. They have a data team.
What they often don't have is an organisation that actually changes its behaviour based on data. Decisions get made by the most senior person in the room, supported by whichever metric confirms their prior. The data team produces reports that nobody reads or ignores findings they didn't expect.
Being data-driven isn't about having more data or better tools. It's about organisational habits — who gets to make decisions, how those decisions are justified, and what happens when the data contradicts an intuition.
The uncomfortable truth
In many organisations, data is used to justify decisions that have already been made, not to make better decisions. The data team is a post-hoc rationalisation engine, not a decision-support function. Changing this requires cultural change, not a better dashboard tool.
The Data Maturity Spectrum
The organisation collects some data and produces reports. Decisions are made by instinct, but there is at least a question of what does the data say? Basic analytics infrastructure exists.
- →Transactional data in operational databases
- →Manual reporting (spreadsheets, ad-hoc SQL)
- →No single source of truth
- →Data accessible only to technical staff
Data is regularly consulted and influences some decisions. A BI platform exists. Key metrics are defined and tracked. Data still competes with intuition, and data wins sometimes.
- →Data warehouse with defined metrics layer
- →Self-service BI dashboards (Looker, Power BI, Tableau)
- →Key performance indicators defined and visible
- →Some data-driven decisions, some gut-based
Data is the primary input to most significant decisions. The organisation has defined how decisions will be made before looking at data. Experiments are run before major changes are made.
- →Experimentation platform (A/B testing infrastructure)
- →Decision-making process requires data justification
- →Data teams embedded in product and business teams
- →Counterintuitive data findings are investigated, not dismissed
AI and ML augment human decisions. Predictive models surface insights before problems become visible. The organisation anticipates rather than reacts.
- →Predictive analytics and machine learning in production
- →Automated decisioning for high-frequency, low-stakes choices
- →Data quality is a first-class engineering concern
- →External data enriches internal data for deeper insight
The Infrastructure: What You Need Before Culture Can Follow
Cultural change requires the right infrastructure. Teams can't make data-driven decisions if accessing data requires filing a ticket with the data team and waiting three days.
The Modern Data Stack
Data ingestion: Centralise data from all operational systems into one place. Fivetran, Airbyte, or Azure Data Factory replicates data from your SaaS tools (Salesforce, Stripe, Zendesk), operational databases, and event streams into a central repository.
Data warehouse: The single source of truth for analytical queries. Azure Synapse Analytics or Databricks for large-scale processing; dbt for transformation layer (clean, tested, documented data models).
Business intelligence: Self-service analytics for non-technical users. Power BI (native Azure integration), Looker, or Metabase (open-source). The goal is a non-engineer being able to answer their own questions without waiting for a data analyst.
Metrics layer: A semantic layer (dbt Metrics, Looker LookML) that defines your key metrics in code — once, consistently, used everywhere. This eliminates the "which dashboard is right?" problem.
The one-dashboard principle
If your organisation has 47 dashboards and nobody agrees which one is correct, you have a metrics definition problem, not a tooling problem. Define your key metrics once, in a metrics layer, and have every reporting surface query the same definition.
Data Quality as Infrastructure
The most data-sophisticated organisation in the world can't be data-driven if the data is wrong. Data quality is engineering infrastructure, not a data team concern:
- Data contracts: Service owners publish contracts for the data their services produce (schema, freshness, completeness expectations)
- Data validation: Great Expectations, Soda, or dbt tests validate data quality in pipelines before data reaches analysts
- Data observability: Monte Carlo, Acceldata, or Databricks observability features monitor for anomalies, missing data, and schema changes in production
- Data lineage: Know what data flows from where to where. Critical for debugging data quality issues and impact assessment of upstream changes.
The Culture: What Infrastructure Alone Can't Fix
Infrastructure is necessary but not sufficient. The culture change requires deliberate organisational work.
1. Define Decisions, Not Just Metrics
Most organisations track dozens of metrics without being clear about which decisions those metrics should inform. A metric that's tracked but doesn't change any decision is not data-driven; it's decoration.
The practice: For every significant recurring decision (feature prioritisation, pricing changes, market entry, headcount allocation), define in advance:
- What metric(s) will influence this decision?
- What threshold would change our course of action?
- How often is this decision reviewed?
This forces clarity about what matters and prevents the post-hoc data mining that produces "data-driven" decisions that were actually driven by something else.
2. Build an Experimentation Culture
The most reliable way to learn from data is to run controlled experiments. Not analysing historical data (which is confounded by selection bias, external events, and correlation-causation confusion), but actually randomising users or markets into treatment and control groups and measuring the effect.
What this requires technically:
- Feature flag infrastructure (LaunchDarkly, Azure App Configuration) to randomise users into experiment variants
- Event tracking that captures user behaviour at the granularity experiments require
- Statistical analysis tooling to correctly interpret results (t-tests, Bayesian inference, sequential testing)
What this requires culturally:
- Acceptance that many experiments will show no significant effect (this is information, not failure)
- Patience to run experiments long enough for statistical significance
- Willingness to ship the "winning" variant even when it contradicts intuition
The peeking problem
The most common experimentation mistake: checking results daily and stopping the experiment when it "looks positive." This produces false positives at high rates. Define your sample size and test duration before starting the experiment, and don't peek at results until you have the data you planned for.
3. Embed Data Expertise in Teams
A centralised data team that produces reports is a bottleneck and a handoff. Data analysts embedded in product, marketing, and operations teams — who understand the domain and have access to the data — are a multiplier.
The modern pattern: a data platform team that owns infrastructure (warehouse, BI tooling, data quality), combined with analytics engineers embedded in business teams. The platform team makes self-service possible; the embedded engineers do the domain-specific analysis.
4. Treat Data Literacy as a Leadership Skill
A data-driven culture requires data-literate leaders. Executives who can't interpret a confidence interval, don't understand the difference between correlation and causation, and make decisions by "looking at the dashboard" without understanding what they're looking at are a ceiling on organisational data maturity.
The investment: Regular data literacy training for leadership, not just individual contributors. A/B testing workshops. Statistics for non-statisticians. "What does this chart actually tell us?" sessions.
5. Create Psychological Safety Around Counterintuitive Findings
The most valuable data findings are the ones that contradict a senior person's intuition. These findings are also the most likely to be suppressed, explained away, or ignored.
Building a culture where counterintuitive data is welcomed, investigated seriously, and allowed to change decisions requires explicit leadership behaviour. Leaders who respond to surprising data with curiosity ("that's interesting, let's understand why") rather than defensiveness ("that can't be right, check your methodology") create cultures where data is actually used.
The Measurement of Data Culture
How do you know if your data culture is actually changing?
- Decision documentation: Are decisions recorded with the data that informed them?
- Experiment velocity: How many experiments are running per quarter? Is this increasing?
- Data self-service rate: What percentage of data questions are answered without a data team ticket?
- Time to insight: How long does it take from "I have a question" to "I have an answer"?
- Data trust: When data contradicts intuition, what happens? (Hard to measure, but observable)
The ultimate metric: does the organisation change its behaviour based on data, even when the data says something inconvenient?
Digital transformation and data strategy are areas I work on with organisations at every stage. If you're trying to build a data-driven culture — or understand why your current efforts aren't working — let's talk.