Ask a room of engineers how to improve a machine learning system and most will reach for the model: a better architecture, a bigger network, a newer technique. Ask where the returns actually come from, and the honest answer is almost always the same — the data. Model choice is visible and exciting; data quality is invisible and tedious. The value is distributed in exactly the opposite proportion.
The uncomfortable ratio
On most real projects, the overwhelming majority of the effort — and the overwhelming majority of the eventual performance — lives in the data, not the model. Cleaning it, understanding it, fixing labelling errors, handling missing values honestly, and making sure the training data actually resembles the data the model will see in production: this unglamorous work is where projects are won or lost. A modest model on excellent data will beat a sophisticated model on poor data almost every time.
This is not a controversial claim among people who have shipped systems that matter. It is close to consensus. Yet the way teams allocate their time rarely reflects it, because the incentives and the interest both pull toward the model. Naming the gap is the first step to closing it.
Why teams get it backwards
There are understandable reasons the model gets the attention. Model work is intellectually satisfying and well-documented; there is always a new technique to try. Data work is repetitive and specific to your organisation, so nobody has written the tutorial for it. And a better model feels like progress in a way that fixing a labelling inconsistency does not — even when the labelling fix moves the metric far more.
The result is teams that spend weeks tuning architecture while a systematic error in their labels quietly caps the achievable accuracy far below where the tuning could ever reach.
What data quality actually means
It is not a single thing. It means labels that are correct and consistent. It means training data that matches production reality rather than a cleaner, easier distribution. It means understanding and handling missing values deliberately instead of letting a default paper over them. It means checking for leakage — information in the training data that will not be available at prediction time and quietly inflates your test scores. Each of these is boring. Each of these matters more than the model.
Leakage: the silent scorekeeper
Data leakage deserves special mention because it is both common and invisible. When information that would not really be available at prediction time sneaks into the training data, the model looks brilliant in testing and fails in production. The scores were never real. Catching leakage requires discipline about how data is split and a suspicious eye toward any feature that seems too predictive. It is one of the most valuable habits a data team can build.
The practical implication
When accuracy is disappointing, the instinct is to change the model. The more productive first move is almost always to interrogate the data: look at the errors, check the labels, verify that training resembles production, and hunt for leakage. Nine times out of ten the problem — and the fix — is there. This is not a reason to ignore modelling; it is a reason to spend your effort where the returns are, and the returns are in the data.
Look at the data, not just the metrics
Aggregate scores hide as much as they reveal. A model at ninety percent accuracy might be failing catastrophically on the one category that matters most, and the headline number would never tell you. The habit that consistently separates strong teams from weak ones is unglamorous: they look at actual examples. They read the cases the model got wrong, one by one, and patterns jump out that no summary statistic would surface — a class of inputs that is systematically mislabelled, a subgroup the model never learned, a formatting quirk that confuses it.
This is slow and it does not feel like progress, which is exactly why so few teams do it. It is also where the most valuable insights consistently come from. An afternoon reading errors will usually teach you more than a week of tuning.
Data quality compounds
There is a compounding effect that makes early investment in data quality especially worthwhile. Clean, well-understood, well-governed data does not just help the model you are building today — it accelerates every model, dashboard and analysis that comes after. Conversely, a messy foundation taxes everything built on top of it, forever. Teams that treat data quality as a one-off cost miss that they are really making an investment that pays back across every future project. It is the closest thing to a free lunch that data work offers.
Building the habit
The teams that internalise this build data checks into their workflow the way software teams build tests: automated validation of incoming data, alerts when distributions shift, and a culture of looking at examples rather than only at aggregate metrics. It is less exciting than the latest architecture, and it is the single most reliable way to build systems that actually work.