Crosshire
← Enablement & coaching
Engagement21 Enablement & coaching · 2 of 3

The weekly rhythm

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.

Stand 29.07.2026

#The pairing protocol

What
Pairing has the highest bandwidth of any format here and is the easiest to fake, so it needs a protocol rather than good intentions.
  1. Ninety minutes, in the calendar, one named outcome. Opportunistic pairing evaporates the week things get busy — which is the week it matters.
  2. The team member drives. Always. To show something you take the keyboard for under two minutes and hand it back with the change unmerged.
  3. Narrate intent, not keystrokes: 'we have to close the open interval before inserting the new version', never 'line 40, change the mode'.
  4. When the driver is stuck, count to twenty before speaking. Usually you never reach twenty.
  5. The driver writes the commit message unaided. If they cannot describe what changed, the session is not finished.
  6. 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
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 commitsgit 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 aloneThat list is your coaching backlog, and later your handover risk register.
Embedding it
  • From week 6, pair two team members with each otherYou sit silent and speak only if both are stuck.
  • Ask the driver to teach the same thing to a colleague within the weekTeaching is the only honest test.
  • When the driver asks what to type, answer with a question about intentUncomfortable for two sessions, then they stop asking.
  • Let a session end with the change not workingRescuing 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 pairingFaster 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 dayBoth 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 fastestThe 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 pathYou pair on the code you enjoy; the code that fails at 3am is the MERGE and the retry, and it stays untransferred.

#What a review comment says

What
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
BadWhy it failsGood
Use liquid clustering here.gives the answer, teaches nothing, and they ask again for the next tableThis 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 thoughtThis 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: namingvague, and costs a full round trip to resolvecustomer_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 freeI 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 mergeamount_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
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 branchThere 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 fixThe bug comes back; the test does not.
Embedding it
  • From week 4, require two team reviewers and make yourself optionalYou comment; you do not approve.
  • Once a week, review a reviewTake a merged PR and ask what that comment taught, not whether it was right.
  • Watch for your kind of comment appearing on a colleague's PR without you in the threadThe first time it happens, the transfer is real. Say so.
  • Have them write the review checklist themselves from the routes they were taughtOne 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 everywhereIt 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 that block a variable name and pass a wrong joinThe team correctly concludes review is theatre and starts approving each other unread.
  • Pushing fixes to the author's branchThey 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 messageThe lesson reaches one person and disappears. Put it in the PR thread, where the person who hits it in March can find it.

#Weekly katas on the canonical model

What
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.
  1. Write the grain sentence for gold.agg_revenue_month, then find the two ways it can double-count. (RULE 1)
  2. 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)
  3. Break RULE 2 deliberately: compute amount_eur before joining silver.fx_rate. Find the assertion that catches it; if none does, write it.
  4. 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.
  5. 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)
  6. 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.
  7. Query system.billing.usage for last week by tag and explain the largest line in one sentence.
  8. 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
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 finishedThat 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 workOnce one result is merged, the next gets scheduled around delivery and the format is dead within a month.
  • Toy dataA 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 passesIt feels good and transfers nothing. If everyone finishes in twenty minutes, retire it that day.