Phase 12 — Collaboration, EBOM & Staff Leadership

Difficulty: ⭐⭐⭐⭐☆ | Estimated Time: 1–2 weeks Roles supported: Staff/Senior Rack Management SWE, Tech Lead Hardware needed: none — this phase produces documents and practices

Why This Phase Exists

The JD's "softer" but decisive requirements — the ones that separate Senior from Staff: "Contribute to software EBOM and protocol documentation with Pegatron and other partners," "Participate in design discussions and reviews, providing implementation‑focused feedback," "Contribute towards documentation, runbooks, and operational procedures," "Strong written and verbal communication for a multi‑site, globally distributed team," and at Staff: "drive implementation of the designs assigned to the local engineering team and provide guidance and mentorship to junior engineers."

These aren't extras. In a distributed, multi-site program co-developed with ODMs (the JD names Pegatron), the artifacts and the communication are the engineering: a precise protocol spec prevents a month of integration pain; a good ADR prevents re-litigating a decision; a runbook turns a 3 a.m. incident from a hero effort into a checklist; mentorship multiplies the team. This phase makes you fluent in producing them.

Unlike the others, this phase's "labs" are the deliverable documents themselves — the exact artifacts you'd produce on the job, with templates and guidance you fill in and reuse.

Concepts

• The software EBOM (Engineering Bill of Materials): for software/firmware — the versioned inventory of components, firmware baselines, dependencies, and interfaces agreed with the ODM; why it's the contract that keeps a multi-party build coherent (ties to Phases 01, 08)
• Protocol/interface documentation: specifying Redfish schemas/OEM extensions, sensor lists, error semantics, and behavior precisely enough that two teams on two continents build to the same thing; the conformance suite as the spec's executable form (Phase 03/11)
• Working with ODMs/ISVs: the NPI process (Phase 01), defining interfaces up front, the defect-feedback loop, upstreaming (e.g., OpenBMC — Phase 04)
• Design reviews & ADRs (Architecture Decision Records): how to give and receive implementation-focused feedback; capturing decisions, alternatives, and consequences durably
• Runbooks & operational procedures: turning Phase 10 RCAs and Phase 08 diagnostics into repeatable, on-call-ready procedures; the runbook template
• Technical writing for a distributed team: async-first, precise, decision + consequence + honest limit; documents that survive timezones
• Staff leadership: driving implementation of a defined design across a local team; mentorship; raising the engineering bar (standards, Phase 02/11); influence without authority; the Senior→Staff transition
• Behavioral excellence (STAR): structuring the stories (debugging wins, RCAs, cross-team delivery) that interviews probe

Deliverables (the "labs" of this phase)

Produce each by filling in the template; they double as your interview portfolio.

Worked portfolio (complete, filled artifacts — leadership/portfolio/)

The templates above, filled in as standalone artifacts you can show in an interview (no placeholders):

Deliverables Checklist

• A software EBOM for a node/rack: components, firmware baselines, interfaces, versions
• A protocol/interface spec section precise enough for an ODM to build to (with conformance hooks)
• An ADR for a real decision (e.g., "Redfish-first driver abstraction") with alternatives + consequences
• A design-review feedback example (implementation-focused: feasibility/perf/reliability/maintainability)
• A runbook for a real procedure (e.g., "node won't POST" or "fleet firmware rollout")
• A mentorship/onboarding plan and an async-communication norm for a multi-site team
• 3–5 STAR stories drawn from the labs (a hard bug, an RCA, a cross-team delivery)

Interview Relevance

• "Walk me through how you'd document an interface for an ODM partner to implement."
• "What goes in a software EBOM and why does it matter?"
• "Tell me about a design review you led / disagreed in. How did you handle it?"
• "How do you write a runbook? What makes a good one?"
• "How do you mentor junior engineers / raise the team's bar?"
• "How do you communicate effectively in a distributed, multi-timezone team?"
• "What's the difference between Senior and Staff to you?"
• Behavioral (STAR): hardest bug, a conflict, a delivery under ambiguity, mentoring a struggling teammate.