I've now worked with, in, and around enough organisations on their data — a dozen or so, if I count properly, across quite different industries, sizes, and levels of sophistication — that something has started to happen: the patterns show through. When you've seen only a few, every organisation's data problems look unique, specific to their industry and their systems and their particular mess. See enough of them, and the specifics start to feel like costumes over a much smaller set of recurring characters. The technologies were all different. The problems underneath were almost always the same. And — this is the part that took a dozen organisations to fully believe — almost none of the real problems were technical.
This is my attempt to write down what a dozen organisations have taught me, now that I can finally see the shapes that repeat. Consider it a field guide to the problems that are actually the problems, whatever the logos and the stacks.
Pattern one: the problem is never the technology they think it is
Every organisation I've worked with came to their data challenge convinced it was, at root, a technology problem. They needed a better platform, the right tool, a modern stack, a migration — the belief that somewhere out there was a technical purchase that would fix things. And in a dozen organisations, I have essentially never found that to be true at the level they believed it.
The technology was almost always adequate, or the technology problems were the solvable ones — real, but tractable, the kind that yield to competent engineering and time. Underneath the technology complaint, reliably, was something else: a disagreement nobody had resolved, an ownership nobody had claimed, a conversation nobody had had. The organisations that thought they needed a new platform usually needed to agree what their words meant. The ones that thought they needed better tools usually needed someone to own a decision. The technology was the thing they could see and buy, so it's where they looked — but it was rarely where the problem lived.
This is the single most consistent lesson: when an organisation tells you their data problem is technical, gently doubt them, and go looking for the human problem the technology complaint is standing in front of. It's almost always there.
Pattern two: the same word means three different things
If I had to name the most common actual problem, across all dozen, it's this: the organisation has never agreed what its own words mean, and its data faithfully reflects the disagreement.
Every organisation has its contested words — "customer," "active," "revenue," "churn" — where two departments quietly mean two different things and have for years, and where the reports have silently disagreed the whole time without anyone quite confronting it. It shows up as a "data quality problem" or a "reporting problem" or a "the numbers don't match" problem, and it gets chased, expensively, as a technical fault. But the numbers usually don't match because they're correctly computing different things that happen to share a name. It's not a counting error. It's an unresolved human disagreement about meaning, wearing the costume of a technical one.
I have watched organisation after organisation try to solve this with tooling — a better catalogue, a metrics layer, a governance platform — and I've come to believe the tooling only ever helps after the human work is done, and is worse than useless before it, because it just industrialises the disagreement. The definitions have to be agreed, out loud, between the people who currently disagree, which is a negotiation and often a mildly political one. No dozen organisations taught me a technical fix for this, because there isn't one. The word has to be agreed by humans before any tool can help.
Pattern three: the value dies in the last mile
The third recurring pattern is about where value fails to be created, and it's consistent enough to be depressing: organisations pour enormous effort into producing data — collecting it, cleaning it, modelling it, building beautiful platforms — and then lose almost all of the value in the last mile, the short distance between a correct insight and an actual changed decision.
The dashboard gets built and nobody opens it. The analysis is right and it doesn't change what anyone does. The insight is true and it dies in the gap between the analyst's screen and the decision-maker's gut. Over and over, I've seen organisations that were genuinely good at the production of data and genuinely bad at the use of it — because the last mile isn't a technical problem, it's a communication and trust and culture problem, and it's the one organisations invest in least because it's the one that doesn't yield to a purchase.
A dozen organisations taught me that the return on data investment is decided almost entirely in this last mile, and almost nobody spends there. They spend on the platform, the pipeline, the production — the visible, buyable, technical part — and then wonder why a true number never became a different decision. The value was always in the crossing, and the crossing was always human.
Three organisations, three costumes
Let me put faces — anonymised — on the three patterns, because a dozen organisations taught me these as stories long before I could see them as patterns.
There was the organisation convinced it needed to replace its entire data platform — a big, expensive migration was already being scoped — because "the current system can't give us reliable numbers." We looked. The system was fine. The reason the numbers weren't reliable was that three departments each maintained their own definition of the core metric the whole company ran on, and the "unreliable system" was faithfully reporting three different truths. They were about to spend a fortune migrating the disagreement onto a newer platform. What they actually needed was a two-hour meeting nobody wanted to hold. That's pattern one in the flesh: a human problem wearing a very expensive technical costume.
There was the organisation where "revenue" meant something subtly different to finance, to sales, and to the product team — recognised differently, timed differently, scoped differently — and had for years. Every month their numbers disagreed, and every month it got chased as a data-quality bug by people who genuinely didn't realise they were arguing about a definition, not a calculation. The fix wasn't technical and it wasn't easy: it was getting three senior people who each believed their "revenue" was the revenue into a room to agree one shared meaning. The tooling to enforce the agreement was trivial. The agreement was the hard part, and it was pure human negotiation.
And there was the organisation with a genuinely excellent analytics capability — good platform, good analysts, genuinely insightful work — whose leadership still made most decisions on gut, because the beautiful analyses arrived in a form and a language that never quite connected with how the decision-makers actually thought. The insight was real, and it died, every single time, in the last mile between the analyst's screen and the executive's judgement. All that production, and nearly all of the value lost in the final short crossing that nobody had invested in. Pattern three, and the most quietly wasteful of the lot.
The thread through all three
Stand back from the three patterns and they're clearly one pattern wearing three costumes. In every case, the organisation was looking at the technical layer — the tools, the platforms, the production — and the actual problem was in the human layer: the meaning nobody agreed, the ownership nobody took, the decision the insight never reached. A dozen organisations, a dozen different technology stacks, and underneath, the same displaced attention: energy poured into the part you can buy, while the part that actually determines success — the human, communicative, definitional, cultural part — went unattended because you can't purchase it and it's genuinely hard.
This is, of course, exactly what I believed when I entered this field from the side door of communication, years before I'd earned the right to be sure of it. I thought then that data was fundamentally people communicating, and that reading it as mere technology missed most of what mattered. A dozen organisations later, I no longer think it. I've seen it, repeatedly, from the inside, in enough different costumes to be certain of the character underneath.
A dozen organisations, a dozen stacks, three problems — none of them technical. The word nobody agreed. The decision nobody owned. The insight that never reached anyone. The technology is always where they look, and almost never where the problem lives. That's the whole map.
Why they can't see it themselves
A fair question is why, if these patterns are so consistent, the organisations living inside them can't see them. And the answer is instructive, because it isn't stupidity — it's structural.
They can't see it because they're inside it. The disagreement about what "revenue" means is invisible from within, because each department is quite sure their meaning is simply the meaning; the conflict only becomes visible when someone stands outside all of them and notices they're different. The technology framing is compelling from within because technology is what they can see and buy, and "we need a better tool" is a far more comfortable story to tell than "we've never actually agreed what we mean." And the last-mile loss is invisible because everyone is doing their job — the analysts analyse, the leaders lead — and no one owns the crossing between them, so no one is watching the exact place where the value falls on the floor.
That's why an outsider — a consultant, a new hire, someone who's seen a dozen of these — is so often the one who spots it: not because they're smarter, but because they aren't yet inside the assumptions. The patterns are hard to see from within and obvious from a step back, which is both why organisations keep missing them and why the most valuable thing you can sometimes offer is simply the outside view — naming, plainly, the human problem everyone was too close to see.
Learning to see the shape faster
The main thing a dozen organisations gave me isn't a solution — these human problems don't have tidy solutions — it's pattern recognition. Early on, I took every organisation's data challenge at face value, believed the technical framing, and went looking for the technical fix, wasting real time before discovering the human problem underneath. Now I can usually feel the shape of it early, because I've seen the costumes before.
When an organisation tells me they need a new platform, a part of me immediately asks: what disagreement is this platform being asked to migrate? When they describe a data-quality problem, I ask: which word do two departments define differently? When they show me an impressive analytics capability, I ask: does any of this actually change a decision, and if not, where does it die? I've learned to look past the presenting complaint to the recurring character behind it, and it's made me faster and more genuinely useful — not because I have answers they lack, but because I know where to look for the real question.
That's the compounding value of range in this field, and it's why I'm glad I've worked across a dozen organisations rather than gone deep in just one: the patterns only reveal themselves across variety. One organisation teaches you its specifics. A dozen teach you the shapes that repeat under all the specifics — and the shapes, it turns out, are where the actual understanding lives.
What I'd tell someone starting out
So if you're early in a data career and you want the shortcut that a dozen organisations bought me the slow way, here it is. Get genuinely good at the technology — it's real, it matters, and you can't lead the human work without the technical credibility underneath it; I'd never counsel skipping the craft. But hold, from the beginning, the knowledge that the technology is rarely where the real problem is. When an organisation shows you their data challenge, look past the tool they want to buy, to the agreement they haven't reached, the ownership they haven't claimed, the last mile they haven't crossed. That's where the actual work is, in almost every organisation, almost every time.
And that work — the agreeing, the owning, the crossing — is communication work, human work, the work of standing between people and meanings and decisions and making them connect. Which means the most valuable thing you can become in this field isn't the best engineer, though be a good one. It's the person who can see the human problem behind the technical complaint, and do something about it. A dozen organisations taught me that, and I suspect the next dozen will only teach it harder. The tools will keep changing. The three problems, and their stubborn humanity, won't.