Staff Mentorship & Distributed-Team Communication

Deliverable 4 of Phase 12. A mentorship/onboarding plan, an async-communication norm for a multi-site team, and a STAR story bank for behavioral interviews (WARMUP Ch. 6–8).

Part A — Onboarding & mentorship plan (template, worked)

Goal: a new engineer is productively contributing to rack-management software within ~30 days and independent within ~90 — and the team is stronger, not bottlenecked on you.

30 / 60 / 90:

  • Day 0–30 — orient + first ship: run the curriculum's Phase 01–03 labs (rack model, the CLI, a Redfish client) on a lab/emulator; pair on a small, real, scoped change behind a flag; first PR reviewed as teaching (explain the why, not just the what). Read the EBOM + key ADRs (Phase 12).
  • Day 30–60 — own a component: take a bounded piece (an exporter metric, a runbook, a driver method) end-to-end incl. tests (the seam — Phase 11) and a runbook; shadow an on-call shift.
  • Day 60–90 — independence + breadth: own a feature across the seams (Phase 03/04), do a design review, write an ADR, take a (supervised) on-call shift, and lead one incident's RCA (Phase 10).

Mentorship mechanics:

  • Pairing on the hard/ambiguous parts; review-as-teaching (link the principle, the ADR, the standard — don't just say "change this").
  • Stretch with a safety net: assign slightly-beyond-current tasks with clear support and a blameless retro if it wobbles.
  • Feedback: specific, timely, kind; separate "must-fix" from "growth area"; celebrate the wins.
  • Make yourself unnecessary: success is the mentee not needing you, and the team's knowledge rising (runbooks, ADRs, docs) — not you being the single point of knowledge.

Part B — Async-first communication norms (multi-site)

For a globally distributed team (the JD), writing is the primary interface (WARMUP Ch. 6):

  • Decisions live in durable docs (ADRs/specs/runbooks), not chat that scrolls away. If a decision happened on a call, someone writes it down.
  • Lead with the decision/ask, then context; make each doc/message self-contained (understandable without the meeting that isn't happening across timezones).
  • Decision + consequence + honest limit in every proposal — what, why, and what you're unsure of.
  • Right medium: durable → doc; quick sync → short call (rotate the painful hour fairly across sites); status → a written update; urgent → page (Phase 07), not a buried message.
  • Minimize required-synchronous; default to async with clear deadlines; assume good intent across cultures/timezones; over-communicate context that's "obvious" locally but not globally.
  • Bias to writing things once, well — a clear interface spec or runbook saves dozens of cross-timezone clarification round-trips.

Part C — STAR story bank (build your 5–6 from the curriculum)

Structure each: Situation · Task · Action (you, specific) · Result (quantified + learning) (WARMUP Ch. 8). Drafts to flesh out from your lab work:

  1. Hardest bug (Phase 10): a latent use-after-free found via ASan/gdb under load; root-caused, fixed, added ASan to CI + a regression test → the class of bug can't recur. (debugging — the JD's #1)
  2. Production incident, prevented recurrence (Phase 08/10): nodes rebooting under thermal load → RAS pointed at a degrading DIMM (rising correctable ECC) → predictive RMA + a new alert; turned an outage class into planned maintenance.
  3. Cross-team/ODM delivery (Phase 03/12): an interface ambiguity with the ODM caused integration slip → wrote a testable spec + conformance suite → integration time dropped and defects became unambiguous.
  4. Mentoring (Phase 12): brought a junior from first-PR to owning the exporter via pairing and review-as-teaching; they now mentor the next hire.
  5. Design-review disagreement (Phase 12): pushed back on synchronous scrape-time BMC calls with a prototype + the failure mode → adopted cached polling; codified the standard.
  6. Tradeoff under constraints (Phase 01): a rack 10% over power budget → power-capping to fit vs. refusing the deployment → capped to fit safely with the perf cost made explicit to stakeholders.

For each, write the quantified result and the one thing you learned — that's what distinguishes a Staff answer.

How to use this deliverable

  1. Adapt Part A to a real (or imagined) report and Part B to your team's reality.
  2. Write out all 6 STAR stories in full from your lab work — they're your interview portfolio.
  3. Practice telling each in ~2 minutes: decision + consequence + honest limit, you the clear actor.