Structural Correction

Chapter 11: Contracts, Not Committees

Versioned, machine-readable contracts between units replace committees. A contract violation is detected automatically, attributed to a specific party, and resolved in eighty-six minutes between two people, with no bridge call and no responsibility debate.

The payments unit's contract requires consuming units to submit fully validated customer and account data, which is structurally correct: the payments process should not validate data it does not own.

The contract feels different to the consuming units. Motor origination finds that validating account data at point of sale adds delay customers feel; claims discovers that claimants who have changed banks require a re-verification step its process does not accommodate. Both face the same incentive: minimise their own validation and let the payments unit reject what it cannot process. The payments unit tightens its contract, stricter formats and faster rejection; the consuming units add workarounds and automatic retries. Within six months the interaction has produced coordination overhead encoded in contracts rather than meetings, but coordination overhead nonetheless, with payment failures rising and resolution times lengthening.

Only a structural redesign fixes it. The three units redesign the contract together: validation responsibilities are split so each unit validates what it owns, and a shared checking step, published by the payments unit, lets the others verify payment-specific fields before submitting. The arms race stops, and the customer experience recovers within a quarter. The operating model produced both the failure and the fix, but only once the structural incentive changed: each unit accountable for its own validation rather than passing it across the boundary. Coordination between teams is usually managed through committees: steering groups, dependency boards, change advisory boards. They exist because no explicit mechanism governs how one team's output becomes another team's input, so the interaction is negotiated socially, in meetings, and the negotiation repeats whenever conditions change. A typical steering committee shows the ratio: twelve attendees, of whom eight represent someone who could not attend, three are taking notes for a different meeting, and the one who understands the system has not been asked to speak. Contracts replace repeated negotiation with a structural mechanism.

A contract is the operational equivalent of a supplier agreement with versioned terms: a specification of how one unit interacts with another, what it promises, what it depends on, and what happens when either changes. A social agreement depends on memory and goodwill; a contract can be tested, versioned, and enforced without continuous human interpretation. Once an interaction is made explicit, a consuming unit reads the contract, and when the contract changes it reads the new version: the interaction is mediated by the artefact, not by a person. New interactions still require design and contract failures require investigation, but the routine steady state, one unit consuming another's output, is handled by the contract. For a board member unfamiliar with software versioning, this is the equivalent of changing the terms of a supplier contract: the question is whether changes are announced, bounded, and backwards-compatible, or arrive without warning and break existing arrangements. When the payments unit modifies its API, it publishes a new version, the old and new coexist for a defined period, consumers migrate on their own schedule, and an AI reader can flag contracts approaching end of support and identify consumers that have not migrated.

The value of a contract depends on what happens when it is violated. In a committee-based model, violations are discovered late: Team A finds that Team B's output no longer matches expectations when something breaks in production, an incident bridge is assembled, responsibility is debated, and the fix is negotiated across multiple meetings. In a contract-based model, violations are detectable, attributable, and resolvable: the contract specifies what the output should look like, so divergence is flagged automatically; the violation traces to a specific contract and a specific party; and the resolution occurs between two parties referencing a shared artefact rather than twelve people on a bridge call.

On a Tuesday at 10:14, the claims unit's monitoring flagged a contract violation: the payments unit's settlement API had begun returning timestamps in a different format from the one the contract specified. The claims unit lead sent the payments unit lead the contract clause, the expected format, and three examples of the divergent output. The payments unit checked its most recent deployment, found a library upgrade had changed the default timestamp serialisation, and deployed a configuration change by 11:40. No bridge call was assembled, no incident manager was paged, and no responsibility was debated, because the contract specified the expected output and the attribution was structural rather than political: two people, one conversation, eighty-six minutes from detection to resolution.

...

See also: Full contents · Preview chapters · Illusions of Work