Selected work
Bringing six data portfolios together
Xero · Vice President / General Manager, Data · 2021–2024
What I owned
I brought six data portfolios into a shared strategy and operating model, and grew the organization from 8 to 65 across data engineering, analytics, and platform functions. My responsibility was both the direction of the platform and the organization needed to deliver it.
What the team delivered
We reduced enterprise data latency across roughly 800 production data stores from 48 hours to five minutes. That work helped provide the data foundations for JAX, Xero's AI product.
Why this matters to me
This is the kind of platform work I enjoy: solving a problem the business has today while making things possible that were difficult before.
CDC and near-real-time sales reporting
Ticketmaster · Program leadership and hands-on delivery
Sybase, Java, Apache Avro, Kafka, Kafka Streams, Snowflake, SQL, PostgreSQL, AWS, Terraform
What I owned
I led the consumer-side delivery of a change-data-capture and reporting program across roughly 500 Sybase ticketing databases. That meant about 15 consumer-side engineers, working with six to seven source-system engineers. I owned the translation of product requirements into reporting logic for NFL and other sports and theater clients.
The system had to support ticket-release decisions during busy sales periods approaching 10,000 ticket sales a minute, along with refunds and other changes, without putting unnecessary pressure on the ticket-selling systems.
What I built, and what the team built
We ran parallel processing paths from a shared Java/Avro producer and Kafka topics. I managed the principal engineer and his team, who owned Snowflake ingestion, historical retention, and current-state modeling. I personally worked through business logic buried in legacy stored procedures and wrote the consolidated reporting SQL in Snowflake.
I also designed and wrote the alternative: a Java Kafka Streams application using the same business logic, writing into a self-hosted PostgreSQL cluster on AWS. I built and ran that infrastructure in Terraform, with implementation help from a contractor team.
Why two implementations
I cross-checked the two paths against each other and against source-system results. That turned up defects in the original stored procedures and helped improve reporting correctness upstream. I also worked as an architectural and Kafka/Avro partner to the producer team on missing or stale records, topic compaction, and monitoring.
As an early customer of Snowflake’s Kafka connector, I worked with their product teams on ingestion requirements, topic metadata, and record ordering, tested early releases, and later joined previews of scheduled tasks and materialized views.
The first program landed in under a year. Snowflake reporting ran about five minutes behind real time, and we chose it over the custom Kafka Streams/PostgreSQL path for scalability and maintainability. The alternative made the cost of keeping equivalent logic current across 9–15 related tables, under bursty load, very concrete.
SQL-first Databricks platform
Ticketmaster · 2020
Databricks, Apache Spark, Spark SQL, Python, Scala, Delta Lake, Kafka, YAML, Git
What I owned
This was a separate program from the Snowflake CDC work. I led platform architecture and a migration involving about 24 engineers across three data-delivery teams and one platform team. The aim was to let engineers build and operate data products in SQL without having to be fluent in Spark, Scala, or Python.
It sat under a cost-reduction mandate. The existing Snowflake environment was over $3 million a year; that figure is the wider estate, not this workload.
What we delivered
I designed a notebook-based harness where engineers could write and test SQL, iterate on individual steps, and publish YAML pipeline definitions. I used the harness against real reporting requirements and contributed the business-logic judgment. Engineers concentrated on silver-layer transformations and gold-layer models.
Delivery was a mostly Python framework with performance-critical pieces in Scala. Bronze ingestion from Kafka was configuration-driven. Scheduling covered continuous ETL, record-count and timestamp triggers, and workflow dependencies. Git promotion, a custom dependency engine, automated recovery, Delta Lake restore points, and failure notices to producers and consumers were part of the operating model. Kafka topic, partition, epoch timestamp, and client metadata stayed intact through the warehouse layers so we could tell where a number came from.
By December 2020 we had a working platform and two high-profile products: sales reporting and attendance. Sales reporting reached about 30-second freshness. Annual operating cost for that comparable workload went from about $300,000 to $50,000, even with tighter requirements.
Sitting with the people who have to use the numbers
Ticketmaster and Xero
I worked directly with Ticketmaster Product, NFL stakeholders, and client account teams to pin down requirements, answer technical questions, and set shared expectations about what would actually ship. At both Ticketmaster and Xero I was the technical counterpart in client meetings: helping customer technologists, product leaders, and executives understand what we would deliver and how it would work.
Getting delivery onto a workable footing
Radix · Chief Technology Officer · September–December 2025
What I owned
During a leadership transition, I retained key engineering leaders and built a two-year product and engineering roadmap tied to profitability goals and realistic staffing constraints. I also evaluated cloud strategy and advocated for reducing dual-cloud complexity.
What changed
The engagement established a clearer delivery direction and retained important technical leadership. The roadmap connected near-term product work with longer-term platform changes rather than treating them as separate plans.
Still building
Scale Data · Founder / Principal · 2024–present
Through Scale Data I lead a small senior team delivering software, backend systems, cloud infrastructure, and data platforms. I also build AI-assisted engineering workflows. Staying hands-on keeps my judgment close to what the tools actually do, rather than what a demonstration suggests they might do.
I want to know where the tools fall over, but just as importantly, when they've moved past a limitation and we should be doing something differently.