The Fix

Chapter 14: Units of Truth

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 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. It owns the payments process (premium collection, claims disbursement, broker commission payments, refunds), the services that implement those flows, the data they produce, and the contracts through which other units interact with them.

On a Wednesday morning, the domain expert notices 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 or schedule a meeting with a product manager; she checks the payment provider's changelog herself, finds a response format change shipped three weeks ago, and suspects the refund service's error handling was never updated to match. 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 is still expecting the old structure.”

The change history confirms her hypothesis. The fix is twenty lines of code, deployed after lunch. The domain expert verifies it against the business rules she knows: refund amounts must match the original premium within tolerance, the customer notification must trigger within the correct window, the reconciliation feed must include the corrected transactions. By Thursday, the failure rate is back to 0.3%.

The total elapsed time is less than a day, with no one outside the unit involved, no approval required, no impact assessment written. The fix is logged in the unit's change history with the cause, the resolution, and the time to detect, and the AI reader will note the improvement in next week's synthesis.

In the old structure, this would have followed a different path. The domain expert would have noticed the failure rate in a monthly report and raised it with the product manager, who would have prioritised it against the backlog. The backlog would have been reviewed in sprint planning, the work estimated, scheduled, and assigned, and because 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, and the affected customers would have called to complain, their complaints logged as a customer service issue rather than a payments process failure.

In the autonomous unit, the problem and the solution live in the same place. The autonomous business unit is a precondition, not an incremental improvement: the minimum viable structure for machine-readable reality, the units of truth from which the organisation's self-description is constructed. 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.

Autonomy is also the most abused word in technology leadership, and it fails in three ways. First, a leader announces that teams are empowered while none of the structural work has been done: no one has defined which processes belong to which units, or specified the contracts between them, so local decisions conflict and dependencies surface as crises. Second, the organisation decomposes along the wrong axis, dividing by data entity, technical capability, or functional layer rather than by business process. The output looks structured, but the boundaries do not follow how value is created: no unit owns a complete business process or customer journey end to end, every real action still crosses multiple units, and the coordination overhead matches the centralised model it replaced. The organisation is no more readable to a machine than before. Third, autonomy becomes a mechanism of avoidance: the leader points to the structure, and when outcomes disappoint the failure belongs to the teams, who should have coordinated better, while the design that insulates the leader guarantees failure even as it appears to enable success.

Diagnosing fictional autonomy is simple: ask whether the leader can describe the business processes the organisation operates. Not the capabilities, not the data domains, but the sequences of activity through which customers receive value. If the answer names six units that must coordinate to complete a single journey, the decomposition is wrong and the autonomy is fictional.

...

See also: Full contents · Preview chapters · Illusions in the Boardroom