I recently spoke to Toby Henley Smith, Senior Analytics Engineering Manager at Moneybox, on Data Matas. We covered trust, psychological safety, cloud costs, AI, semantic layers and what makes a good data engineer. They sound like separate topics, but I think they all come back to the same thing: judgement.
Good data teams know what not to build
Early in his career, Toby fell into a trap that will be familiar to plenty of people in data. Being valuable meant becoming the person who could do everything, from finding the data and building the analysis to producing the answer and saving the day.
The problem with the superhero model is that it doesn’t scale. More importantly, it misses where the real value of a good data team lies. Can people trust the numbers? Can you bring evidence to a difficult decision? Can you challenge an assumption when the data says something different?
The same principle applies to the systems we build.
Testing, observability and clean architecture are all useful, but they aren’t automatically valuable because they’re considered good engineering. You can build an incredibly sophisticated testing framework for a pipeline that barely matters, or spend months designing the perfect stack while the business is still waiting for an answer.
Sometimes good engineering means knowing what not to build.
Constraints can be healthy
One of Toby’s points that stuck with me was the value of constraints. When budgets tighten, teams have to decide what they actually care about and every pipeline, workload and cloud bill has to justify itself.
If you had to cut your data infrastructure costs significantly tomorrow, what would you switch off first and what could you absolutely not lose?
The answer tells you quite a lot about where the real value sits. Good data teams should probably be asking those questions before the CFO asks them.
AI makes judgement more valuable
AI makes this even more important. As producing code gets cheaper, simply writing it becomes a smaller part of an engineer’s value.
Agents can already produce SQL, suggest transformations, explain errors and help build pipelines. As those capabilities improve, the valuable skills move towards understanding the problem, making trade-offs, reviewing what the machine produces and knowing when it has confidently got something wrong.
It also gives us a reason to question some of the assumptions behind today’s data stack. Toby raised an interesting point about semantic layers. If AI gets much better at understanding context and working with data, will we need the same abstractions in the same places?
Maybe we will. But we shouldn’t assume today’s best practice automatically becomes tomorrow’s.
We don’t need more superheroes
A lot of the AI conversation still focuses on replacement. I think the more useful question is what happens when machines take on more of the repetitive work and engineers spend more time on architecture, context and decisions that require judgement.
That also makes psychological safety more important. Teams need people who are comfortable experimenting, admitting when they don’t know something and learning from what went wrong. A culture built around everyone needing to be the smartest person in the room wasn’t particularly healthy before AI, and it certainly won’t help us get the best from it now.
The question I came away with after speaking to Toby was simple: are we building better data systems, or just more complicated ones?
The best data teams aren’t the ones with the most impressive architecture diagrams. They’re the ones that understand where reliability matters, where complexity earns its keep and where a simpler solution will do the job.
AI will change the tools and probably some of the architecture around them, but it won’t remove the need for judgement. I suspect it will make good judgement considerably more valuable.
Watch my full conversation with Toby Henley Smith on the latest episode of Data Matas, where we get into trust, over-engineering, AI, psychological safety, cloud costs and what all of this means for data teams.
And if the complexity of building and maintaining reliable data pipelines feels familiar, that’s exactly the problem we’re working on at Meltano.
Book a demo here to see how Meltano can help your team spend less time managing pipelines and more time putting your data to work.