15. What Every Tier Wants (Exec to Supplier)

Thursday, 12:55 p.m., lunch cleared to the corner of the table, the weekly review still going.

The exec pulled the status from last week's board deck. The PM has the project tracker open on one screen. Engineering is working from an email thread that captured the last three decisions. The supplier's rep is at the table with a spec revision they received three weeks ago, which has since been superseded twice.

Nobody is wrong about what they brought. Each person is reading a legitimate artifact — a written program record. The problem is that the artifacts are not the same artifact.

The ninety-minute review stalls forty minutes in because a decision that everyone assumed was made — a packaging change affecting the supplier — had never been recorded in a form any two tiers could read together. The exec asks for a confidence number. Engineering needs two more weeks of closure time. PM needs a stable input to forecast. The supplier needs one released package with one owner. All four needs are legitimate. None of them can be met in this meeting because the four tiers are navigating by different maps — on average, a decision and a half per week carried this way, each adding two to five days of downstream delay.

Alignment fails at interface contracts

Most cross-tier conflict is not ideology. It is interface-contract ambiguity: what each tier needs to make a decision, when that input is needed, and which quality bar applies to the artifact. When those three things are not written down, every tier improvises. Improvisation looks like friction.

When a named owner publishes these contracts in one shared artifact, the friction does not disappear — but it becomes auditable. An auditable gap gets assigned and closed. An invisible gap becomes a personality conflict.

What each tier usually needs

Keep each tier contract plain, operational, and tied to one decision artifact.

Executive / sponsor

leading indicators of risk and dependency — not a confidence score, but a named risk row with an owner and a trigger
clear decision asks — one binary question with a date, not a discussion topic
tradeoff framing when date/cost/scope conflict — their job is to make that call, not to infer it from color-coded slides

What the exec owes downward: stable goals that do not shift weekly, in-room tradeoff decisions when engineering brings the evidence (not hallway overrides), day-grade resource unblocking when the engineering lead names a blocker, and a clear definition of "done enough to ship." An executive who takes the decision asks and the tradeoff evidence without closing the call keeps the risk item open. It will run through every weekly review unchanged — re-reported, re-acknowledged, unresolved — while the work that needs that decision queues behind it.

stable owner map — who has each decision, one row per open item
decision-ready updates — the PM should not have to chase an answer; the owner posts it before the review
early signal when assumptions break — if the PM hears about a schedule shift from the exec, the information routing is broken

What the PM owes downward: transparent escalation when a contract breaks (not a complaint — a named artifact gap, a blocked decision, a date), dependency hygiene in the one-page update, and a cadence that does not add overhead faster than it removes ambiguity.

Engineering lead

clear requirement and risk state — one live record, not email
authority boundaries — which decisions belong to the lead and which need approval; ambiguity here is expensive
protected closure windows for technical decisions — time to think is not a luxury; a lead with no protected windows will make shallow calls on deep problems, because the problem context resets at every interruption

Operations and manufacturing read the same thing differently — they need the release package to be unambiguous before the build starts, not before the inspection fails.

Manufacturing/operations

unambiguous release package with revision-locked content
process-critical characteristics called out explicitly, not scattered through engineering notes
change notice with timing — not just "we changed it" but "this revision affects your build starting with lot N"

The supplier contract is the farthest from the program center, which means any ambiguity compounds the longest.

Supplier

one current revision source — not "check the portal, the email, and the drop folder"
expected evidence and acceptance criteria before the program needs the data, not when inspection fails
single owner for both technical and commercial closure — when these run as separate conversations, the supplier receives two partial agreements and acts on whichever arrived last; no one on the program side holds the combined answer, and the gap surfaces in the release package

Reciprocal obligations

Needs without reciprocal obligations become entitlement and eventually gridlock. The contract is not "here is what I need from you." It is "here is what I need, here is what I deliver in return, and here is the artifact that makes both visible."

Pair each ask with an owed output artifact:

Exec asks for confidence → owes timely trade decisions recorded in the decision log and stable goals that do not drift week-to-week.
PM asks for predictability → owes transparent escalation and dependency hygiene in the one-page update, and a cadence the team can trust.
Engineering asks for room to solve → owes explicit risk state and closure dates in requirement and risk records, and a commitment to surface surprises before the weekly review, not at it.
Supplier asks for clarity → owes capability evidence and issue response cadence in the release package.

This framing keeps fairness visible by balancing each tier's ask with a concrete, auditable obligation.

PM fairness, explicitly

When record quality is low, PM becomes the human sync engine compensating for missing system behavior in formal artifacts. The PM pings because the artifact does not answer the question. That is a system failure, not a PM failure.

With clean ownership, requirement truth, and one-page integrity, PM work shifts from chasing contradictions to clearing real blockers. That shift has a concrete payoff for the engineering lead: a PM who trusts the schedule and the risk register stops asking for daily status. Not because they stopped caring, but because they have something reliable to read. An engineering lead who has earned that trust has bought themselves a working environment — time to solve the technical problem instead of presenting it repeatedly.

That is the contract to protect. A PM who reads the schedule without calling you is one who trusts the artifacts — and that is the signal the OS is working.

What the exec leaving early looks like

There is a simple field test for whether the program's one-page status and gate truth are working: can your exec leave for the weekend without anxiety?

Not because the program has no risk. Every hardware program has risk. But because:

the risk register surfaces the risks that would otherwise surprise them
every open decision has a named owner and a date
the one-page status line traces to a real artifact, not to a slide that was polished to look calm
the gate status reflects what the test floor actually saw, not what the team hoped to see

When those four things are true, an exec who leaves Friday afternoon is not checking out. They are making a rational decision that the information they need will surface through the artifact, not through a weekend phone call. That is the payoff for having built the OS. The fact that the exec can leave early is the measurement.

If your exec calls you on Saturday, the OS has a gap. Find it.

One review format that surfaces gaps early

Run a short cross-tier interface review against one shared contract sheet — one page listing what each tier needs and delivers each week, with a named owner per row. Not a status update: a contract-quality check:

Confirm what each tier needs this week (read from the contract sheet, not from memory).
Verify what each tier received (not what was sent — what actually landed in usable form).
Identify where contract quality failed (which artifact was missing, late, or incomplete).
Assign which owner closes the gap by when.

Skip long debate. Focus on interface quality, owner assignment, and dated closure commitments. The meeting produces a short gap record: gaps found, gaps owned, gaps closed. That record is the input to next week's check.

Escalation becomes cleaner

When tier contracts are explicit, escalation becomes factual and auditable: identify which contract failed, state what decision is blocked, quantify the current risk and date impact, assign who must decide by when.

That path resolves blockers faster than personality-driven escalation because decision authority and artifact gaps are explicit. An engineering lead who escalates with a named artifact gap and a dated decision need is not complaining — they are running the process. An exec who receives that escalation has a job to do, not a people problem to manage.

Field test: name the most recent decision your exec made on your program. Did they have a one-page status that traced to a live record? If they had to call someone first, the artifact was not trusted — and the call is now the record.

All four tiers are finally working from the same record. The exec can say where the program stands in one sentence — and the next test of that sentence is first article: one build, one question at a time.

The Hardware OS