Some problems are easy to name in a meeting. Budget gaps, missed deadlines, a vendor who is not delivering. The structural data problems that slow organisations down rarely make it onto the agenda. They are too diffuse to point at, too familiar to flag, and often too uncomfortable to raise with the people who approved the original decisions.
That does not make them easier to fix. Pipeline fragility, undocumented data sources, inconsistent definitions, platform complexity that nobody fully understands - these issues compound quietly. By the time they surface, they have already changed the cost structure of everything downstream.
This article names five of them. Not to criticise the teams who inherited them, but to make it easier to have the conversation that starts fixing them.
Every data team has one. A pipeline that produces correct-enough output and has not been touched in two years. Nobody wants to open it. Nobody fully knows what it does. The person who built it has left.
The risk is not that it breaks. It is that when something changes upstream, a schema update, a source API version bump, a new field the business starts relying on; the break is invisible until it matters. By then, the output has already been wrong for weeks.
The fix is not a rewrite, but it is documentation. Even a rough record of inputs, outputs, expected behaviour, and known quirks reduces the risk significantly. Start there.
Finance says revenue is up six percent. Marketing says it is up nine. Both are right from where they sit. The difference is in how they handle returns, timing, attribution, or currency conversion. Nobody agreed on a definition and nobody wrote it down.
This is one of the most common data problems in mid-to-large organisations, and one of the hardest to fix, because agreeing on a single definition requires a conversation across teams that nobody has prioritised.
The cost shows up in every board meeting where a number needs a footnote, every report that takes three days to explain, and every time the data team has to caveat an answer.
Every data platform has a de facto data catalogue. It lives in Slack, in email threads, in the memory of whoever has been there longest. Ask where a metric is defined and someone will point you to a Confluence page last updated in 2022 and a Slack message from someone who no longer works there.
A proper catalogue does not require a dedicated tool. It requires a decision about where definitions live, who owns them, and a commitment to keeping them current. That last part is where most efforts fail.
Data platforms are designed at a point in time. The organisation that commissioned the design three years ago was different: smaller, with fewer teams, a simpler product, a different data model. The platform reflected that.
The organisation has changed, but the platform has not. Features were bolted on to cover the gap. Now the architecture is a record of every compromise made under time pressure.
The question worth asking is not "how do we fix this?" It is "what would we design if we were starting today?" The gap between that answer and the current state is the technical debt backlog.
Many data problems live inside tools you cannot fully control. When the pipeline belongs to the vendor, the fix is limited to what the vendor allows. When the schema is dictated by the SaaS product, the data model is theirs, not yours.
This is increasingly relevant as organisations question the SaaS renewal decisions they made three to five years ago. The pipeline architecture that made sense when the tool was the best option in the market may not make sense today. That conversation is worth having before the next renewal, not after.
Naming these problems is the first step. The second is deciding which one to address first, not the most urgent, but the one whose fix creates the most headroom. If it would help to think it through, talk to our data team.