4. DRI Ownership and Decision Authority

Three failure patterns run together in hardware programs: chaos, drift, and unowned decisions. Unowned decisions are the first break point because without a named person accountable for closure, the minimum control loop has no one to run it.

Monday, 3:55 p.m., late sun on the whiteboard, decision still hanging open.

The question is clear. The data is good enough. The room still does not decide.

Everyone has input. Nobody is the DRI.

By next week, the same topic appears in three meetings with three different "current" assumptions.

This is not a communication problem. It is an ownership design problem.

DRI means closure, not coordination

A Directly Responsible Individual (DRI) is not "the person who schedules the meeting."

A DRI is the person accountable for:

1. framing the decision question,
2. collecting required inputs,
3. proposing a decision by date,
4. recording the outcome and rationale,
5. pushing updates into dependent artifacts (a written program record).

If those five are not explicit, you do not have a DRI. You have a coordinator.

The lead does not need to personally own every DRI role. Naming a DRI is itself a lead responsibility. An engineering lead who surfaces an electromagnetic interference (EMI) concern can frame the decision question — what does this component need to meet, against what test condition, by what date — and assign that question to another engineer. That engineer becomes the DRI: they own defining the requirements, assessing the risk, setting next actions, and driving to a date.

What the lead does not do after that assignment is re-own the path. In reviews, the lead's questions are limited to three: is the closure criterion met, do you need help escalating with another team, and does the one-page status need updating? The lead does not have enough context to judge whether the work is at risk, whether a due date is realistic, or whether escalation is warranted. Those calls belong to the DRI. The lead relies on the owner to surface them.

Authority must match responsibility

The most common ownership failure is giving responsibility without authority.

"You own this thread" means nothing if the owner cannot:

• call the decision when criteria are met,
• escalate when criteria are blocked,
• and enforce update of the one-page status and dependent records.

Authority does not mean unilateral control over everything. It means a known decision boundary and a known escalation boundary.

A battery-pack team hit this exact gap during a stretch where several problems were running in parallel: cell components were arriving out of expected formation tolerance, one material was on allocation, and the laser welding process was generating consistent leak-test failures that nobody could pin to a single root cause. Three functions — process engineering, materials, and the cell supplier — each had a stated position, but no one had a named DRI or a decision date. For ten days, procurement held orders to two different material specifications while the debate continued. The weld failures in particular were resisting quick resolution; each team's proposed fix was blocked or qualified by another team's constraint.

The fix was not a task-force. It was a one-line revision to the ownership record: one process engineer was named DRI for the weld-process decision with explicit authority to call the hold on any build lot when leak-test failure rate exceeded a stated threshold — without waiting for cross-function consensus. The authority boundary was written, not assumed. Once it was, the process engineer called the hold, drove the weld parameter validation without waiting for permission, and closed the leak issue in the next build cycle. The earlier delay was not an analysis problem. It was the absence of a named person who could call the hold.

• Old process: three functions each held a stated position, but no one had named authority to call the hold — resolution required cross-function consensus that was not arriving.
• Artifact changed: one-line revision to the ownership record — one process engineer named DRI for the weld-process decision, with explicit authority to call the lot hold when leak-test failure rate exceeded a stated threshold, without waiting for consensus.
• Measured improvement: leak issue closed in the next build cycle; no additional cross-function permission loop required.
• Cost of the gap: ten days of procurement hold on two competing material specifications while the authority gap remained unresolved.

What breaks when ownership is fuzzy

Shared ownership sounds collaborative and often behaves like delay.

Failure signatures:

• Decisions reopen because nobody is accountable for final closure.
• Teams hold parallel assumptions while waiting for "alignment."
• Escalations happen late because no one is responsible for raising the flag.
• PM and exec updates become negotiation artifacts instead of state artifacts.

One team carried an open bus-bar gauge decision for eleven days. Three functions had stated positions; no one had a named DRI or a decision date. Procurement held two competing purchase orders for the full period. The missing verb was a single line in the ownership record: the lead engineer was authorized to call the gauge specification by a stated date without cross-function consensus below a defined current threshold. Writing that line took ten minutes.

The cost is not just time. It is trust in the decision system.

Minimum ownership map for Week 1

You do not need an org redesign to fix this. You need a narrow map:

1. Top 10 active cross-functional decisions.
2. One DRI per decision.
3. Decision deadline per decision.
4. Required inputs per decision.
5. Decision authority level (team, lead, exec).
6. Escalation path if blocked.

Publish this map where engineering and PM both work from it. If it lives only in one lead's head, it is already stale.

Decision record standard (minimum)

Every closed decision needs one short record:

• decision question,
• decision made,
• alternatives considered,
• why this choice now,
• owner/sign-off/date,
• downstream artifacts updated.

No long memo required. One durable record is enough to stop re-litigation.

The decision record can live in any format — a plain text file, a shared document, a wiki page — as long as it has three properties: a static link anyone on the program can reach today and six months from now, a date stamp or edit history that shows when it was last changed, and a location that is not buried in a conversation thread.

What disqualifies a tool is not its name but its behavior. Chat and email fail as decision records because state drifts — the decision is somewhere in a scroll of messages with no stable address, no clear owner field, and no way to confirm which version is current. A decision sent in a chat message is invisible to anyone who joined the thread late and unrecoverable once the channel is archived.

The question to ask of any tool: can I send someone a direct link to this record right now, and will that link still resolve in a year? If the answer is no, that tool is not suitable for decision records regardless of what else it is used for.

The fields that must be present — owner, decision question, evidence, rationale, affected artifacts, approver, date — are the requirement. The container is implementation detail.

Decision record: bad vs corrected

Escalation without drama

Escalation is a design feature, not a social failure: it fires when trigger conditions are hit, not when room politics allow it.

Define escalation triggers in advance:

• missing critical input by date,
• unresolved cross-function conflict,
• risk threshold exceeded,
• customer/compliance impact.

When trigger conditions are objective, escalation is faster and less political.

If you can name the DRI for every open program decision today, and each DRI has proposed a decision by a date, the OS is doing its job. If any question is 'TBD / team / committee,' it is not.

Decision classes: not every call needs the same overhead

Not every decision warrants the full DRI machinery. The overhead should match the reversibility.

A reversible decision — component selection before tooling, test parameter adjustment during Engineering Verification Testing (EVT) — can move fast with a lighter record and a lower authority threshold. The DRI still owns closure, but speed is the right bias. The cost of being wrong is small; the cost of being slow is real.

An irreversible decision — tooling release, supplier qualification, customer specification commitment — requires the full map: written authority boundary, decision record, downstream artifact updates. Replaying an irreversible decision is expensive enough to justify the added friction before calling it.

A build-to-learn unit is a third class. The acceptance criterion is "what did we learn?" not "did it pass the requirement?" Treating a build-to-learn result as a production failure is a scope error. Name the unit's class before it hits the floor. The DRI for a build-to-learn unit owns the learning extraction, not the conformance call.

If you are not sure which class a decision falls in, ask one question: if we call this wrong, can we undo it before purchasing and build decisions fan out? If yes, it is reversible. If no, treat it as irreversible until proven otherwise.