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 in the room 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. The problem is that the artifacts are not the same artifact.

The 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.

Old process: implicit contracts — each tier knew what it needed but had never written down what it would deliver in exchange, nor what artifact form that delivery had to take.
Artifact changed: a single cross-tier contract sheet, one page, listing what each tier needs each week and what each tier delivers in return, with a named owner and a dated commitment.
Measured improvement: the next week's review ran forty minutes instead of ninety, and three blocked decisions surfaced in the first fifteen minutes instead of the final five.
Cost of the gap: an average of one and a half decisions per week carried unresolved from one review to the next, each adding between two and five days of downstream delay in the quarter.

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 only consumes without delivering these outputs is an exec whose team will stop surfacing real risk.

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 — a PM who hears about a schedule shift from the exec is a PM who has failed in the system design, not as a person

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; an engineering lead interrupted every thirty minutes cannot hold a consistent technical thread

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"

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 — two different people owning the same conversation is not coverage, it is an orphaned decision waiting to happen

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. An efficient PM, backed by a process that does not waste their time, is a PM teams respect. More concretely: a PM who stops pinging is a measurement. It is the signal that the artifacts are doing their job.

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 — 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 delta note: gaps found, gaps owned, gaps closed. That note 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.

The Hardware OS