The Hardware OS
> Monday. 6:47 a.m. Parking-lot light still on — messages already stacking before the standup. > > > The thermal limit changed again. > >
> Mechanical already cut metal to last week's number. Electrical has a new test trace that says the old number was optimistic. The supplier says they never got the last revision anyway. The program manager is trying to hold the date everyone committed in the first quarter — and your executive wants a one-page update by noon: _Are we still on track or not?_ > > > Everyone is working. Nobody is slacking. The program is still drifting. > > — Chapter 1: The Missing Manual
About the book
The operating procedure for hardware programs
Hardware programs fail in a predictable pattern: requirements drift from what the physics actually demands, decisions get made without a clear owner, and test results arrive too late to change what was already built. It is rarely weak engineers. What is almost always missing is a manual for the process — no agreed way for work to cross team lines, no shared rule for what "locked" means when new data shows up, no single page where that story stays true long enough to survive the next status call.
The Hardware OS is that manual. A shared operating procedure for how requirements are written, how decisions get made and recorded, how evidence changes the plan, and how that discipline is installed in an organization already in motion.
Process is the product — the system being built while the hardware is being built.
Who this is for
Written for engineers running programs, not projects
- **Engineering leads** responsible for a hardware program from concept to production — where the build always diverges from the decisions made in the review room.
- **Systems engineers** who write requirements and watch them get softened, stacked with margin, or quietly abandoned as schedules compress.
- **Program managers** on hardware programs who need a technically credible framework — not a generic PM methodology — for keeping the program honest as evidence arrives.
If your product sits in a regulated domain, safety lifecycles and certification obligations remain primary. This OS mounts underneath them.
What this delivers
A narrower promise — and a more useful one
The OS does not remove uncertainty. Hardware work stays cross-functional and time-constrained. The promise is:
1. Everyone in the room works from the same number — because there is only one, it is controlled, and it is current 2. Problems reach you while you still have room to respond — not after the expensive metal is already cut 3. Decisions actually close, with a written record of what was decided, who owns it, and what would reopen it 4. The class of surprise that shouldn't happen — a supplier missing a revision, an assumption nobody wrote down, a test result that never changed the plan — stops happening
If your team is looking at the same facts, making faster decisions, and updating the plan when evidence changes — this OS is doing its job.
About the author
Steve Embleton
Steve Embleton is a hardware engineering lead with over ten years running mechanical, thermal, and power electronics programs from concept through production. He has worked in defense sonar systems, data center infrastructure at Dell, and advanced battery and power electronics at Tesla — including the 4680 cell program, where he applied the methodology in this book to deliver novel high-risk R&D products on time. Teammates across disciplines credited the program discipline directly.
He currently builds AI-related hardware products and holds patents spanning AI systems, liquid cooling, EMI shielding, reliability, transportation, and battery manufacturing.
Contents
Twenty chapters in five parts
1. ### Part I — Why Hardware Programs Break
The failure pattern that shows up on every program — not bad engineers, but missing operating discipline. Names the dysfunction before proposing the fix.
1. The Missing Manual 2. Process Is the Product 3. Failure Patterns: Chaos, Drift, and Unowned Decisions
2. ### Part II — The Hardware OS Core
The operating controls: ownership, spec integrity, gates that mean something, automation decisions made early enough to matter, and schedules built from real dependencies.
1. DRI Ownership and Decision Authority 2. Spec Integrity and Requirement Hygiene 3. Gates, Risk Registers, and One-Page Truth 4. Automation Decisions at Concept Stage 5. Schedule from Real Dependencies and Honest Critical Path
3. ### Part III — Technical Evidence That Changes Program Decisions
How requirements evolve from physics, not stacked buffers. How tests and models change the plan. How to define "done" in a way that survives evidence.
1. Requirements Lifecycle: Hypothesis → Bless → Evidence → Revise 2. Requirements from Physics, Not Stacked Buffers 3. Many Factors, One Honest Limit 4. Models and Tests That Change Decisions 5. Fleet as Instrumented Experiment 6. Risk and How We Define Done on Paper
4. ### Part IV — Running the Organization
What each tier actually needs — from executive to supplier. First-article iteration done fast and with discipline. Supplier truth that matches what build and test actually see.
1. What Every Tier Wants: Exec to Supplier 2. First Article: Fast, Disciplined Iteration 3. Supplier Data, Critical Characteristics, and Producibility
5. ### Part V — Adoption and Scale
Installing the OS in an organization already in motion — triage first, then system. Training, cadence, and how to recover when the OS itself starts to drift.
1. Rollout Sequence: Triage Then System 2. Training, Cadence, and Failure Recovery 3. What This OS Does Not Cover
Get the book