This route decides how the team ends up owning the warehouse rather than watching it get built. It sets the engagement as a measurable curve, the four formats that actually move skill, and the prepared answers to the six objections that arrive in every project. The deliverable is not the warehouse — anyone can sell them that. It is the week their output overtakes yours.
Stand 29.07.2026
The shape of the engagement
Enablement fails quietly: everything ships, everyone is happy, and six months later every change still arrives as a ticket addressed to you. The fix is to make transfer a number that is visible from week one.
Your share of the work starts near total and falls to near nothing; theirs rises to meet it. The crossover is the deliverable. Put the curve in the statement of work with numbers, because a curve that stays a metaphor never gets measured.
Sixteen weeks, with the signal that tells you the week actually happened
Week
Your share of merged PRs
What the team owns
Signal
1–2
~90%
nothing yet — reading, then workshop 1
the layer contract is committed, by them
3–5
~70%
one silver table end to end
the first PR you did not have to touch
6–8
~45%
two gold tables and the CI job
they review each other before you see it
9
~30% — crossover
the alert rota
you come off the rota and nothing changes
10–12
~15%
all pipelines, all runbooks
an incident resolved without you
13–16
≤10%
everything; you review by exception
game day survived; your name on no runbook
The percentages are not targets to hit exactly — the shape is. And it is measurable on the platform, not only in the repository, because what matters is who operates the warehouse rather than who types:
sqlWho is actually operating this warehouse? Run it weekly; paste it into the status note.
-- Action names differ per service. List yours first:
-- SELECT DISTINCT service_name, action_name FROM system.access.audit
-- WHERE event_date >= current_date() - INTERVAL 7 DAYS;
SELECT date_trunc('WEEK', event_date) AS week,
user_identity.email AS actor,
count(*) AS write_actions
FROM system.access.audit
WHERE event_date >= current_date() - INTERVAL 90 DAYS
AND service_name IN ('unityCatalog', 'jobs')
AND action_name RLIKE '(?i)create|update|delete|run'
GROUP BY ALL
ORDER BY week, write_actions DESC;
Why here
This prevents a warehouse that works and a team that cannot change it. The defect is invisible during the project, because during the project you are there. It surfaces the first time silver.customer needs a new attribute and nobody but you has ever opened src/dwh/common/scd2.py.
The second reason is commercial and works in your favour: a falling line is the only honest evidence a sponsor has that they bought capability rather than headcount. A line still flat in week 12 means staff augmentation at consultant rates, and eventually someone notices.
Doing it
Put the curve and its measurement in the statement of work, with the week-9 crossover named.
Run the audit query every Friday and publish it, including the weeks it moves the wrong way.
From week 5, stop taking tickets that touch gold. Review them instead; the queue slowing down is the point.
Leave the alert rota in week 9, not in the final week — standby for a fortnight, then off.
Embedding it
In week 3 ask which two tables they will own end to end, then refuse to merge anything on those under your name.
When asked to do something you already taught, answer with the file path, not the fix.
Have them present the architecture to their own stakeholders in week 8 while you sit at the back and say nothing.
In week 10 ask each engineer which part they would not want to be on call for. That names the gap while it is still cheap.
Defaults
Numbers in the statement of work, measured weekly, visible to the sponsor.
Off the alert rota by week 9 at the latest.
One named human owner per gold table by week 6, written into the table COMMENT.
The final quarter is theirs; you review by exception and write nothing.
Gotchas
The line that never falls. You are faster, so you do it, so they never do. It does not show in the standup mood — it shows in the merged-PR count, which is why you count.
Reaching the crossover by removing yourself rather than raising them. It measures as success and arrives as a 3am incident nobody can resolve. Tell them apart by asking who wrote the last three runbooks.
Holiday as the real test. If the daily load cannot survive a week without you, week 9 did not happen whatever the chart says. Take that week off deliberately, in week 11.
A plateau presented as ownership: they say they own it while every non-trivial PR waits on your approval. If you are a required reviewer everywhere, you are still the bottleneck under a new title.
One a week from week 2. Ninety minutes by default, two hours for modelling, six people maximum. The proportion is the argument: four on architecture and modelling, one and a half on testing, the rest on governance and operations. Teams ask for more tooling sessions because tooling feels productive — but a wrong CI configuration costs a day, and a wrong fact grain costs a rebuild of every report beneath it.
The eight, with the artefact each must produce
#
Week · length
Subject
Artefact — merged, or it did not happen
1
2 · 90 min
The layer contract
the contract table, filled in by them, committed to the repo
2
3 · 120 min
Grain and the star
gold.fct_order_line DDL with a grain COMMENT, merged
3
4 · 120 min
Keys and SCD2
the boundary table, plus two-changes-in-one-day written as a test
4
5 · 90 min
Ingestion decision table
all four sources placed, each with a written reason
5
6 · 90 min
Testing I — the pure function
one transform extracted to src/dwh/pipelines/transforms/silver_sales_order.py, with a test
6
7 · 90 min
Testing II — SQL assertions, then CI
three .sql assertions from RULES 1–7, running in the bundle test target
7
8 · 90 min
Governed tags, ABAC, PII
gold.dim_customer.email tagged; a column mask proven from two accounts
8
9 · 90 min
Runbooks and the re-run question
one runbook per pipeline, written by whoever gets woken
Workshop 7 used to spend its first half on preview caveats and a documented fallback. It no longer needs to: ABAC row filter and column mask policies, governed tags and automated data classification are all generally available, so the ninety minutes are entirely hands on gold.dim_customer. Every session runs the same six-segment sheet, and the segment that gets cut when you run late is the one that must not be:
textRun sheet — workshop 2, the exemplar for all eight
WORKSHOP 2 — Grain and the star week 3 · 120 min · max 6 people
PREREQ everyone has run 'databricks bundle validate' and can query dwh_dev.silver
ARTEFACT gold.fct_order_line DDL merged to main, with a grain COMMENT
00:00 frame One sentence on the whiteboard: "one row per order line."
Nothing else may be written until everyone agrees it.
00:10 hands Team draws the star. Consultant holds the pen for zero minutes.
00:40 break it "Sales wants revenue per delivery, not per order line."
New fact, or does that change this grain?
01:10 build Write the DDL together. CLUSTER BY (customer_sk, order_ts).
01:40 commit PR opened by a team member, reviewed by a second team member.
Consultant comments; consultant does not approve.
02:00 close Each person names the one thing they would still get wrong.
The other seven sheets are this one with two substitutions: the artefact from the table above, and the provocation that drives break it. Those are the only two parts worth preparing — the six clock positions never change, which is why nobody has to think about the format. The provocations, in workshop order:
Layer contract — 'a dashboard needs a column that only exists in bronze. Where does it go, and what does the contract say?'
Grain and the star — 'Sales wants revenue per delivery, not per order line.'
Keys and SCD2 — 'the same customer changes customer_segment twice on one day. How many versions, and what are the interval bounds?'
Ingestion — 'bronze.sap_kna1 arrives with no change timestamp. How do you know which customers changed?'
Testing I — 'the transform needs today's date. Where does the clock come from, and how do you test yesterday?'
Testing II — 'your assertion returns zero rows against an empty table. Did it pass, or did it not run?'
Governed tags and ABAC — 'the analyst is excluded by the column mask. Can they still CLONE the table or TIME TRAVEL past it?'
Runbooks — 'the load failed at 02:00 and nobody knows why. Is it safe to re-run blind?'
Why here
A workshop that ends in a slide is entertainment. The named failure is a team fluent in bronze/silver/gold that cannot say what one row of gold.fct_order_line is — discovered in month four, when the first aggregate double-counts and nobody can explain it.
The break it segment exists because the happy path teaches nothing durable. Ten minutes watching their own design fail a plausible business question beats an hour of correct explanation, and it is the part that survives into production instincts.
Doing it
Publish all eight dates and artefacts before week 2, so the calendar is defensible when delivery pressure arrives.
Check the prerequisite the day before. A room where half the people cannot connect loses forty minutes and its credibility.
Cap attendance at six. The seventh person turns a workshop into a presentation.
Keep your hands off the keyboard during the hands and build segments, without exception.
Embedding it
Hand facilitation over from workshop 5 — a team member runs the run sheet, you take notes and speak twice.
Have each artefact reviewed by someone who was not in the room. That tests understanding rather than a shared mood.
At week 10, ask which workshop should be repeated. The one they name did not land, and repeating it is cheap.
Let them write workshop 8's runbooks badly, then run an incident against what they wrote.
Defaults
Weekly cadence, never a two-day bootcamp. Hands need a week between them.
Ninety minutes default, 120 for modelling, six people, one merged artefact each.
The same six-segment run sheet every time, so nobody spends attention on the format.
Four sessions on architecture and modelling — protect that proportion when the schedule is squeezed.
Gotchas
The two-day kickoff bootcamp. Retention is near zero because nothing is applied between sessions; you re-teach SCD2 in week 7 and the client concludes their team is slow.
Workshops that drift into demos. The tell is the consultant being the only person typing for more than ten minutes. Say it out loud and hand over the keyboard.
Cutting break-it to finish on time. They then learn only the happy path and meet the edge case in production, at the worst hour, without you.
Inviting the department for visibility. Above six people nobody types, it becomes a status update, and the artefact is not built.
Teaching workshop 7 as a preview briefing. Governed tags, ABAC policies and classification went GA in May 2026; the old fallback wastes the session and installs a workaround the team keeps for years.
Workshops move understanding once a week. Skill moves in the loop that runs every day: who holds the keyboard, what a review comment says, and forty-five protected minutes where nothing has to ship.
Pairing has the highest bandwidth of any format here and is the easiest to fake, so it needs a protocol rather than good intentions.
Ninety minutes, in the calendar, one named outcome. Opportunistic pairing evaporates the week things get busy — which is the week it matters.
The team member drives. Always. To show something you take the keyboard for under two minutes and hand it back with the change unmerged.
Narrate intent, not keystrokes: 'we have to close the open interval before inserting the new version', never 'line 40, change the mode'.
When the driver is stuck, count to twenty before speaking. Usually you never reach twenty.
The driver writes the commit message unaided. If they cannot describe what changed, the session is not finished.
Next session, verify: same driver, same class of change, you out of the room, and you read the PR afterwards.
Pair with everyone inside three weeks, then concentrate on the two who will own gold. Pair on src/dwh/common/scd2.py and gold.fct_order_line — the code they must change first and understand least — not on gold.dim_date, which pairs pleasantly and teaches nothing.
Why here
The failure is a week reported as knowledge transfer that shows up in git shortlog -sn with your name on every commit. A passenger learns what a passenger learns: they recognise the route and cannot navigate it.
It matters most on the SCD2 code, because that is where the business rules live. RULE 4 says a customer_segment change creates a version and an address change does not — one sentence separating a dimension that answers historical questions from one that quietly lies about them.
Doing it
Book the sessions for the whole engagement on day one; never week to week.
Check whose name is on the commits. git shortlog -sn --since='4 weeks ago' takes five seconds and is not flattering.
Pair on the on-call path — the MERGE, the retry logic, the currency conversion.
After each session write the one thing the driver could not do alone. That list is your coaching backlog, and later your handover risk register.
Embedding it
From week 6, pair two team members with each other while you sit silent and speak only if both are stuck.
Ask the driver to teach the same thing to a colleague within the week. Teaching is the only honest test.
When the driver asks what to type, answer with a question about intent. Uncomfortable for two sessions, then they stop asking.
Let a session end with the change not working. Rescuing it teaches them that you rescue things.
Defaults
Ninety minutes, booked, one outcome, the team member always driving.
Under two minutes of consultant keyboard time, and the demonstration is discarded rather than merged.
Rotate through everyone early, then concentrate on the future owners.
Pair on the code that wakes people up, not the code that demos well.
Gotchas
Consultant-drives pairing. Faster in the session, and it appears in the git log as your authorship during a week invoiced as enablement — exactly what a client checks when they later ask what they got.
Pairing all day. Both people degrade after ninety minutes, and the afternoon session teaches the driver that pairing is exhausting, so they stop asking for it.
Pairing only with the strongest engineer because it goes fastest. The person who needed it does not get it, and they are frequently the one still there in three years.
Never pairing on the on-call path. You pair on the code you enjoy; the code that fails at 3am is the MERGE and the retry, and it stays untransferred.
Review is where coaching happens forty times a week, and it is the only coaching that is written down, searchable, and available at 3am to someone you never met. Each comment is a correction or a lesson, and the difference is mechanical.
The same five situations, twice
Bad
Why it fails
Good
Use liquid clustering here.
gives the answer, teaches nothing, and they ask again for the next table
This is PARTITIONED BY (year, month, day) — what does DESCRIBE DETAIL say about numFiles? Compare with gold.fct_order_line and tell me which you would rather query.
This is wrong.
no failure mode, no reproduction; invites defence instead of thought
This MERGE fails with 'multiple source rows matched' the first time bronze.sap_vbap sends two changes for one line in a batch. Run it against the two-changes-same-day fixture.
nit: naming
vague, and costs a full round trip to resolve
customer_key should be customer_sk — the prefix table in the architecture route. One line, then this is mergeable.
LGTM (on a 400-line PR)
approves what nobody read; teaches the team that approval is free
I read the SCD2 close and the tests. I did not read the FX join — @maria, can you take that half?
I've pushed a fix to your branch.
removes the learning and the authorship; the author finds out at merge
amount_eur is rounded before the FX multiply, so RULE 2 does not hold for CHF orders. Pair for twenty minutes, or shall I point you at the assertion that would have caught it?
One further rule does more than the rest combined: at most one question per review that requires thinking, plus as many mechanical notes as you like, each prefixed nit:. Give someone three hard questions and they answer the easy two and negotiate the third.
Why here
The failure is a review culture rigorous about naming and silent about correctness. It feels disciplined. It passes a 400-line PR in which amount_eur is rounded before the fx_rate multiply rather than after it — RULE 2 read backwards. Every CHF line is then wrong by a rounding step: too small to catch by eye in a spot check, systematic enough that the quarter's revenue disagrees with SAP, and nobody can say by how much or since when.
Citing the rule by number rather than citing yourself is what makes the standard outlive you. RULES 1–7 are in the repository; your authority leaves at handover.
Doing it
Cite the rule number and link the test that would have caught it, instead of describing the fix.
Never push to someone else's branch. There is no version of this that is worth it.
State what you read and what you did not, and name who should read the rest.
Ask for the missing test rather than the fix. The bug comes back; the test does not.
Embedding it
From week 4, require two team reviewers and make yourself optional — you comment, you do not approve.
Once a week review a review: take a merged PR and ask what that comment taught, not whether it was right.
The first time someone leaves your kind of comment on a colleague's PR without you in the thread, the transfer is real. Say so.
Have them write the review checklist themselves from the routes they were taught. One you hand over is read once.
Defaults
One thinking-question per review; everything mechanical prefixed nit: so the author can triage.
Comments cite RULES 1–7, the layer contract or a route — never seniority.
Reviews end in a test, not in a fix.
Two team reviewers by week 4; the consultant is a required approver on nothing.
Gotchas
The consultant as required reviewer everywhere. It looks like quality control and behaves like a queue: merge latency climbs, the team routes around you by splitting PRs into 'small' ones, and the risky change waits longest.
Style-only reviews. They block a variable name and pass a wrong join, and the team correctly concludes review is theatre and starts approving each other unread.
Pushing fixes to the author's branch. They never see the failure, git blame now points at someone who leaves in eight weeks, and the next person has nobody to ask.
Teaching in a direct message. The lesson reaches one person and disappears. Put it in the PR thread, where the person who hits it in March can find it.
Forty-five minutes, same slot every week, on the warehouse's own model, producing nothing that ships. A kata is deliberately not delivery: the moment one result gets merged it becomes a task, and tasks get rescheduled around delivery until they stop happening.
Write the grain sentence for gold.agg_revenue_month, then find the two ways it can double-count. (RULE 1)
Write the SCD2 close-and-insert MERGE on silver.customer for a changed customer_segment — and prove an address change on the same row creates no version. (RULE 4)
Break RULE 2 deliberately: compute amount_eur before joining silver.fx_rate. Find the assertion that catches it; if none does, write it.
Declare the primary key on gold.dim_customer, then insert a duplicate customer_sk. Watch it succeed. Now write the assertion that would have failed.
Land an order line whose customer_id is not yet in gold.dim_customer on customer_sk = 'UNKNOWN' instead of letting the join drop it. (RULE 7)
Two changes to one order line in a single bronze.sap_vbap batch. Make the MERGE fail with the real error, then make it pass without losing a change.
Query system.billing.usage for last week by tag and explain the largest line in one sentence.
Cold modelling on samples.nyctaxi.trips — one of the few places this handbook deliberately leaves the canonical model, and it says so, because this exercise needs a table nobody in the room has modelled before. Grain sentence and star, twenty minutes.
Why here
Under delivery pressure a team becomes very good at the four transforms it built and learns nothing about the fifth. SCD2 edge cases appear in production perhaps twice a year, which is precisely why nobody can handle them when they do, and why the incident takes a day instead of an hour.
Katas also give the seven business rules a second life. A rule enforced in an expectation, asserted in SQL, measured in the metric view and practised on a Thursday morning is a rule the team can state from memory — the only version that gets applied to code you never reviewed.
Doing it
Book the recurring 45-minute slot for the whole engagement on day one, owned by someone who is not you.
Throw the code away at the end. Every time.
Keep the list of katas nobody finished. That list is next month's workshop.
Retire a kata once two people solve it cold; keep the one that still hurts.
Embedding it
Hand kata selection to the team from week 5 and accept the ones you would not have picked.
Have whoever solved it fastest explain it, while you say nothing.
Run one kata blind — you are not in the room — and read the result later without commenting on style.
Ask them to invent a kata from a bug they shipped: the cheapest post-mortem there is.
Defaults
Forty-five minutes, weekly, thrown away, on the canonical model.
One rule from RULES 1–7 per kata, so practice and production enforce the same seven sentences.
Difficulty from the edge case, never from data volume.
The last ten minutes of discussion is the exercise; the code was the pretext.
Gotchas
Cancelled 'just this sprint'. It never returns. The recurring booking with a non-consultant owner exists to survive the sprint where it is inconvenient.
Katas that turn into work. Once one result is merged, the next gets scheduled around delivery and the format is dead within a month.
Toy data. A two-row fixture teaches syntax and hides every timing problem; you discover in production that nobody has seen an overlapping SCD2 interval.
Only running katas the team already passes. It feels good and transfers nothing. If everyone finishes in twenty minutes, retire it that day.
Resistance, and what to stop doing
Six objections arrive in every warehouse engagement, usually in this order; the answers you improvise are the ones that sound like sales. Then subtract — enablement is mostly removing work, and every row below got there for a reason that made sense at the time.
The kill list — take it to the sponsor with a name against each row
Stop
Why it started
Do instead
Weekly status decks
someone asked for visibility once
the declining-contribution query and the PR count, five lines in a channel
Consultant on the alert rota past week 9
you are faster at 3am
team on the rota, you on standby a fortnight, then off
%run notebook chains
it worked in the prototype
workspace files and imports — %run hides the dependency graph and cannot be unit-tested
Scheduled OPTIMIZE on UC managed tables
necessary before predictive optimization existed
check whether predictive optimization is already on for this account first — if it is, the scheduled job pays a second time to compact files that were already compacted, and the two writers start losing to each other on concurrent-modification conflicts
A shared team mailbox for alerts
it felt like coverage
a named rota — a mailbox is where alerts go to be unread
Consultant as required PR approver
quality
two team reviewers; you comment without approving
Copying production data into dev
debugging
seeded fixtures in dwh_test.fixtures — a production copy in dev is a GDPR event with a ticket number
Documentation in the consultant's deck
it is what got sold
repository pages the team edits; anything only you can change dies at handover
Concede the true part first — every one of these has one
Objection
Response
You want to rewrite our working code.
No — I want to pin what it does today, then change it without changing that. Characterization test first, refactor second.
We don't have time to write tests.
You already write them: you eyeball the output in a notebook after every run. Same cost, except mine runs again next month. One assertion per bug from here; nothing retroactive.
Our data is too complex for a star schema.
Possibly. Take the three hardest questions the business asked last quarter and model only those — two hours. Usually the complexity is in the source, not the model; if it is not, we have learned something real.
Databricks does that automatically now.
Often true, and worth checking rather than arguing: predictive optimization runs OPTIMIZE, VACUUM and ANALYZE on Unity Catalog managed tables, on by default for accounts created on or after 11.11.2024. It does not decide your grain or notice that revenue is wrong.
The previous consultant said the opposite.
What problem was that solving, and does it still exist? Partitioning advice was right before liquid clustering; Databricks now recommends clustering over Z-ordering for new tables, and the two cannot be combined.
We'll do it properly later.
Name the date and price it. Retrofitting catalog-per-environment after go-live moves every table, reissues every grant, re-points every report, and has no partial rollout. 'Later' with a number attached stops being free.
The first objection decides whether the engagement works, and it is answered with code rather than reassurance. A characterization test pins current behaviour before anything is touched, so the refactor is provable instead of trusted:
"""Pins TODAY's behaviour of the existing customer load.
Asserts nothing about correctness -- only that the refactor changes nothing
the business can see. Delete it once the refactor is merged and reviewed.
"""
from pyspark.testing import assertDataFrameEqual
from dwh.silver.customer import clean_customer
def test_clean_customer_matches_pinned_output(spark):
source = spark.read.table("dwh_test.fixtures.sap_kna1_2026_07_01")
pinned = spark.read.table("dwh_test.fixtures.silver_customer_pinned")
actual = clean_customer(source).drop("_tech_loaded_at")
assertDataFrameEqual(
actual,
pinned.drop("_tech_loaded_at"),
checkRowOrder=False,
)
Write it with them, on their most feared module. The objection is not about code quality — it is about being blamed for breaking something that currently works. The test moves the blame onto an assertion, which is where it belongs.
Why here
Improvised answers sound like sales, and a team that suspects it is being sold to stops arguing and starts complying. In a meeting compliance is indistinguishable from agreement; in the code six weeks later it is not.
Two of the six cite the platform, which is what the currency register is for. Contradicting a client who is right about Databricks — and it moves fast enough that they sometimes are — costs more credibility than any single technical point is worth.
Doing it
Write the six responses down before week one. You will be asked all six, usually in this order.
Answer with a demonstration on a named date, not with an argument in the room.
Concede the true part out loud, first, every time.
Never a flat no: three options with their costs, per the requirements route.
Check the currency register before contradicting any claim about what the platform now does by itself.
Embedding it
Once you have answered an objection twice, have a team member answer it in front of their own stakeholders. If they cannot, they were being polite rather than convinced.
When a team member repeats an objection you already answered, treat it as evidence the answer was a speech, and redo it as a demonstration.
Ask which objection their sponsor will raise, and prepare them for it rather than yourself.
Let them win one of these arguments against you in public. A team that has never disagreed with you is not thinking.
Defaults
Six prepared answers, each conceding something true.
Schedule the demonstration rather than winning the meeting.
Platform claims get checked against the currency register before they get contradicted.
A characterization test before any refactor of code that currently runs in production.
Gotchas
Winning the argument. They concede in the meeting and revert in the code, and you find out at handover. The tell is agreement with no follow-up question.
Treating 'no time for tests' as a values problem. It is a schedule problem and it is usually accurate. Answer with scope — one assertion per bug — not with principle.
Dismissing the previous consultant. The team hears a verdict on their last two years, and it guarantees the next consultant dismisses you.
Flatly denying that Databricks now handles something. Half of these claims are true and more become true each quarter; being wrong about one costs you the other five arguments.
Answering the rewrite objection with reassurance instead of a test. Reassurance expires the first time a refactor breaks a report, and nothing you propose afterwards gets adopted.
The generic platform material lives in the official docs and is not restated here. These are the pages worth having open while you work through this route.