The Fix
The autonomous business unit, owning a real slice of value creation end to end, is the minimum viable structure for machine-readable reality. This chapter defines what authentic ownership means and distinguishes it from the simulated autonomy of squads and feature teams.
The payments unit has nine people. Two senior engineers, three engineers, a domain expert named Marta who spent twelve years in payments operations before joining the unit, a data analyst, a reliability engineer, and a unit lead who was previously a senior architect.
They own the payments process: premium collection, claims disbursement, broker commission payments, and refunds. They own the services that implement these flows, the data those services produce, and the contracts through which other units interact with them.
On a Wednesday morning, Marta notices that the refund process has a failure rate that has crept from 0.3% to 1.1% over the past month. She does not file a ticket with another team. She does not schedule a meeting with a product manager. Before approaching anyone, she checks the payment provider's changelog herself. She finds that a response format change was shipped three weeks ago, and she suspects the refund service's error handling has not been updated to match. She walks to the engineer who maintains the refund service and says: “Refund failures are climbing. The provider changed their response format on the fourteenth. I think our error handling is still expecting the old structure.”
The engineer checks the change history. Marta's hypothesis is correct: the refund service's error handling was not updated after the provider's API change. The fix is twenty lines of code. He deploys it after lunch. Marta verifies the fix against the business rules she knows: refund amounts must match the original premium within tolerance, the customer notification must trigger within the correct window, and the reconciliation feed must include the corrected transactions. By Thursday, the failure rate is back to 0.3%.
The total elapsed time from detection to resolution is less than a day. No one outside the unit is involved. No approval is required. No impact assessment is written. The fix is logged in the unit's change history with the cause, the resolution, and the time to detect. The AI reader will note the improvement in next week's synthesis.
In the old structure, this issue would have followed a different path. The domain expert would have noticed the failure rate in a monthly report. She would have raised it with the product manager. The product manager would have prioritised it against other items in the backlog. The backlog would have been reviewed in a sprint planning meeting. The work would have been estimated, scheduled, and assigned. The engineer would have needed access to a system maintained by another team. A change request would have been filed. The fix would have shipped in six to eight weeks.
By then, the company would have over-collected or under-refunded approximately € 40,000 in premiums. The customers affected would have called to complain. The complaints would have been logged as a customer service issue, not as a payments process failure.
In the autonomous unit, the problem and the solution live in the same place. The structure described in this chapter is a precondition, not an incremental improvement. Autonomous business units are the minimum viable structure for machine-readable reality, the units of truth from which the organisation's self-description is constructed, because their autonomy depends on the same thing AI requires: business processes defined precisely enough for both humans and machines to read, understand, and hold to account.
...
Continue reading in the interactive reader
Read this chapterSee also: Full contents · Preview chapters · Illusions in the Boardroom