Warmup Guide — Leadership & the Capstone Platform

Zero-to-expert primer for Phase 12 — the leadership judgment and integration that turn the prior 11 phases of depth into the role. Less new mechanism, more synthesis and decision-making. The capstone composes everything; this guide is how a Head of Engineering thinks about it.

Table of Contents

Chapter 1: What a Head of Engineering Actually Does

The JD's responsibilities decode into five jobs, none of which is "write the most code":

  1. Set technical direction — the platform vision and the decisions that commit the company (the "decouple from hardware" strategy, the build-vs-buy boundary). Output: strategy docs and ADRs (Ch. 2).
  2. Build the team — hire and structure the rare skill mix (Ch. 3), and make the build-vs-hire calls.
  3. Own the quality bar — codify and defend the standards (Ch. 4) that keep a fast-moving platform shippable.
  4. Drive partnerships and commercialization — OEM integrations (Ch. 5), pricing, the sovereign-AI go-to-market (Ch. 6).
  5. Communicate — translate roofline economics and honest security claims to executives and customers (Ch. 7), and keep technical credibility with engineers (Ch. 9).

The shift from senior engineer to head of engineering is from solving the problem to building the system (human + technical) that solves the class of problems. Your leverage is decisions, standards, hiring, and clarity — not keystrokes. The prior 11 phases are what let you make those decisions credibly; this phase is making them.

Chapter 2: Technical Strategy as an Executable Roadmap

A strategy that isn't executable is a wish. The discipline (the PLATFORM-STRATEGY.md artifact):

  • Start from the thesis: "decouple software from hardware" → the HAL (Phase 09) is the spine, vendor lock-in is the enemy, sovereign + cost-conscious customers are the market.
  • Make it a roadmap with sequenced bets: e.g., (0–6mo) HAL + NVIDIA backend + serving + licensing → first sovereign customer; (6–12mo) AMD backend + conformance suite + OEM #1; (12–18mo) Triton/MLIR backend + multi-vendor GA. Each milestone has a commercial outcome, not just a technical one.
  • Encode the build-vs-buy boundary (Phase 09 ADR): build the HAL (the moat), adopt the kernel compiler, buy commodity infra. State it once, defend it consistently.
  • Tie to error budgets (Phase 10): the roadmap's pace is governed by quality, not just ambition.

The leadership skill is sequencing under uncertainty: which bet first, what it unlocks, what you learn, what you'd cut. A roadmap that's all "and then we build everything" signals inexperience; one with explicit sequencing, dependencies, and kill-criteria signals a leader.

Chapter 3: Org Design and Hiring for a Deep-Tech Platform

The platform needs a skill mix that's hard to assemble (it spans the careers Phases 01–11 represent): kernel/compiler, runtime, distributed systems, serving, security, and SRE. The ORG-DESIGN.md artifact:

  • Structure by subsystem ownership, not by layer: a "serving" team owns Phase 07 end to end (KV cache, batching, the engine integration), a "platform core" team owns the HAL + runtime (Phase 05/09), a "infra/SRE" team owns scheduling + observability + releases (Phase 06/10). Security (Phase 11) is often a small specialist team that consults across.
  • Hire for the gaps, not the comfort zone: the rare hires are the kernel/compiler people and the GPU-savvy SREs; generalists are easier. Map every open role to a phase's competency and use the interview-prep folder's questions as the bar.
  • The build-vs-hire call: do you hire a compiler team (Option C, Phase 09) or adopt Triton/MLIR and hire integrators? Usually the latter — staff to your build-vs-buy boundary (Ch. 2).
  • Seniority shape: a few principals who set the standards (Ch. 4), more senior ICs who execute; avoid over-hiring juniors into a domain with a steep ramp and few mentors.

The meta-point: org design is technical strategy — the team shape encodes the build-vs-buy boundary and the bet sequencing. Mis-shape it and the roadmap stalls regardless of individual talent.

Chapter 4: The Quality Bar — Standards You Own and Defend

A fast platform without standards becomes an unmaintainable one; standards without buy-in become ignored. The leader's job is to codify the bar (it exists implicitly across the phases) and defend it with reasons, not authority. The ENGINEERING-STANDARDS.md artifact collects:

  • Kernel PR checklist (Phase 02): reference-comparison test, sanitizer-clean, event-based timing, ncu limiter evidence, arch notes.
  • Runtime contract (Phase 05): no driver alloc/free in steady state, stream-ordered lifetime, pool segregation + metrics, no device-wide syncs.
  • ABI discipline (Phase 09): version-first, append-only, conformance-gated backends.
  • Release gates (Phase 10): compatibility check → canary → progressive rollout → auto-rollback, governed by error budget.
  • Security-claim discipline (Phase 11): every protection stated with its defeat condition; never "uncrackable."

Each standard maps to a specific incident class it prevents — which is how you defend it when a team finds it pedantic ("this rule exists because of the day-3 OOM / the corrupted tokens / the vendor backend that broke on our release"). Standards justified by incidents stick; standards justified by authority rot.

Chapter 5: OEM and Partner Engineering

The JD's "drive integrations with OEMs, cloud providers, and infrastructure partners" is where engineering and business fuse. Onboarding a vendor's chip (the OEM-ONBOARDING.md artifact) is a process, not a one-off:

  1. Technical: the vendor (or your team) builds a HAL backend (Phase 09) wrapping their compute libraries; it must pass the conformance suite (Phase 09 Ch. 7) — correctness first, then a performance tier.
  2. Commercial: "certified backend" status is the deliverable and the lever — it's a quality promise to customers and a negotiation chip with the vendor (they get ecosystem access; you get a tested backend and a co-marketing story).
  3. Relationship: the conformance bar protects your platform's reputation (a slow/broken backend poisons it) and gives the vendor a clear target. Versioned ABI (Phase 09 Ch. 6) means their backend keeps working across your releases — the trust that sustains the ecosystem.

The leadership insight (Phase 09 Ch. 9): every OEM integration is a backend behind your HAL and a revenue/adoption event. The HAL's quality is the throughput of your partner pipeline — which is why you own it.

Chapter 6: Commercialization — Technical Artifacts to Revenue

The technical work maps to money; a leader makes that mapping explicit:

  • The HAL (Phase 09) → market access for non-NVIDIA chips + freedom-from- lock-in for customers → the core value prop.
  • Sovereign security (Phase 11) → the regulated market (defence, finance, healthcare, government) that cloud-assuming competitors can't serve.
  • GPU sharing tiers (Phase 06) → pricing tiers (dedicated/MIG/time-sliced mapped to isolation guarantees and price points).
  • Serving efficiency (Phase 07) → margin (goodput per GPU is gross margin per dollar of hardware).
  • Conformance certification (Phase 09) → a partner-ecosystem flywheel.

The discipline: for every major engineering investment, state the commercial thesis (who pays more / churns less / becomes reachable because of it). An engineering leader who can't connect the roadmap (Ch. 2) to revenue gets out-prioritized by those who can.

Chapter 7: Executive and Customer Communication

The JD: "engage with customers and partners at both technical and executive levels." The skill is translation without dishonesty:

  • To executives: roofline economics as dollars ("decode is bandwidth-bound, so batching is our margin lever; this optimization is $X/year across the fleet"), the sovereign value prop as TAM, the build-vs-buy boundary as focus/risk. Lead with the decision and its consequence, not the mechanism.
  • To customers (technical): honest capability and honest limits — the goodput-at-SLO discipline (Phase 07 Ch. 6), the security claims with defeat conditions (Phase 11 Ch. 1). Credibility compounds; overselling (a TFLOPs number, "uncrackable") destroys it.
  • To customers (executive): outcomes (their cost per token, their data never leaving the TEE, their air-gapped deployment) not internals.

The through-line from Phase 01's spec-sheet skepticism to Phase 11's "never say uncrackable": honest, decision-oriented communication is a technical leadership skill, and it's what keeps both engineers' and customers' trust.

Chapter 8: The Capstone — How the Pieces Compose

The capstone proves you can integrate, which is harder than any single phase. The composition (trace a request through it):

request -> [License gate, Phase 11]  valid? features/quota ok?
        -> [Scheduler/admission, Phase 06+07] admit? (protect goodput)
        -> [HAL capability routing, Phase 09] pick a backend for the dtype/op
        -> [Serving: paged KV + continuous batching, Phase 07] generate
        -> [Observability, Phase 10] every step emits metrics; SLOs evaluated
   (a backend failure -> failover; license expiry -> refuse; overload -> shed)

The integration lessons:

  • Abstraction boundaries are the design: the HAL ABI (Phase 09), the runtime contract (Phase 05), the control-plane API — each is a seam that lets the pieces evolve independently. Getting the seams right is the architecture.
  • Cross-cutting concerns compose awkwardly: licensing, observability, and failure-handling touch every layer; the capstone shows where they belong (a gate at the edge, metrics everywhere, failover in the router).
  • The whole has emergent failure modes: a license check in the hot path (latency), a metrics export that blocks serving (Phase 05's sync lesson), a capability-routing miss under failover. Integration surfaces these.

The capstone is deliberately CPU-runnable (it reuses the prior phases' models) so the architecture is the lesson, not the GPU plumbing — exactly the altitude a Head of Engineering operates at.

Chapter 9: Staying Hands-On Without Being the Bottleneck

The JD: "stay hands-on where needed — maintaining technical credibility." The balance every engineering leader navigates:

  • Why stay hands-on: credibility (you can't set the kernel-PR bar if you've never profiled a kernel — Phase 02), judgment (you estimate and arbitrate better when you've done the work), and culture (teams respect leaders who can go deep). The prior 11 phases are this credibility, banked.
  • How to not be the bottleneck: be hands-on in leveraged ways — prototype a risky technical bet to de-risk it, do the hard design review, pair on the gnarliest incident, write the reference for a new standard — not by owning critical-path features the team should own. Your code should unblock and set patterns, not be the dependency.
  • The anti-patterns: the leader who codes the main feature (team atrophies, you're the bottleneck) and the leader who never touches code (loses credibility and judgment). The JD explicitly wants neither extreme.

The synthesis: a Head of Engineering's hands-on work is targeted at the highest- leverage technical risk and the standards, leaving the bulk to a team they've hired and structured (Ch. 3) and equipped with clear standards (Ch. 4). That's the role.

Lab Walkthrough Guidance

The capstone is the lab; the leadership artifacts are the portfolio.

  1. Boot and trace (python platform.py): run it, then trace one request through the composition (Ch. 8) — license → admit → route → serve → metrics.
  2. Run the scenarios: expired license (refuse), capability routing, overload (admission protects goodput), backend failover. Each is a prior phase, integrated.
  3. Write the design doc (DESIGN-DOC.md): the architecture, the abstraction boundaries (the seams), the build-vs-buy decisions, the failure modes. This is the single most important artifact — it's what you'd present.
  4. Write the runbook (RUNBOOK.md): operational procedures for the platform's failure modes (compose the Phase 10 runbooks).
  5. Write the four leadership artifacts (leadership/): strategy, org, OEM, standards (Ch. 2–5). Use the rubrics.
  6. Retrospective: what you'd do differently at real scale — the reflection that shows you understand the gap between the model and production.

Success Criteria

  • You can articulate the five jobs of a Head of Engineering and which the JD emphasizes (Ch. 1)
  • You can write an executable, sequenced roadmap with a build-vs-buy boundary (Ch. 2)
  • You can design the team/skill-mix and map roles to competencies (Ch. 3)
  • You can codify and defend with incidents the engineering standards (Ch. 4)
  • You can describe the OEM-onboarding-as-conformance process (Ch. 5)
  • You can connect every major technical investment to a commercial thesis (Ch. 6)
  • You can communicate roofline economics + honest security to executives and customers (Ch. 7)
  • The capstone boots, passes all scenarios, and you can present it end to end (Ch. 8)
  • You can articulate the hands-on-without-bottleneck balance (Ch. 9)

Interview Q&A

Q1: Walk me through a platform you've built. (the capstone) A: [Present the capstone.] It's a GPU orchestration platform composing the layers the role spans: a capability-routed hardware-abstraction layer so software runs across vendors unchanged; a scheduler with admission control that protects goodput; a serving layer with paged KV-cache and continuous batching for serving efficiency; an offline license gate for sovereign deployment; and Prometheus observability with SLOs and release gates so it ships as a product, not a prototype — all behind one control-plane API. The architecture is the abstraction boundaries: the HAL ABI, the runtime contract, the control-plane API are the seams that let each layer evolve independently. I'd walk you through a request: license check → admission → capability routing → batched generation → metrics, and the failure modes — failover on a bad backend, refusal on an expired license, load-shedding under overload — that integration surfaces. What I'd do differently at real scale: [the retrospective].

Q2: How would you execute "decouple our software from hardware"? A: It's a HAL-centered strategy with a sequenced roadmap (not "build everything"). The HAL (the moat) is the spine — a stable API, a versioned backend ABI, and dlopen'd vendor backends with capability routing, so a new chip is a new file, not a rewrite. I'd sequence: first the HAL + NVIDIA backend + serving + licensing to land a first (likely sovereign) customer; then the AMD backend + a conformance suite to onboard OEM #1; then a Triton/MLIR backend for kernel velocity and future chips toward multi-vendor GA. Build-vs-buy: build the HAL, adopt the kernel compiler, buy commodity infra — stated once and defended consistently. Each milestone has a commercial outcome, conformance gates every backend, and the pace is governed by error budgets. The org is shaped to that boundary: a platform-core team owns the HAL/runtime, not a compiler team we don't need.

Q3: How do you structure and hire a GPU platform team? A: By subsystem ownership, mapped to the competencies: a platform-core team owns the HAL + runtime (the hardest hires — kernel/compiler and systems people), a serving team owns KV-cache/batching/engine-integration end to end, an infra/SRE team owns scheduling + observability + releases (GPU-savvy SREs are rare and critical), with a small security specialist team consulting across. I hire for the gaps — the kernel/compiler folks and GPU SREs, not generalists — and use a competency-mapped interview bar. Seniority shape: a few principals who set and defend the standards, more senior ICs executing; I avoid over-hiring juniors into a steep-ramp domain with thin mentorship. Critically, org design encodes strategy — the team shape is the build-vs-buy boundary, so I staff to "adopt the compiler, build the HAL," not to a compiler team.

Q4: How do you balance shipping fast with production quality? A: Error budgets make it arithmetic, not argument (Phase 10). SLOs tied to user experience (goodput at SLO, not raw throughput) define "healthy"; the error budget (1 − SLO) is spendable — we ship aggressively while budget remains and freeze risky changes when it's exhausted. Quality is enforced by codified gates that each prevent a specific incident class — the kernel-PR checklist, the runtime contract, ABI/conformance discipline, the compatibility→canary→rollback release pipeline — defended by the incidents they prevent, not by authority. So "fast" and "production-grade" aren't in tension: the gates let us move fast safely, and the budget tells us objectively when to push and when to stabilize. That's how a deep-tech startup ships through a full release cycle without becoming either reckless or sclerotic.

Q5: Sell me the sovereign-AI value proposition. A: [To an executive:] Regulated customers — defence, finance, healthcare, government — have budget and can't use cloud-assuming AI stacks: they need to run on their own hardware, often air-gapped, with provable control of the software and data. Our platform is built for exactly that: it runs unchanged across whatever hardware they have (the HAL), it's licensed and activated fully offline (no phone-home), and for the highest stakes it proves — via attestation and confidential computing — that it runs unmodified on authorized hardware with model weights and customer data never leaving an encrypted enclave. A cloud-native competitor structurally can't make that claim. So it's a defensible, high-margin market the architecture opens — and the same hardware-agnostic core also wins cost-conscious customers who want out from under NVIDIA lock-in. I'd be honest about limits (attestation proves what loaded, not bug-freeness) because in this market credibility is the product.

References

  • Will Larson, An Elegant Puzzle: Systems of Engineering Management — org design, standards
  • Camille Fournier, The Manager's Path — the IC-to-leader transition
  • Michael Nygard, Release It! — production-grade design (pairs with Phase 10)
  • Staff Engineer (Larson) and The Staff Engineer's Path (Tanya Reilly) — technical leadership without management-only
  • Google SRE books — SLOs/error budgets as a management tool (Phase 10)
  • Architecture Decision Records (Phase 09) — the strategy-as-artifact discipline
  • High Output Management (Andy Grove) — leverage, the core leadership idea (Ch. 9)
  • Cross-track: all prior phases of this track (the capstone composes them); interview-prep, system-design