Every Team Can Be Right and the System Can Still Be Wrong

A reasonable decision can create an unreasonable combination

Consider a hypothetical weather-data service. This example illustrates a decision pattern; it is not an event from a real program or a scene from TEMPEST.

The collection team buffers observations to reduce transmission overhead. The processing team waits for a complete batch because partial batches complicate quality checks. The distribution team retries failed deliveries on a schedule that limits network load. The operations team suppresses repeated alerts so operators can focus on conditions that require intervention.

There is a credible argument for every choice. Each team may also pass the tests written for its own deliverable.

Now consider the person waiting for an observation to support a time-sensitive decision. Buffering adds delay. Waiting for completeness adds more. A retry adds another interval. Alert suppression may keep the accumulating delay from becoming visible soon enough to act. The data can be accurate, the service can be available, and the result can still arrive too late to be useful.

Nobody needs to have ignored a requirement for this to happen. The program may never have allocated a complete timing budget, agreed on how degraded conditions affect that budget, or assigned responsibility for judging the combined behavior.

The risk lives in the conditions attached to success

When a team reports that its design works, ask what must be true for that statement to hold.

Perhaps the input must arrive in order. Perhaps another service must respond within a particular interval. Perhaps an operator must recognize that a displayed value is stale. Those conditions may be reasonable. They become risky when the receiving team has not accepted them, cannot meet them, or is working from a different interpretation.

Interface definitions help, but an agreed message format does not settle every question about how that message will be used. Two teams can exchange the correct fields while disagreeing about whether a timestamp means collection time, processing time, or delivery time. A technically valid message can therefore support an invalid operational judgment.

This is where local evidence needs to be connected. A passing component test establishes something useful within its tested conditions. It does not establish that the next component's assumptions match those conditions, or that the complete sequence preserves the mission's intent.

Review one outcome across the decisions

A practical way to expose this gap is to select one important operational outcome and examine the decisions that shape it. Keep the first pass narrow enough for the participating teams to work through together.

Start by stating what useful means. In the weather-data example, receiving a file is insufficient. The result needs a defined maximum age, understandable quality information, and an agreed response when timely delivery cannot be achieved. The actual limits must come from the mission need, not from whichever component happens to be easiest to measure.

Then ask each participating team to bring one consequential design decision, the reason for it, and the assumptions that make it acceptable. Put those decisions in operational order. Identify where one team's output becomes another team's condition for success.

For each handoff, ask a concrete question: can both decisions remain valid under the same operating conditions? Include a degraded case, such as delayed input or a missed delivery, rather than discussing only the nominal sequence. Look for accumulated delay, incompatible meanings, competing priorities, and recovery behavior that depends on someone else acting first.

Finally, decide what evidence would resolve the uncertainty. That may be an analysis, a representative simulation, an integrated test, or an operational walkthrough. Record what it will demonstrate and what it will leave unproven. Give unresolved conflicts a named decision owner and a resolution date tied to the next affected commitment.

Preserve the reason for the compromise

The result of this discussion will not always be a design change. The program may accept a limitation, revise the operating concept, allocate additional margin, or choose a different priority. What matters is that the trade is made with the complete consequence visible.

Record why the choice is acceptable and the conditions that would require it to be revisited. Otherwise, a later change can remove the very assumption that made today's compromise work while leaving every team's status unchanged.

Technical leadership includes protecting this shared understanding. Teams need room to solve their own problems, together with a reliable way to recognize when their solution changes someone else's ability to deliver the mission.