1. The Missing Manual
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.
You have watched this movie. It is usually not weak engineers. It is usually no 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 honest tie between the schedule and long leads plus what test actually measured, and no single page where that story stays true before the room invents a new one.
Process means the written habits: who owns the handoff, where the numbers live that the factory is allowed to build to, who may change that number after a test, and how everyone who needs to know finds out before they order steel. Not paperwork stapled on after the design is “done.” The thing that keeps the design from quietly forking inside three different inboxes.
Most engineering leads earn the role on technical judgment, then get judged on skills nobody prints in the promotion packet: who owns the step when mechanical’s output becomes electrical’s constraint; what has to exist after a meeting so people actually build to the same assumption; what belongs on a one-page status; how a limit moves when evidence says it must; when to pull an executive in before a week turns into a quarter. Nobody hands you a course for that bundle. The industry still behaves as if you learn it by walking past the right cubicles long enough.
That gap costs money the same way bad parts cost money: slips, rework, supplier scrap, trust thinning with the people paying the bills. The same scenes on repeat: no owner on the interface line in writing, executive-facing pages that read confident while build and test already know the open item, suppliers going quiet when the drawing set forks, the stretch of calendar where cheap learning has become expensive metal.
This book closes that gap.
The PM in the room
The PM is usually the easiest face to blame when the review gets loud. They are also the one left holding ship windows someone already showed a paying customer while the technical facts are still moving. When what the team knows and what leadership sees do not match, someone still has to turn what actually happened into a plan someone can fund. Facts in hallway fragments and slide footnotes mean the PM keeps asking “where are we?” while mechanical, electrical, and supply each carry a different piece of the answer.
Usually not a personality failure. Missing process: named owner for the handoff, one-page story that matches build and test, written decision when a tradeoff changes, early pull on risk and long leads while you can still steer. When the week stops burning on the same unanswered question, PMs get room to clear blockers instead of running the same worry past everyone again. Those habits start with leads, because that is where they get installed first or not at all.
From the outside it can look like temperament. It is almost always facts that never landed in one place. Back to the list you can actually fix.
What “missing manual” looks like
You see the same failure modes often enough to stop calling them bad luck.
Handoffs nobody owns. Interfaces, limits, and supplier cut-ins sit between org charts. Everyone assumes someone checked. Nobody can point to the sheet that is supposed to be true tomorrow morning.
Paper locked, reality unlocked. Numbers and dates live in mail threads or decks, not where build, test, and supply chain actually run.
Heroic individuals, fragile program. The work gets done because one person holds the context — who owns the call, where the open items live, what the real number is. When that knowledge is not in a record, work that depends on it cannot close. People push in parallel on the same question, each carrying a different piece of the answer, none of it forced into a single decision.
Late truth. Risk and dependency never land in writing where PM and executives can help early, so the surprise shows up first in an exec review, then in metal, then in the field. Wrong altitude for cheap fixes.
Schedule theater: the physics, procurement, and test facts that drive the date moved weeks ago, but the shared plan never caught up. The meeting defends loyalty to a date instead of updating the plan to match the facts. Name it that way and you can at least stop adding your own layer to it.
None of those get fixed by working harder on the same scattered pattern. I came to this late. A few different employers showed me what I had not been naming.
Three programs, one lesson
Three stretches of work. Same lesson as the list above.
Same people, different written habits. What changed was control discipline: one controlled source for the build limit instead of four slide versions, a named signer and date for post-test changes, and direct reporting from the engineer who did the work instead of each layer rewriting the message upward.
Early in my career I saw programs where timelines slid again and again with very little forcing function: no single story of one plan, one date, one record people actually used. People were busy. Key decisions stayed open anyway.
Later I touched energy hardware where right-to-left schedule pressure was not a slide. Survival. Long leads and thermal work landed in the same month as procurement. PMs there were doing real work keeping motion visible while engineering learned what had to be surfaced and written down before it burned the path. Risk and dependency still hurt when they arrived late. Expensive in time and metal.
The strongest program rhythm I have seen personally was on a cell program: tight requirements, real phase gates, a PM who made state obvious to everyone, engineers who owned critical work in front of leadership without each manager filtering and re-editing the message on the way up. Strong process, and the program still needed a technical lead to keep the team from circling the same narrow pocket in the design space for a quarter. Good process did not erase leadership. It focused it.
Now I work with a large industrial org on power electronics. Wins are not a clever topology tweak and are more like pulling the program out of opaque reporting, soft requirements, timelines that slip without anyone writing down why. Biggest gain is often process — engineering cost and time recovered — not a topology or architecture win.
Those sketches point at the same conclusion as the opening: nobody is trying to fail. The operating manual for how decisions and numbers move is what is missing.
What this OS covers — and what it does not
Operating habits and records for hardware programs: ownership, spec integrity, gates that mean something, risk you can read, fleet and factory learning used as instruments, automation choices made early enough to matter, schedules tied to real dependencies, supplier truth that matches what build and test see.
Primary reader: the engineering lead, the person who ends up owning integration whether or not the title caught up. PMs and executives too. Same facts in the same order the lead needs, without inventing another standing meeting to get them.
Not a textbook on formal drawing rules, structured multi-factor experiments, or simulation theory. Those tools matter; pull specialists when the program needs them. You get when to insist on that class of work, what “good enough to decide” looks like, how the result feeds a gate and a one-page status.
Not a replacement for design history, functional safety, or regulatory paperwork. The final chapter names the boundary so nobody confuses these habits with compliance.
Process is the product — the system being built while the hardware is being built. The question that follows is how to run that without it becoming religion.