The leader track 🤝 · for heads of data, analytics leads & curious minds · 6 x 45 min · no code to write
Thinking mode: why this role exists between the warehouse and the dashboard, what changes when transformations live in git, how to read a test suite as a trust budget rather than developer hygiene, what to buy and what to build, how to shape the team, and why generated documentation is the only kind that stays true. Each session ends with the questions to ask your data team.
Why analytics engineering exists
The role that appeared between the data engineer and the analyst, what forced it, and the sign your organisation already needs one.
🧾Leader 2 · easyModels as code
Version control, review, environments and rollback applied to SQL - and what it costs a team that has never had them.
🛡️Leader 3 · mediumTests as the trust budget
100 tests on 23 models is a governance artifact, not hygiene. Which failures you actually want to block a build, and which are noise.
⚖️Leader 4 · mediumBuy vs build the transformation layer
Core versus Cloud versus hand-rolled versus your ELT vendor's own layer, and the model count where the argument stops being close.
👥Leader 5 · mediumThe team shape
Analytics engineer, analyst, data engineer: who owns which layer, who reviews whose model, and how the handoffs actually work.
📚Leader 6 · mediumDocumentation that stays true
Generated docs and derived lineage versus the wiki nobody updates - and why the difference is structural, not cultural.
The builder track 🛠️ · for practitioners · 10 sessions x 45 min (b10: 60) · real DuckDB in your browser
One project: Bazaar, the multi-merchant marketplace from learn-data-modeling, rebuilt as dbt. You already know the model, so every session is about the craft. Each page runs real DuckDB compiled to WebAssembly and executes the SQL dbt itself compiled - so what you query in the browser is what the project builds on a laptop.
From hand-written SQL to a project
Run the finished project, read a real build's output, and see the same numbers appear - 111,906.48 to the cent - from version-controlled, tested SQL.
⚙️Builder 2 · easyThe project config
dbt_project.yml, profiles and targets walked line by line - materialization per layer as a decision, and vars instead of hard-coded dates.
Sources and staging
Declare the eight raw tables once, then one staging model each: rename, recast, no joins. The discipline that makes everything above it readable.
🕸️Builder 4 · mediumref() and the DAG
Explore the project's real lineage - 32 nodes, 47 edges, read from its manifest - and get an impact set before you rename anything.
🔧Builder 5 · mediumIntermediate models
The joins staging is not allowed to do, materialized as nothing at all - plus the fan-out guard expressed as a model rather than a warning.
🧊Builder 6 · hands-onDimensions, facts, snapshots
Six dimensions and three facts as dbt models, deterministic surrogate keys, and a real type-2 snapshot doing what a hand-written SCD load cannot.
🧨Builder 7 · hands-onThe break-a-model lab
Six real breakages, the project's own 100 compiled tests. No tests catches 0 of 6, generic catches 4, generic plus singular catches all 6.
📊Builder 8 · hands-onMarts and the business questions
Three marts at three grains, the four questions answered again, and why a mart never joins two facts even when it could.
📜Builder 9 · hardestContracts, docs and deployment
Model contracts, generated docs, exposures for the consumers dbt cannot see, and CI that tests only what a pull request touched.
🏁Builder 10 · hardest · 60 minCapstone: add a subject area
Returns and refunds through every layer - source, staging, intermediate, dimension, fact, mart, tests, contract - and a green build at the end.
What you leave with - a project that runs, not slideware
8 staging models
3 intermediate (ephemeral)
6 dimensions
3 facts
3 marts
2 schema.yml + 1 sources.yml
tests/ 5 singular tests
macros/ surrogate_key + 2 generic tests
snapshots/ merchants_snapshot
dbt_project.yml · profiles.yml
load_raw.py
build_browser_assets.py
Take learn-data-modeling-with-phoebe first if you can: this course rebuilds that course's warehouse, and the whole argument depends on knowing what was built by hand. It sits above learn-sql and beside learn-data-warehouse; scheduling and monitoring what you build here is learn-dataops, because dbt does not schedule itself.
Built from the dbt documentation (models, sources, tests, snapshots, contracts, node selection), the community layering conventions, and Kimball for the model being rebuilt - every source named on the session that uses it, with an honest out-of-scope list. Verified against a real dbt build: 23 models, 100 tests, PASS=121, ERROR=0.
Choose your path 🗺️
Two doors, one project. Leaders never write code; builders never sit through theory they have not just run.
The knowledge map 🧠
Both tracks at a glance - hover a session to spotlight its concepts, click any node to jump in.