FIELD NOTE / 05

Who Owns the Total?

A program needs someone who can account for a complete operational outcome, including the conditions that cross team boundaries. Assigning every component to a capable team does not automatically create that responsibility. The missing assignment becomes visible when each team has finished its work and the mission still cannot proceed.

One practical idea in Everything Was Green Until Integration is preserving end-to-end responsibility when authority is distributed. Applying it starts with a specific question: who is responsible for bringing the combined outcome, its supporting evidence, and its unresolved conflicts to a decision?

The answer needs more than a name on an organization chart. It needs a defined outcome and a workable route to the people authorized to resolve the conflicts.

Define the outcome before assigning it

“Own integration” is broad enough to mean almost anything. It can mean managing a facility, coordinating a schedule, or checking that equipment connects. All are necessary activities. None tells the assigned person exactly which operational result they must account for.

Consider a hypothetical spacecraft recovering from safe mode. This is an illustrative example, not a real program event or a scene from TEMPEST. The flight-software team confirms that the recovery sequence completes. The attitude-control team confirms stable pointing. The payload team confirms that the instrument can collect data. Ground operations confirms that the downlink is available.

The mission needs usable observations after recovery. That outcome may also depend on the instrument reaching its valid operating temperature, the correct calibration being applied, and the ground system identifying which observations are suitable for use. A successful recovery command sequence alone does not establish those conditions.

Define the total in operational terms: restore observations that meet the agreed quality criteria within the required recovery interval, under the specified recovery conditions. The program must establish those criteria and limits. Until it does, teams can use the same word, “recovered,” while making different claims.

Give responsibility a route to authority

The person responsible for this outcome will probably not control every contributing team. Their assignment must therefore include access to the relevant evidence and a recognized way to bring unresolved trades to the appropriate decision authority.

For the recovery example, suppose the payload needs additional settling time to meet the observation-quality criterion. That could conflict with the required recovery interval. The outcome owner brings both constraints into the same discussion, identifies the affected requirement and commitment, and obtains a disposition from the person authorized to decide. They cannot quietly relax the quality criterion or promise a shorter recovery on another team's behalf.

Leadership must make that route usable. Name the authority for conflicts that exceed the owner's remit. Establish when those conflicts must be raised and which commitments need a decision before proceeding. An assignment to coordinate, without a way to obtain decisions, can leave the coordinator repeatedly reporting the same unresolved problem.

This preserves the discipline leads' responsibilities. They still own their designs and evidence. The end-to-end owner is responsible for making the combined consequence visible and ensuring it reaches an authorized decision. The role should be explicit even when an existing systems engineer or technical lead already performs much of the work.

Own the combined claim

Local evidence remains valuable. It must be connected to the outcome being claimed. In the recovery example, the owner needs to establish whether the evidence covers the same configuration and operating conditions, how the timing intervals combine, and how observation quality is determined after recovery.

An integrated demonstration might address those questions. Analysis or a representative simulation might support some of them. The evidence plan should identify what each method establishes and which conditions remain unproven. The owner does not manufacture confidence by collecting more passing reports.

When evidence is incomplete, record the consequence for the next commitment. Perhaps a recovery demonstration can proceed, while an operational-readiness claim remains unsupported. If the program accepts a limitation, the authorized decision must state that limitation and its operating consequences. The person assembling the evidence should not become the default risk acceptor merely because they discovered the gap.

Keep ownership through change

Responsibility for the total continues after the first successful demonstration. A revised recovery sequence, new calibration approach, or changed ground procedure can invalidate the conditions that supported the earlier conclusion.

The contributing teams need to know when a proposed change requires the combined outcome to be reconsidered. The owner needs a place in that change process, with access to the affected evidence and decisions. When ownership transfers, transfer the unresolved conditions and accepted limitations as well as the status report. Otherwise, the next person inherits a conclusion without the reasons that made it defensible.

Make one assignment concrete

At your next technical leadership meeting, select one operational outcome that crosses team boundaries and write a one-page ownership agreement. Name the outcome and its acceptance conditions, the person responsible for the combined evidence, the authority for unresolved trades, and the next commitment that depends on their decision. Have the affected leads confirm the assignment before the meeting ends.

If your team needs help finding gaps in that ownership, discuss an Integration Risk Scan with Green Until Integration. This focused consulting engagement examines assumptions, interfaces, ownership, and evidence before a major build, handoff, or review.