About

I’ve built a data function where there was none, and modernized one that had fallen behind. I’ve merged two that disagreed about the same number, which is harder than it sounds and about as political as you’d guess. Lately I’ve been making a platform ready for the agents that now answer from it: the definitions they read, and the evals on what they say.

For the last several years I’ve led a central function of ten-plus across data engineering, analytics and data science, reporting to a CTO. Before that I ran the database team behind a warehouse that grew into the hundreds of millions of rows, and before that I built BI platforms for other people’s companies.

The job has changed names several times over that span, from BI to data engineering to platform to whatever this year’s word is. The problem underneath hasn’t. 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, in SQL and reports, working out why a report and its source disagreed. Before any of that I trained as an electrical engineer and left optoelectronics with three papers and a provisional patent, none of which prepared me for getting two departments to agree on revenue. The SQL instinct is the one I still bring to an 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.

And the teams around the platform. Building a data function where there was none, with the definitions centralized first, the people second and the tools last. Working with executives up to board level, where the useful analysis is the one asked for before a decision rather than after it. Deliberately handing model ownership to analysts, which cost central control and bought a great deal of throughput.

I write these up as case studies in the six sections I find most useful: situation, constraint, decision, the tradeoff I accepted, outcome, and what I would do differently. They distinguish observations from recommendations and credit published industry examples in the text. Confidential specifics stay with the organizations; the reasoning is what I can share.

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. The consequence of a plausible wrong answer depends on the decision it reaches, so evaluation and review need to be designed around that use.

The practical question interests me most: what evidence would make a team ready to rely on an assistant for a particular task? I write about scope, evaluation, adoption, and the work that remains with the people operating it.