About

I've spent fifteen-plus years in data, most of it on platforms and the teams that run them. The shape of the job has changed names several times over that span (BI, then data engineering, then platform, now increasingly AI), but the underlying problem has been remarkably stable: someone needs an answer, the answer depends on data nobody fully trusts, and the gap between those two facts is where the work lives.

I started close to the data, SQL, reports, the unglamorous business of working out why two systems disagreed about the same number. That's still the background instinct I bring to every architecture conversation, and it's why I'm skeptical of designs that look elegant on a slide and buckle the first time real data hits them. Real data is always worse than the diagram suggests.

What the work has looked like

Warehouse consolidation after a merger, where the hard part was never the pipelines but getting two organizations to agree on a single definition of a metric they each thought was already settled. Rebuilding an analytics ingestion pipeline from the ground up and proving it by parallel run before asking anyone to trust a number from it. Governance and metadata programs that had to earn adoption rather than mandate it. Deliberately handing model ownership to analysts, which cost central control and bought a great deal of throughput.

I write these up on the work page in the format I find most useful: situation, constraint, decision, the tradeoff I accepted, and what actually happened. They're written as patterns rather than company histories: the specifics belong to the organizations I did them for, but the reasoning is portable, and the reasoning is the useful part.

What I'm paying attention to now

Agentic systems in real data environments. Not the demo version: the version where an agent operates against a warehouse carrying a decade of accumulated history, inconsistent naming, and business logic that encodes decisions nobody remembers making. And where the people consuming the output will withdraw trust permanently the first time it returns a confidently wrong number.

That gap between the demo and the deployment is the most interesting problem I've encountered in years, and very little is being written about it by people who have had to actually operate one. So I'm writing it.

How I think about the work

• Correctness before coverage. A small set of numbers everyone trusts beats a warehouse full of numbers nobody does. This sounds obvious and is violated constantly.
• Ownership pushed outward. A central team that is the only group able to change anything is a bottleneck wearing a platform costume.
• Show the reasoning. Decisions outlive the people who made them. Writing down why is far cheaper than re-deriving it in two years, usually under pressure.
• Distrust the tidy diagram. If a design has no stated failure mode, it hasn't been thought about hard enough yet.

Outside of it

I live in a terminal more than is strictly healthy. I watch an unreasonable number of K-dramas and will defend the genre at length to anyone who opens the door. Milky Way bars. Happy to talk about any of this instead of data modeling, if you'd prefer.

Get in touch

Speaking invitations, podcasts, or a second opinion on a platform decision:email me. Topics I speak on are listed on thespeaking page.

Everything here is written in a personal capacity and represents my own views, not those of any employer, past or present.