How much of your data team’s week goes into keeping something alive that nobody would particularly miss?

It’s an uncomfortable question. There’s usually a reason each report, pipeline and tool exists. Someone asked for it, a project needed it and it solved a problem at the time.

Whether it still earns its place is another matter.

On the latest Data Matas, I spoke with Ian Pudney, Head of Data at the Wine & Spirit Education Trust. Early in the conversation, he put forward an idea that stayed with me: every piece of software you create becomes a liability.

You’ve given yourself something to run, secure, understand and eventually replace. The business might get enormous value from it but the obligation starts as soon as you build it, and often lasts longer than anyone expected.

With AI making it easier to produce code, reports and analysis, I think we need to take that obligation more seriously. We’re getting much faster at creating work for our future selves.

The impressive architecture might be wrong for you

Ian leads a small data team in a global education business. He’s also worked in technology companies, so he understands how different the requirements can be.

That’s easy to forget when you’re looking at what everyone else is building.

You see a conference talk about a difficult problem solved at enormous scale. The engineering is excellent. The speaker explains the choices and you come away thinking your platform ought to look something like theirs.

Except their business might have hundreds of engineers, different demands and a budget you’ll never have.

I understand the attraction. Engineers enjoy solving difficult problems, and new tools give us interesting ways to solve them. But adopting an architecture also means accepting the work that comes with it. Someone has to learn it, monitor it and work out what happened when it breaks.

Before you introduce another component, ask what your business can’t do today that it needs to do. Then ask whether the proposed solution fits the people who will actually operate it.

“Good enough” takes judgement. You need to know where a simpler approach will hold up and where it will let you down. Copying someone else’s stack doesn’t spare you that decision.

Every dashboard deserves a second interview

Ian told me he’s removed more reports than he’s created. I liked that. Building a report is visible work. Retiring one takes a different kind of confidence, particularly when someone senior originally asked for it.

But dashboards accumulate obligations, measures need checking, source changes need handling and users need help understanding why two figures disagree. Even a report that hardly anyone opens can keep generating work.

Ian’s team has been experimenting with answering business questions more directly. With Claude Code helping them work with their warehouse, they can sometimes take a clear request and deliver a package of analysis within an hour. That might include supporting data, a summary and suggested actions, often in Excel.

The person asking gets something they know how to use, without having to navigate a dashboard designed to answer twenty other questions.

There’s a reason we ended up building those dashboards. Answering every request individually was expensive, so we tried to anticipate the next question and give people the means to investigate it themselves. Sometimes that worked beautifully. Sometimes we handed someone a complicated interface when they needed ten minutes of help.

AI changes the cost of providing that help and it makes it worth revisiting decisions that once seemed obvious.

For your next reporting request, establish how often the decision comes up, who makes it and what they’ll do with the answer. A recurring operational decision may deserve a permanent dashboard. A question about one region’s performance last quarter may be better served by a piece of analysis.

You can always build something permanent when the need repeats. It’s harder to withdraw something once people assume you’ll maintain it forever.

A convincing answer still needs checking

We also got into whether AI needs a semantic layer.

Ian’s experience was encouraging and quite specific. Claude could explore his warehouse schema and help people who understood the data get answers more quickly. He was clear that this didn’t mean he was ready to connect the whole business and let everyone assume the results were right.

The person asking the question is doing some of the work here. They know what the business means by a term. They can spot a strange result. They know when to ask a follow-up question.

Take a seemingly simple request: how many customers did we have last year? You still have to decide whether that includes trials, inactive accounts, subsidiaries or customers who left halfway through the year. A query can run perfectly while answering a different question from the one the business intended.

During the conversation, I made the point that understanding the semantics of your data remains essential, whether you put that understanding into a dedicated technology layer or express it another way.

A useful place to start is with questions you can already answer confidently. Compare the AI’s results with your established answers. Look at the assumptions it makes, the corrections it needs and how much expertise it takes to review the output.

That will tell you more about what to build next than a successful demonstration on a conveniently straightforward question.

The prototype worked. Who owns it now?

Towards the end, Ian reflected on his team’s pipelines. They work reliably and helped establish the value of the warehouse. They also depend heavily on particular software and one person’s knowledge.

That’s a familiar situation. A small team uses what’s available, gets something working and proves the idea. The business starts relying on it. The team moves on to the next requirement.

Somewhere along the way, the experiment becomes infrastructure.

The original decision may have been entirely sensible. What deserves another look is whether the arrangement still makes sense now that the business depends on it.

Could another engineer understand how it runs? Could you change the destination without starting again? Do you know what happens when the person who built it is away?

This is where reusable connectors, readable code and source control earn their keep. They give the next person a reasonable chance of understanding what they’ve inherited.

AI can help write an integration quickly. You still need to account for API changes, failed loads and the knowledge required to diagnose them. Before building it yourself, look at how much of that work someone else has already solved.

Make room by questioning what stays

Ian’s question for our next guest was: which data activity does your team currently do that delivers the least value?

I’d put that on the agenda before the next discussion about tools or headcount.

Take one recurring piece of work and follow it through. Who uses the output? What decision does it support? What would happen if it stopped? Include the time spent maintaining it, explaining it and fixing it.

You may find it’s essential. You may find a simpler way to provide it. You may discover that everyone assumed someone else was using it.

If you want to simplify your data stack, those are useful discoveries. They give your team time to work on the questions the business actually needs answered.

Listen to the latest Data Matas episode with Ian Pudney for the full conversation.