Skip to content
Jonathan Hazeley

About

Platforms fail on trust, not on code. I architect Databricks lakehouse and agentic AI systems, and prove them before a business commits.

I started in mechanical engineering. An interview at Siemens turned me toward data. That detour became business school, then a few startups, then a decade building the data infrastructure behind business decisions.

From October 2025 to September 2026 I was the client-facing technical lead at Lovelytics on four engagements across Entertainment, Finance, Healthcare, and Real Estate. Two or three ran at once, because the next engagement started before the last one closed. I wrote the technical case behind a ~$1.5MM Microsoft and Databricks ECIF proposal. Before that: at Snap One I helped drive a 50% EBITA increase (~$50M) by building the pipelines and the governance framework behind them, and certifying the metrics leadership acted on; at Celonis I turned enterprise process data into ~$10M business cases executives would actually fund.

My focus now is AI-native data engineering: lakehouse platforms designed for the agentic era, and using AI to accelerate the engineering work itself. At Lovelytics that meant a 118-skill Databricks accelerator other engineers built inside, written once and reaching their coding agents over four surfaces. It also meant agentic systems on Model Context Protocol and the Claude Agent SDK that automate the translation and validation a migration otherwise repeats by hand, and the deployment that follows. In September 2026 I joined Climb, a Databricks-native Data and AI consultancy, as a Senior Data Engineer.

Outside the job I box, dance salsa, bachata and merengue, and build furniture in a shop I document the same way I document a lakehouse. 15 countries so far, most of them in Latin America and the Caribbean. The through-line, if there is one, is a preference for practices with an honest feedback loop: the round, the dance floor, and a joint that either closes or does not.

The method

How I run an engagement

The same four phases whichever shape the engagement takes, and what leaves each one.

  1. Assess

    Name the problem beneath the stated problem

    The problem a team reports is rarely the one worth solving. Before any architecture, I establish what breaks if the numbers are wrong, and who has to defend them. That decides what the work has to prove, not only what it has to build.

    Ships

    The baseline, and the definition of done

  2. Design

    Build the proof with the system

    Validation is designed alongside the thing it validates, not bolted on after it. The checks are config-driven, so a new table is one line of config and a new skill is a graded eval, never new rule code. The standard does not decay as the surface grows.

    Ships

    Target architecture and the validation contract

  3. Build

    Ship a domain at a time

    Delivery runs domain by domain. On a migration that means a parallel run against the source, with every table proven equivalent before anything is retired. A framework that only ever confirms what you hoped is not a validation framework, so the comparison has to be able to fail.

    Ships

    Production systems, and a passing check on each

  4. Hand over

    Make the standard outlive me

    A gate nobody runs is indistinguishable from no gate at all. The checks run in CI, not on request. The definitions live in a glossary the team owns, not in one engineer’s head.

    Ships

    Runbook, glossary, and the checks in CI

Skills

Languages & processing
  • SQL
  • Python
  • PySpark
  • Apache Spark (Structured & Streaming)
  • Working knowledge:
  • Pandas
  • NumPy
Databricks & lakehouse architecture
  • Databricks
  • Unity Catalog governance
  • Lakeflow Declarative Pipelines
  • Delta Live Tables
  • Delta Lake
  • Databricks Asset Bundles
  • Auto Loader
  • Medallion architecture (bronze/silver/gold)
  • Data Vault 2.0
  • Data Mesh
  • Dimensional modeling (SCD Type 1/2)
  • Migration architecture
Storage & query engines
  • Snowflake
  • BigQuery
  • Postgres
  • Working knowledge:
  • Amazon Athena
  • Presto
  • Trino
Cloud & delivery
  • Azure (ADLS, Fabric)
  • AWS
  • GCP
  • ETL / ELT
  • CI/CD for data
  • Environment promotion
  • Azure DevOps
  • GitHub Actions
  • Git
  • dbt
  • Fivetran
  • Astronomer
  • Working knowledge:
  • Apache Airflow
Agentic AI systems
  • Model Context Protocol (servers and clients)
  • Claude Agent SDK
  • Agent skill design (routing, deferral, graded evals)
  • Agent evaluation (pass^k graduation bar)
  • Agent governance (tool permissions, review gates)
  • Azure OpenAI
  • Prompt design & engineering
Analytics & BI
  • Power BI
  • Power BI semantic modeling (DAX)
  • Epic Clarity / Caboodle
  • Heap.io
  • Celonis
  • Working knowledge:
  • Tableau
  • Redash
Practice & leadership
  • Databricks migrations
  • Data governance and certified metrics
  • HIPAA-constrained delivery
  • Test-driven development for pipelines
  • Mentorship & technical guidance
  • Multi-engagement delivery
  • Level-of-effort estimation
  • Discovery workshops
  • Stakeholder management
  • Agile / Scrum

Education

  • M.S. Management (Business Analytics)

    Wake Forest University School of Business · 2017

  • B.S. Mechanical Engineering

    University of North Carolina at Charlotte · 2015

Credentials

All credentials
  • Databricks Certified Data Engineer Associate
  • AWS Certified Cloud Practitioner

Plus 14 training and course credentials across Data Engineering, AI, Cloud & Delivery.

Outside work

The longer version
  • Boxing
  • Salsa, Bachata, Merengue
  • Woodworking

Plus 15 countries across 4 regions, most of them where the music I dance to comes from.