Structural Correction

Chapter 10: Units of Truth

The autonomous unit is the smallest organisational structure that can be held accountable for a complete business outcome. It owns its process, its services, its data, and its contracts. Without a single process owner, the AI reader has nothing to reconcile against.

The payments unit consists of nine people: two senior engineers, three engineers, a domain expert who spent twelve years in payments operations before joining, a data analyst, a reliability engineer, and a unit lead who was previously a senior architect.

Together they own the entire payments process, premium collection, claims disbursement, broker commission payments, and refunds, along with the services that implement those flows, the data those services produce, and the contracts through which other units interact with them.

On a Wednesday morning, the domain expert notices that the refund failure rate has crept from 0.3% to 1.1% over the past month. Rather than file a ticket or schedule a meeting, she checks the payment provider's recent release notes, finds that a response format changed three weeks ago, and suspects the refund service is still expecting the old structure. She walks to the engineer who maintains it: “Refund failures are climbing. The provider changed their response format on the fourteenth. I think our error handling still expects the old one.”

The engineer checks the change history and confirms she is right. The fix is twenty lines of code, deployed after lunch, and the domain expert verifies it against the business rules she knows: refund amounts within tolerance of the original premium, customer notification within the correct window, the reconciliation feed including the corrected transactions. By Thursday the failure rate is back to 0.3%. The entire cycle, from noticing the problem to verifying the fix in production, took less than a day, with no ticket, no meeting, and no dependency negotiated. That speed is the structural consequence of ownership. The structural correction is organisational design with technological implications, and it belongs at the level of board decision: a board should demand outcomes, not specify what the technology team builds. The operational detail follows from those decisions, not the other way around.

The payments unit is not a team in the conventional sense but a business unit organised around a complete process. The common service-owned model found in large software-dependent corporates organises teams around services instead: one team owns the payments API, another the refund service, another the commission engine, and no unit owns the payments process end to end. The process spans multiple teams, services, and data stores, and when something goes wrong it is reconstructed on an incident bridge from memory. No team can change it with confidence, because no team can test or reconcile it as a whole.

An autonomous unit owns the process end to end; its services, data, and contracts exist to implement that process and to define how other processes interact with it. The ambiguity that previously required translation disappears, because the unit decides what to build, in what order, and with what trade-offs in a single room, where the domain expert's understanding of the business need meets the engineers' understanding of the system with no layer to translate between them. The unit deploys independently, because it interacts with other units only through published contracts; it owns its data, which others reach through APIs, events, or data products; and it is accountable for outcomes, refund processing time, payment failure rates, reconciliation accuracy, commission timeliness, measured continuously.

...

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