Warmup Guide — Collaboration, EBOM & Staff Leadership

Zero-to-Staff primer for Phase 12 — the artifacts and behaviors that separate a strong coder from a Staff engineer who multiplies a distributed team. The technical phases gave you what to build; this gives you how to make it land across sites, partners, and people.

Table of Contents

Chapter 1: Why the Soft Skills Are the Hard Part Here

This role is "execution-focused" and "well-suited for a senior engineer who thrives in a distributed team model, communicates effectively across sites," co-developing with ODMs (Pegatron). At that scale, the bottleneck is rarely "can someone write the code" — it's "do two teams on two continents share the same understanding of the interface, the decision, and the procedure." Your artifacts (EBOM, specs, ADRs, runbooks) and your communication are what create that shared understanding. A brilliant implementation built to a fuzzy spec is a month of rework; a clear spec built by competent engineers ships. So these "soft" deliverables have hard, measurable impact — and they're what the Staff bar is about.

Chapter 2: The Software EBOM

An EBOM (Engineering Bill of Materials) lists everything that goes into a product. For software/firmware, the EBOM is the versioned, authoritative inventory of what runs on a node/rack and the interfaces between parts — the contract that keeps a multi-party build (you + the ODM + ISVs) coherent. It typically captures:

  • Firmware components & baselines (Phase 08): BIOS/UEFI, BMC, NIC/DPU, accelerator, PSU, PCIe switch, CPLD — each with the approved version and signing info.
  • Software components: the rack agent, exporters, operators, drivers — versions and dependencies (Phase 11 compatibility matrix).
  • Interfaces: which protocols (Redfish/IPMI/SNMP — Phase 03) and which exact schemas/OEM extensions, sensor lists, error semantics (Chapter 3).
  • Configuration baselines: secure-boot keys, network/VLAN layout (Phase 09), default policies.
  • Provenance & traceability: who owns each, source, licenses, support status.

Why it matters: at commissioning (Phase 01) you reconcile discovered reality against the EBOM — a mismatch is a finding raised back to the ODM. During the lifecycle, the EBOM is the source of truth for "what should be here," and drift from it is a defect. Without it, a multi-site, multi- vendor program descends into "works on the lab unit, not in Riyadh."

Chapter 3: Protocol & Interface Documentation (ODM-facing)

The JD specifically calls out protocol documentation with partners. The skill is writing an interface spec precise enough that another team builds the same thing without you in the room. A good interface spec:

  • Names the standard and the deltas: "Redfish 2023.2, with these OEM extensions, these required resources, these sensor names/units, these AllowableValues." Don't assume; enumerate.
  • Specifies behavior, not just shape: state machines (power, firmware-update Task lifecycle — Phase 08), error semantics (what status/body on each failure), idempotency, timing/retry expectations (Phase 03 Ch. 9 — real BMCs vary).
  • Is testable: pair the prose with a conformance suite (Phase 11) — executable expectations the ODM runs against their firmware. The suite is the unambiguous spec; prose drifts, tests don't.
  • Versions and changes deliberately: the spec evolves; track it like code, with a changelog and compatibility notes (Phase 11 Ch. 5).
  • Has an owner and a feedback loop: defects and gaps flow back to the partner; you upstream fixes where applicable (OpenBMC — Phase 04).

The mental model: you're writing the contract between organizations. Ambiguity in it becomes integration pain measured in weeks. Precision here is leverage.

Chapter 4: Design Reviews and ADRs

Design reviews: the JD wants "implementation-focused feedback on feasibility, performance, reliability, and maintainability." Giving good review feedback:

  • Anchor on those four axes plus security (Phase 02/09) and operability (Phase 07). Ask "how does this fail?", "how is it tested without hardware?" (the seam, Phase 11), "what's the blast radius?" (Phase 01), "how do we roll it back?" (Phase 11).
  • Separate must-fix (correctness/security) from opinion (style). Be specific and kind; critique the design, not the person. Offer alternatives, not just objections.
  • Receiving feedback: assume good intent, ask for the why, disagree-and-commit when a decision is made.

ADRs (Architecture Decision Records): a short doc capturing a significant decision — the context, the decision, the alternatives considered, and the consequences (including the downsides you accept). ADRs prevent re-litigating settled questions, onboard newcomers ("why is it this way?"), and make trade-offs explicit. Every meaty decision in this curriculum is an ADR: "Redfish-first driver abstraction" (Phase 03), "A/B firmware banks" (Phase 08), "operator-based lifecycle" (Phase 06). Writing one is a deliverable here.

Chapter 5: Runbooks & Operational Procedures

A runbook is a step-by-step procedure for an operational task or incident, written so someone other than the author, possibly half-asleep at 3 a.m., can execute it safely. The JD wants "runbooks and operational procedures related to the software you own." A good runbook:

  • Has a clear trigger (the alert/symptom — Phase 07) and a stated goal/outcome.
  • Is a precise checklist: exact commands, expected outputs, decision points ("if X, then Y").
  • Bounds risk: pre-checks, blast-radius notes (Phase 01), dry-run/confirmation for destructive steps (Phase 04), and a rollback (Phase 11).
  • Links context: the relevant dashboard, the ADR, the escalation path, the partner contact.
  • Comes from incidents: every RCA (Phase 10) that found a manual fix should leave a runbook (and ideally automation that makes the runbook obsolete).

Runbooks turn tribal knowledge into team capability — essential for a distributed, follow-the-sun on-call. The progression a Staff engineer drives: manual → runbook → automated → self-healing (the operator, Phase 06).

Chapter 6: Writing & Communicating for a Distributed Team

Multi-site means async-first: you can't tap a shoulder across an 8-hour timezone gap, so writing is the primary interface. The principles:

  • Lead with the decision/ask, then the context (inverted pyramid) — readers in another timezone shouldn't dig for the point.
  • Decision + consequence + honest limit: state what, why, and what you're unsure about or trading away. Honesty about limits builds trust and prevents nasty surprises.
  • Precise and self-contained: a doc/message should be understandable without the meeting that isn't happening. Define terms, link references.
  • Right medium: durable decisions → a doc/ADR (not a chat that scrolls away); quick syncs → short calls; status → a written update. Capture verbal decisions in writing.
  • Respect timezones: minimize required-synchronous; when you do meet, rotate the painful hour fairly across sites.

Clear writing is not a "nice to have" in this role — it's the JD's explicit requirement and the mechanism by which a distributed team functions at all.

Chapter 7: The Staff Engineer

The Senior→Staff shift, framed for this JD ("drive implementation of the designs assigned to the local engineering team; provide guidance and mentorship"):

  • Scope: a Senior owns features/components; a Staff owns outcomes across a team/area — making sure the design actually gets implemented well, integrated, and shipped, unblocking others.
  • Leverage over output: a Staff multiplies the team — through standards (Phase 02/11), reviews (Chapter 4), specs and runbooks (Chapters 3, 5), mentorship, and good technical decisions — more than through personal commits. Your code matters, but your impact through others matters more.
  • Mentorship: grow junior engineers deliberately — pairing, review-as-teaching, stretch assignments with a safety net, and clear feedback. A mentored team that ships beats a hero who bottlenecks.
  • Influence without authority: you usually can't order; you persuade with clear reasoning, data, and prototypes, and you build trust by being reliably right and reliably honest.
  • Driving implementation: take a defined design (architecture set elsewhere — the JD's model) and make it real: break it down, sequence it, identify risks early (the integration seams, Phase 03/04), keep the distributed team aligned, and own the debugging when reality bites (Phase 10).
  • Knowing the limits of your role: the JD is explicit that architecture is often "defined elsewhere" — Staff here is about excellent execution and local leadership, not architecture astronautics. Reading that correctly (ambitious in execution, collaborative on direction) is itself a maturity signal.

Chapter 8: Behavioral Interviews (STAR)

Senior/Staff loops always include behavioral rounds; structure your stories with STAR: Situation (context), Task (your responsibility), Action (what you did — be specific and own it), Result (the outcome, quantified, plus what you learned). Prepare 5–6 stories that cover the JD's themes, drawn from this curriculum's work:

  • A hard bug you root-caused (Phase 10 — the RCA story).
  • A cross-team/ODM delivery under ambiguity (Phases 03/12).
  • A production incident you handled and prevented from recurring (Phase 10).
  • Mentoring someone / raising the bar (Phase 12).
  • A disagreement in a design review handled well (Chapter 4).
  • A tradeoff you made under constraints (e.g., capping to fit, Phase 01).

The bar: a decision + its consequence + the honest limit, told concisely with you clearly the actor. Vague "we" stories and no-quantified-result stories are the common failures.

Deliverable Walkthrough Guidance

Work the four leadership docs in order; each is a fill-in template that becomes a portfolio piece:

  1. EBOM & protocol spec (leadership/EBOM-AND-PROTOCOL-DOCS.md): write the ODM-facing contract for a node — components, firmware baselines, the Redfish interface with OEM deltas, and conformance hooks.
  2. Design review + ADR (leadership/DESIGN-REVIEWS-ADRS.md): write an ADR for a real decision from the curriculum and a sample review-feedback note on the four axes.
  3. Runbook (leadership/RUNBOOKS-AND-OPS.md): write a runbook for a real procedure ("node won't POST" or "fleet firmware rollout") with trigger, steps, risk bounds, and rollback.
  4. Mentorship & comms (leadership/STAFF-MENTORSHIP.md): write an onboarding/mentorship plan and an async-communication norm for a multi-site team.

Then extract 3–5 STAR stories from the labs across all phases — that's your interview portfolio.

Success Criteria

You're done with this phase when — without notes:

  • You can explain what a software EBOM contains and why it's the ODM contract (Ch. 2)
  • You can write an interface spec precise + testable enough for a partner to implement (Ch. 3)
  • You can write an ADR (context/decision/alternatives/consequences) and give review feedback on the 4 axes (Ch. 4)
  • You can write an on-call-ready runbook with triggers, risk bounds, and rollback (Ch. 5)
  • You can communicate decisions async for a distributed team (decision + consequence + limit) (Ch. 6)
  • You can articulate the Senior→Staff difference and how you drive implementation + mentor (Ch. 7)
  • You have 5–6 crisp STAR stories covering the JD's themes (Ch. 8)

Interview Q&A

Q1: What goes in a software EBOM and why does it matter for an ODM program? A: It's the versioned, authoritative inventory of everything that runs on a node/rack plus the interfaces between parts — firmware components and their approved baselines (BIOS/BMC/NIC/ accelerator/PSU/switch, with signing info — Phase 08), software components (agent/exporters/ operators) and their dependency/compatibility matrix (Phase 11), the exact management interfaces (Redfish schemas + OEM extensions, sensor lists, error semantics — Phase 03), config baselines (secure-boot keys, VLAN layout — Phase 09), and provenance/ownership. It matters because in a multi-party build (us + an ODM like Pegatron + ISVs) it's the contract that keeps everyone coherent: at commissioning I reconcile the discovered hardware/firmware against the EBOM and any mismatch is a finding raised to the partner, and throughout the lifecycle drift from the EBOM is a defect. Without it, you get "works on the lab unit, not in the field."

Q2: How would you document an interface for an ODM partner to implement? A: I write a spec precise and testable enough that they build the same thing without me in the room. It names the standard and the deltas (e.g., Redfish 2023.2 + these required resources, OEM extensions, sensor names/units, AllowableValues), specifies behavior not just shape (state machines like the firmware-update Task lifecycle, error semantics, idempotency, retry/timing expectations — because real BMCs vary), and — critically — pairs the prose with a conformance suite (Phase 11) the partner runs against their firmware, because executable expectations don't drift the way prose does. I version it like code with a changelog and compatibility notes, give it an owner, and run a defect-feedback loop (and upstream fixes to OpenBMC where applicable). The framing is that I'm writing a contract between organizations, and ambiguity in it costs weeks of integration pain.

Q3: What makes a good runbook, and where do runbooks come from? A: A good runbook has a clear trigger (the alert/symptom — Phase 07) and goal, then a precise checklist anyone can execute at 3 a.m. — exact commands, expected outputs, and decision points ("if X then Y"). It bounds risk: pre-checks, blast-radius notes (Phase 01), dry-run/confirmation on destructive steps (Phase 04), and a rollback (Phase 11); and it links the dashboard, the relevant ADR, and the escalation path. They come from incidents — every RCA (Phase 10) that ended in a manual fix should leave a runbook, and the Staff move is to then automate it away (manual → runbook → automated → self-healing via the operator, Phase 06). Runbooks turn one person's tribal knowledge into the whole distributed on-call's capability.

Q4: What's the difference between a Senior and a Staff engineer to you? A: A Senior owns features/components and delivers them well; a Staff owns outcomes across a team or area and works through leverage rather than personal output. Concretely for this role (where architecture is often defined elsewhere): a Staff drives implementation of the assigned design — breaking it down, sequencing it, surfacing integration risks early (the Redfish/hardware seams), keeping a distributed team aligned, and owning the hard debugging when reality bites (Phase 10) — and multiplies the team through standards, reviews, specs, runbooks, and mentorship. The mindset shift is from "how much can I build" to "how much better does the team/area get because I'm here," while staying hands-on and execution-focused. Reading the JD correctly — ambitious execution, local leadership, collaborative on direction rather than architecture-astronaut — is itself part of the maturity.

Q5: Tell me about a design review where you disagreed. A: (STAR) Situation: reviewing a teammate's BMC-interaction module that hardcoded Redfish paths and talked to the BMC synchronously on every Prometheus scrape. Task: I owned review for the telemetry area. Action: I gave implementation-focused feedback on the four axes — maintainability/correctness (hardcoded paths break across vendors; follow @odata.id links — Phase 03), reliability/ performance (synchronous scrape-time BMC calls hammer fragile BMCs and couple scrape latency to BMC health — poll on our own schedule and cache, Phase 07) — separating must-fix from opinion, and I brought a small prototype showing the cached approach. We disagreed on effort vs. payoff; I framed it with the failure mode (a slow BMC stalling all scrapes) and we agreed to the cached design with a follow-up. Result: the exporter stayed responsive under flaky-BMC conditions in the field, and we codified "follow links, never hardcode" and "no synchronous device I/O on scrape" as review standards. I critique the design, not the person, and I bring alternatives and data, not just objections.

References

  • Will Larson, Staff Engineer: Leadership Beyond the Management Track — https://staffeng.com/
  • Tanya Reilly, The Staff Engineer's Path
  • ADRs — Michael Nygard, "Documenting Architecture Decisions"; https://adr.github.io/
  • Google SRE Book — runbooks/playbooks and postmortem culture — https://sre.google/books/
  • Docs for Developers / Google Technical Writing courses — https://developers.google.com/tech-writing
  • "Disagree and commit" / writing culture (Amazon, Stripe engineering writing) — for async comms
  • DMTF Redfish (interface specification practice) — https://www.dmtf.org/standards/redfish
  • Cross-track: Apache PMC/Committer track — review culture, governance, community