Knowledge Sharing and Team Enablement Questions

Direct answer

I would run office hours (a recurring slot where anyone can drop in with questions) as a lightweight service: a small number of fixed slots that cover the time zones, a simple intake form so questions can be triaged, a shared log of questions and outcomes, and a habit of turning repeated questions into docs. I would judge success by whether people get unblocked faster and whether the same questions stop coming back.

Setup

• Slots and time zones. Two recurring slots: one in the overlap of Europe and the Americas, one for Asia-Pacific, each 45 minutes, with different hosts. For teams too spread out, add an asynchronous channel where questions are answered within a stated window (for example, one business day).
• Drop-in versus appointment. Drop-in by default, since most questions are short. Offer a bookable 25-minute slot for deep problems such as reviewing a data model or a reliability design.
• Triage. A short form asks: what are you trying to do, what have you tried, how urgent. Urgent production issues go to the on-call path, not office hours.
• Hosts. Rotate among team members so knowledge spreads and nobody is a permanent help desk.
• Advertising and the first sessions. Announce in team channels and at onboarding, and seed the first sessions with a known pain (invite a team with a real question) so it does not open to an empty room.
• Capture. Log each question: date, topic, who, outcome, and whether a doc exists.

How I would know it helps

• Repeat rate: the share of questions on topics already answered before.
• Docs created from questions, and whether questions on a documented topic fall afterwards.
• Time to unblock, reported by attendees in one line.
• Attendance mix (new people, several teams) and a short satisfaction check.

Worked example (illustrative log)

Over 3 weeks the log has 30 questions. One topic, "how to request a new data pipeline environment", accounts for 9. That is 9/30 = 30%. I write a one-page guide and link it in the intake form. In week 4, that topic is 2 of 14 questions, about 14%, and people who asked it say the guide answered it. The metric shows that the office hours found the gap and the doc closed it. If the share had not fallen, the guide is unclear or not discoverable.

Trade-offs and pitfalls

• Office hours can become a substitute for documentation. The goal is to shrink repeated questions.
• Low attendance may mean poor advertising, the wrong time, or that people are already served, so ask before cancelling.
• Do not use raw attendance as the success measure, since a good doc reduces attendance.

Direct answer

Build a competency framework (a shared description of the skills people need at each level) as a grid of levels by skill areas, with observable behaviours in every cell. Assess with evidence (work samples and peer input) calibrated across managers, and use it in two ways: a development plan from the gaps, and promotion as sustained evidence at the next level, not a checklist tick.

Structured elaboration

1. Levels and skill areas. Use four or five levels (for example Associate, Engineer, Senior, Staff) and four skill areas: technical craft, delivery, collaboration and communication, and ownership and impact. Describe each level by scope and autonomy (what size of problem, how much guidance) rather than years of experience.

2. Assessment. Use several sources: manager view, peer input, and work samples (assessment tasks). A sample task with pass criteria: "Review this design for a service and identify risks." Pass means at least three of four criteria are met (finds the data-loss risk, proposes a mitigation, states a trade-off, prioritises). Hold calibration sessions where managers compare evidence for the same level so standards match. Example: Priya reviews the design and finds the data-loss risk, proposes a mitigation and states a trade-off, but does not prioritise the risks: 3 of 4, pass. Two managers disagree on her collaboration rating, one says "meets" and one "exceeds". In calibration each cites evidence (she reviewed four designs this half and unblocked two teammates) and they check it against the Senior column of the table, which needs "reviews designs and unblocks others" sustained. The group agrees "meets Engineer, growing toward Senior", and records the evidence, not just the rating.

3. Lightweight certification. For specific skills (for example "on-call ready") a short practical check that grants an internal badge. Keep it small so it does not become a second bureaucracy.

4. Feeding growth. Each person sees their gaps against the next level and agrees two or three development actions per half-year (stretch project, mentor, course). Promotion requires consistent evidence at the next level over roughly two review cycles, reviewed by a committee for consistency.

Worked example

Behavioural angle (STAR: situation, task, action, result): my team of about 20 had inconsistent promotion outcomes and no common definition of "senior". I drafted levels from real promotion write-ups, tested them with three managers on five real people, changed the two rubrics they could not apply the same way, then ran calibration each half-year. The result was qualitative: managers could explain a decision by pointing to evidence, and people could see what to work on.

What a rubric change looked like (illustrative): the first draft said "Senior demonstrates strong technical leadership", and three managers rated the same person differently. We rewrote it as "Senior leads the design of a component used by at least two other teams and gets it reviewed before building", which two managers could now check against a real design document. Before the rewrite the three managers agreed on 1 of 5 people; after it, on 4 of 5 in the next test (illustrative). Situation: inconsistent promotions. Task: create a shared definition. Action: draft, test, rewrite. Result: evidence-based decisions.

Trade-offs & pitfalls

• Checklist promotion: people collect boxes. Judge sustained scope and impact.
• Too granular frameworks (dozens of skills) are never used. Keep it short.
• Bias: unequal access to visible projects skews evidence. Calibrate and check outcomes across groups.
• Never finished: revisit yearly as the work changes.

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

A strong answer is one specific story: a problem the team had, one session or programme you set up, the tactics that got people to take part, and evidence that something changed. The story below is an illustrative skeleton; use a real one of your own with real details and honest numbers.

Story skeleton (STAR: Situation, Task, Action, Result)

Situation. On a backend team of eight, every database incident was escalated to one senior engineer. Three teammates told me they had never done a failover (switching to the standby database).

Task. I was not the manager, but I volunteered to get at least most of the team able to handle a failover, without taking anyone off their sprint work for long.

Action.

• Format choice. I chose a hands-on lunch-and-learn (a short session held over lunch) because the skill was procedural and tacit: a document alone would not build confidence, and a recorded demo alone would be passive. I recorded it as well, for teammates in other time zones, and turned the outcome into a runbook (step-by-step guide) afterwards.
• Preparing a hard concept. Replication lag was the confusing part: the primary database (which takes all writes) sends its changes to the standby (the spare copy) a moment later, and that delay is the lag. I broke it into a three-step mental model: (1) a write lands on the primary; (2) the standby copies it a moment afterwards; (3) if you switch to the standby while it is still behind, the newest writes are missing, so you check the lag is near zero before you fail over. I tried it on one teammate first, and ran the whole exercise in a staging copy (a practice environment that mirrors production but holds no real customer data).
• Getting people to take part. I asked two of the sceptics to co-run one exercise, picked a slot inside the overlap hours, kept it 45 minutes, and asked the manager to say it counted as work time.
• Feedback. I ended with a two-question form ("What is still unclear? What would you use next week?") and fixed the runbook the next day.
• I repeated a shortened version monthly as office hours (a fixed open slot where people bring questions).

Result. Six of the eight had run a failover in staging within a month; the next real database incident was handled by an engineer other than the senior one, with the runbook open. The senior engineer's escalation pings dropped noticeably and the team added a second person to the rota (the on-call schedule of who responds first) for the database.

Why this works as an answer

• It states evidence of uptake (how many did the exercise) and impact (who handled the next incident), not just "people liked it".
• It shows the format choice reasoning: live for tacit skills, documentation for lookup, recorded demos for step-by-step tools across time zones.
• It shows a feedback loop, not a one-off.

Pitfalls

• Saying "we" throughout so your own role is invisible.
• Ending with attendance ("twenty people came") instead of a change in behaviour.
• Inventing precise percentages you cannot back up; counts and named outcomes are more credible.
• Picking a story where nothing was hard; interviewers are looking for the obstacle you handled (low participation, a difficult concept).

Direct answer

Knowledge sharing is how what one person knows becomes usable by others on the team; knowledge transfer is the deliberate version, moving a specific body of knowledge from someone to someone (for example, when an owner changes). The useful distinction is between explicit knowledge (can be written down and looked up) and tacit knowledge (know-how gained by doing, hard to write down). Teams need both, and they move through different practices.

Explicit versus tacit

Practices you should expect to see working

• Docs live next to the work: updated in the same pull request (proposed code change) as the code, each with an owner and a last-reviewed date.
• Code review that explains the why, not only "change this".
• Blameless postmortems (incident reviews that examine causes, not culprits) that produce written actions.
• On-call shadowing and rotations so more than one person has handled each system.
• Regular demos, brown-bags (informal lunchtime talks) and office hours (a fixed slot where anyone can ask an expert questions).

Team flavours:

• Backend microservice team: each service has an owner, an ADR trail, an API contract document (a written spec of what the service accepts and returns), and a shadow on the on-call rota (the rotating schedule of who responds to alerts).
• SRE (site reliability engineering) team: runbooks tested during game days (rehearsed failures), handoff notes at every on-call shift change, postmortem review meetings.
• BI (business intelligence) team: recorded dashboard walkthroughs, a shared glossary of metric definitions, weekly office hours for the people who read the dashboards.

Worked example: first 90 days after a launch

A silo is an area only one person understands, so if they leave or are unavailable the work stalls. The day-90 silo review lists each area of the system and counts who could handle it alone; any area with one name gets a pairing plan, for example two more people take turns as second pair of hands.

Trade-offs and pitfalls

• Over-relying on documents for tacit knowledge produces a large, stale wiki; over-relying on conversation produces a team that cannot survive turnover.
• Sharing that depends on goodwill alone fades under deadlines; give it calendar time and owners.
• Count sharing by outcomes (fewer repeated questions, more people able to handle an area), not by attendance.