Designing the interfaces between teams is also designing capability

The launch had stayed on schedule.

This composite case starts with one specific failure. No team failed to follow its procedure.

The work stopped because no one could decide on an exception that affected configuration, price, and operational risk at the same time.

Three classifications for the same request

Sales described the request as a minor adjustment. Operations received it as a new configuration. Product expected a risk analysis that formally belonged to no function.

Each classification was reasonable within its own frame. The incompatibility appeared at the boundary.

The ticket contained enough data to record the demand, but not to decide it. Another meeting only transferred the same ambiguity to more people.

While the case waited, Sales stopped promising a date, Operations reserved capacity it could not use, and Product opened a parallel review. The interface failure began consuming resources within all three teams.

Part of that cost remained outside the ticket. Work was duplicated, conversations were needed to reconstruct context, and provisional decisions later had to be corrected. Measuring only the two-day wait would have hidden the effort absorbed by ambiguity.

The exception shows what the standard flow conceals

The team followed the case from end to end. It identified the signal that initiated the handoff, the information required, the maximum waiting time, and the decision that no one had the right to make.

It also distinguished the type of dependency. Part of the work could proceed in parallel. Another part required a strict sequence. One decision was reciprocal: each area needed information from the other before settling its own criterion.

That shift also made the cost of deciding late visible. While the exception had no owner, each team optimized its own waiting time and the system accumulated incompatible commitments.

Team research broadens the focus

Mathieu and colleagues reviewed a decade of research on team effectiveness. Their framework considers inputs, processes, and emergent states that change over time. It does not prescribe organizational interfaces. It does support examining coordination and interdependence alongside internal attributes. Mathieu and colleagues, Team Effectiveness 1997–2007, 2008 (opens in a new tab).

The useful transfer is limited: if an outcome depends on several teams, assessing each one separately does not necessarily reveal the capability of the system.

The redesign took place at four points

Product and Operations agreed on a shared criterion for separating known adjustments from new configurations. Sales began attaching a minimum set of data before the handoff.

A joint authority was empowered to resolve cases with multiple effects within a defined threshold. Closing each exception returned a brief signal that could improve future classifications.

The intake package changed too. It included the request’s objective, the departure from the standard, known constraints, and the decision being requested. It was not intended to document the entire case. Its purpose was to provide what the next team needed to act without restarting the analysis.

The threshold prevented every case from being escalated. It included financial impact, reversibility, and operational risk. Above that threshold, the case proceeded to a higher forum with information already structured.

No permanent committee emerged. The synchronization frequency remained tied to variability and the cost of waiting.

The case began moving again

On the next exceptional request, the teams retained their responsibilities. The connection changed: the request arrived with context, encountered a criterion, and had a route to a decision.

The improvement does not show that the organization had achieved stable capability. It still needed to observe timing, decision quality, and new types of exception.

Side effects also required attention. A faster interface can transfer pressure to the receiving team or encourage poorly prepared requests. A useful measure combines speed with rework, clarity, and workload distribution.

It did show that the original problem was not an absence of skills. It was an interface designed only for predictable work.

This conclusion extends The organization can have the right skills and the wrong operating model. The operating model becomes tangible at the points where information, authority, and responsibility cross between teams.

Return to the case: the teams retained their responsibilities and the service began moving again because the connection changed. End-to-end capability did not belong to one box on the organizational chart; it also lived in the quality of the connections between boxes.

To extend this reading, see From a skills gap to a capability gap: individual development is not always what is missing and Team capability is not the average of its members, which develop complementary dimensions of the problem.