Knowledge Sharing and Team Enablement Questions

Direct answer

I would build the hour around what colleagues will actually have to do at 2am: understand the flow at a high level, recognise the common failure signals, and fix them with their own hands. Roughly 25 minutes of orientation and explanation (segments 1 to 3 below: 5 + 10 + 10), 25 minutes of drills, and 10 minutes to point at where things live and wrap up. I would confirm it worked afterwards by making them handle a realistic fault without me.

Agenda (60 minutes)

Total: 5 + 10 + 10 + 25 + 5 + 5 = 60.

Making it hands-on

• Drill 1: I inject a fault (a malformed record that blocks a stage) into a test copy. Participants, in pairs, find it using the dashboards and logs, following the runbook.
• Drill 2: a consumer falls behind. They decide whether to scale, restart or replay, and explain the risk of each. Replay means reprocessing older data from a saved position. Typical risks the group should surface: scaling adds capacity but does not fix a consumer that is slow for a reason (a bad record, a slow dependency); restarting can lose in-flight work or repeat records; replaying can create duplicates downstream and adds load while the pipeline is already behind.
• I stay quiet, answer questions with questions, and fix the runbook wherever they got stuck.

Finding out afterwards that they can troubleshoot

• Within two weeks, a fresh drill without me present: they get an alert scenario and a time box, and I only observe the notes.
• Shadow then reverse-shadow: normally a newcomer shadows the expert. Here it is reversed: on the next on-call, they lead and I shadow, stepping in only if needed.
• Track: could they reach the first correct action without asking me, did they find the runbook, and which steps needed edits.
• Ask each person to describe the rollback aloud. If they cannot, the session failed for them.

Trade-offs and pitfalls

• Do not try to cover everything; it is a support skill session, not a full architecture course.
• Attendance and a "did you understand?" question are not evidence. Only unassisted performance is.
• Record the session, but do not treat the recording as the transfer.
• Flip condition: if the pipeline is too risky to drill even in a test copy, use a written tabletop scenario (the group talks through an invented incident step by step on paper, with no live system) and a supervised first real incident.

Direct answer

Attendance says people showed up, not that anything improved. I would measure at four levels (the Kirkpatrick model: reaction, learning, behaviour, results), choose three or four metrics with a precise numerator, denominator and window, collect them from systems that already exist, and handle attribution by using a comparison group and describing contribution, not claiming sole credit.

Metrics beyond attendance

Timetable

• Before training: the "before" attempt at the standard task, which is the baseline for the Learning row.
• 2 weeks: reaction survey.
• 30 days: behaviour, and the repeat of the same learning task (the "after" attempt in the Learning row).
• 90 days: results.
• 6 months: is it durable, or did behaviour decay?

Attribution

• Confounders are other things that changed at the same time and could explain the result: a new tool shipped the same month, or seasonality (a regular calendar pattern, such as fewer questions during holiday months).
• Use a staggered rollout: train team A first, team B later, and compare changes (a simple difference-in-differences: subtract the change in the untrained group from the change in the trained group, so shared effects like seasonality cancel out).
• Use trend before the programme, not one snapshot.
• Add qualitative evidence: short interviews asking "what did you do differently, and why?"
• Say honestly that noisy metrics like MTTR cannot show an effect when there are only a handful of incidents per quarter.

Worked example (hypothetical)

Training on deployment practices. Both teams are measured over the same two calendar months: the month before Team A's training and the month after it, while Team B is still untrained. Repeat "how do I deploy" questions per month: Team A (trained month 1) goes from 30 to 18, a 40 percent fall. Team B (trained later) goes from 28 to 27, about 3.6 percent. Team B's small drop (minus 1) is what happened with no training, such as drift or seasonality. The difference between the two changes is minus 12 versus minus 1, so roughly 11 fewer questions a month plausibly comes from the training, not from general drift.

Trade-offs and pitfalls

• Goodhart's law (when a measure becomes a target, it stops being a good measure): if you reward fewer tickets, people stop filing them. Pair each count with a quality check (satisfaction, time to resolve).
• Pick a small set; ten metrics create noise and let everyone cherry-pick (quote only the numbers that flatter the programme).
• Do not wait six months to learn the programme is off track; the 2-week and 30-day checks exist for that.
• Self-reported confidence is weak evidence on its own; combine with observed behaviour.

Direct answer

I pick a topic that solves a problem the team feels now, plan a session that is mostly doing rather than telling, give a short pre-task so everyone arrives with the same footing, and follow up within a week with a recording, notes and a small real task. A 30 to 45 minute slot fits roughly one idea, not a survey.

Choosing the topic

• Start from evidence: recurring questions in chat, causes in recent incident reviews (written retrospectives on things that broke), an upcoming project, or a gap in the team's skills.
• Test it: "If they learn only this, what will they do differently next week?" If there is no answer, pick another topic.
• Choose something that matters to the company (for example, a slow pipeline that delays releases), not just something interesting to me.

Planning a 45-minute session

Demo versus slides: use one or two slides for the picture, the demo for everything else. Slides are for the concept, demos are for how it feels.

Preparing people beforehand

• Send a 10-minute pre-read or short video 2 days before.
• Ask everyone to complete one setup step (clone a repo, get access) and verify it works, since setup problems otherwise eat the hands-on time.
• Ask for one question they want answered.

Following up

• Post the recording, the notes and the exercise solution.
• Give a small real task within a week and check in two weeks later to see who used it.
• Ask two questions: what was unclear, what have you used?

Worked example: teaching a CI/CD topic remotely

CI/CD is continuous integration and continuous delivery, the automated pipeline that builds, tests and ships code. Topic: pipeline caching (saving files such as downloaded libraries between runs, so each build reuses them instead of fetching them again), chosen because slow builds delay releases. 8 backend engineers, all remote. Pre-work: a 6-minute video and a check that everyone can clone (download a working copy of) and push to a sandbox repository (a practice code repository nobody depends on, safe to break). In the session: I demo adding a cache step, then engineers work in breakout pairs (small private video rooms of two) on the same sandbox pipeline and compare the build timings shown in the pipeline run, each writing the result in the shared chat. Illustrative numbers: the run before the cache step takes about 8 minutes, and a later run takes about 3 minutes because libraries are reused (each pair runs the pipeline twice after adding the cache step: the first run fills the cache, the second run reuses it). A pair that sees no improvement checks that the cache actually saved something on the first run, since the first run after adding a cache is normally no faster (it is a cache miss and also spends time saving the cache), so the comparison is between the first and second run. One week later each engineer applies it to a real service repo. Remote specifics: cameras optional, chat for questions, a pre-provisioned sandbox so nobody waits.

Trade-offs and pitfalls

• Too much content: two ideas at most.
• Setup unverified: the hands-on block collapses.
• No follow-up: the session felt good and changed nothing.

Direct answer

Make learning bounded, deliberate and tied to decisions: a small, fixed slice of time, a shared view of which technologies matter, and time-boxed experiments that end in a written decision. The distraction comes from unbounded curiosity, so I would put limits on how much is explored at once and require every exploration to answer a question the team actually faces.

Structured elaboration

1. A fixed, small budget of time. For example half a day each fortnight per person (stated openly, and protected in planning), so learning never competes ad hoc with delivery.

2. A technology radar. A shared list that places each tool in one of four rings: adopt (proven, use it by default), trial (use it on one real, low-risk project to learn), assess (worth a short look, not yet used for real work), hold (do not start anything new with it, for example because it is being retired or has caused problems; Thoughtworks' public Technology Radar, which popularised these rings, now labels its fourth ring "Caution", and many teams keep "hold" for their own radar). It gives the team a common answer to "should we look at this?" and stops repeated debates.

3. Time-boxed spikes. A spike is a short experiment to answer one question. Rules: a named question, a time limit (say two days), a limited number of active spikes (a work-in-progress limit: for example at most two spikes running at once, and a new one starts only when one finishes), and a short written outcome (adopt, trial, drop, with reasons).

4. Rotating scout. One person per quarter tracks the landscape and reports back, so all eight people are not scanning news.

5. Just-in-time versus just-in-case. Learn deeply what you will use in the next quarter or two. Keep the rest at awareness level from the scout's summary. Example: if the team migrates to a new database next quarter, learn that database properly now (just-in-time); a new front-end framework nobody plans to use only needs a paragraph in the scout's summary (just-in-case learning means learning something ahead of any concrete need, in case it is wanted later; it is kept to awareness level and deep study waits until a real need appears).

6. Share once. A short demo or note to the team, so one person's spike benefits all of them.

Worked example

Team of 8, half a day (4 hours) per person every fortnight. A fortnight is 10 working days = 80 hours, so learning is 4/80 = 5% of each person's time, or 8 x 4 = 32 team hours per fortnight. Say a new deployment tool appears. The scout adds it to the radar under "assess". Two people run a two-day spike against one real service, and the note says: works, but migration effort is high, so "trial" only on the next new service. No one else's roadmap moved. Check the budget: two people x two days x 8 hours = 32 hours, which is exactly the whole team's pool for one fortnight (8 x 4 = 32), so the spike is funded by pooling the team's slice for that fortnight, and only one such spike fits per fortnight, which is another reason to cap active spikes.

Trade-offs & pitfalls

• Resume-driven adoption: adopting tools because they are new or look good on a CV, not because the team needs them. Require the spike to name the problem it solves.
• Learning time that vanishes under deadline pressure. If it disappears at the first crunch, it was never protected. Track whether it is actually taken.
• Everyone learning everything wastes effort. Specialise deliberately.
• Too many experiments running together cause the distraction you are trying to avoid. Limit them.
• If delivery is already at risk, temporarily reduce the slice openly rather than pretending it continues.

Direct answer

Start small and specific: recruit five to eight people who have already asked for something like this, agree one concrete purpose (for example "get better at pipeline tuning"), and put a fixed 60-minute slot in the calendar. It stays alive after the first few enthusiastic months only if the group has rotating roles, a light accountability loop that turns discussion into small actions, a sponsor (a manager or senior person who backs the group and protects its time), and a scheduled point where the group may end itself.

Structured elaboration

• Recruitment: invite, do not mandate. Pitch an outcome ("read one paper or post a month, leave with one thing to try"), start with people who already ask these questions, keep the door open.
• Reading selection: candidates are proposed in a shared list, capped at one item of under 30 minutes of preparation, chosen by a quick vote. A too-long reading list is the classic first failure.
• Roles and timeboxes for a 60-minute session:

The facilitator, presenter and scribe rotate every session, so no one carries it.

• Accountability: each action has an owner and a date, and is reviewed first thing next session. Publish a five-line summary to a shared page.
• Capturing decisions: a running log of decisions and actions, so the group can point at what it changed.
• Sustaining: a quarterly keep/change/stop review, plus an explicit sunset rule (a pre-agreed condition for pausing or ending the group, for example "if attendance falls below four for two sessions, pause and re-scope").

Worked example

A quarterly peer-learning programme for data engineers, 8 people, one session a month:

• Month 1, tool tips: each person shows one tool trick they use.
• Month 2, tuning: the group reads one write-up on query or pipeline tuning and each applies one idea to their own pipeline.
• Month 3, incident lessons: one blameless review of a real incident (blameless means the discussion is about how the system allowed the failure, not who caused it).

An illustrative action-log row: "Try partition pruning on the orders load | Owner: Priya | Due: next session". (Partition pruning means splitting a big table by, say, date so a query reads only the slices it needs, which can make a slow load faster.) The first agenda item next month is whether it worked and what changed.

Trade-offs and pitfalls

• Discussion with no actions feels pleasant and fades. The action log is what gives the group a visible return.
• Mandating attendance produces silent rooms. Sponsors should protect time and ask for outcomes, not headcount.
• One heavy-lifting organiser is a single point of failure (if that person leaves or gets busy, the whole group stops), so rotate roles from the start.
• Reading groups drift toward whatever the loudest member likes. A voted list and rotating presenter counter this.
• What would change my call: for a group larger than about ten, split into two groups rather than lengthening the session.