Free
Illusions in the Boardroom
The board-level diagnosis
Illusions of Work
The operator manual
What the Competition Does Instead
What happens when a business process gets a real owner, a structured definition, and a machine that checks whether it matches production every week. The nine-month sequence, the costs, and the evidence that boards should expect.
Three months after the claims unit launches, Marcus is no longer spending Thursdays in alignment meetings.
He is sitting with the claims lead and two engineers when the weekly synthesis flags a discrepancy. The process definition says rejected claims are escalated to a human reviewer within twenty-four hours. The configuration in production says seventy-two. The setting was changed during an incident months earlier, logged in a ticket, and never reconciled against the definition.
Marcus knows exactly what would have happened in the old structure. There would have been a bridge call. Somebody would have requested an impact assessment. Two teams would have argued about ownership. A change window would have been discussed. A small administrative storm would have gathered around a forty-minute fix.
Instead, the claims lead verifies the discrepancy, an engineer changes the configuration, a second engineer checks the process definition, and the fix is live before lunch.
The machine noticed because the process was defined. In the old structure, the same discrepancy would have triggered a bridge call, an impact assessment, and a debate about ownership across teams. In the unit model, the person who could verify the problem sat next to the person who could fix it.
Marcus used to be the human glue for the claims process. He held together dependencies across teams, tracked exceptions in a spreadsheet, and knew which handoffs failed silently. He was good at it. The structure made his skill indispensable.
The new structure did not make Marcus irrelevant. It made his knowledge usable.
Instead of coordinating six teams that each owned a fragment of the process, Marcus helped the claims unit write down the process it actually runs: the states, the transitions, the exception paths, the places where the old organisation had learned to cope rather than fix. What used to live in his head now lives in a versioned artefact the unit can test against the system every week.
The claims unit is not a renamed squad. It is not a tribe with better branding. It is not a product team attached to a shared platform it cannot change.
It owns a business process from end to end.
That means the software, the business logic, the operational knowledge, the key data, and the accountability for outcomes sit inside the same unit. The process definition is maintained alongside the code. When the process changes, the definition changes. When the definition and the code drift apart, the synthesis catches it.
That sentence hides three hard-earned preconditions.
First, the process definition has to be structured and machine-readable. Not a compliance document. Not a slide. Not an elegant paragraph in a strategy paper. A definition with states, transitions, decision points, failure modes, and terms precise enough that a machine can compare them against what the system appears to do.
Second, the definition has to have an owner. Without an accountable owner, the document degrades into wallpaper within months. The machine can flag discrepancies all it likes; if nobody answers for drift, the drift simply becomes another report in another folder.
Third, the contracts between units have to be explicit, versioned, and testable. If the claims unit depends on a payment event, both sides need to know exactly what the event is, when it is delivered, and what counts as a violation. Without that, the old bridge call returns wearing a slightly more modern shirt.
The unit also publishes contracts to the rest of the organisation. Other units do not join bridge calls to guess what the claims process is doing. They interact through explicit interfaces and explicit guarantees. When a contract breaks, the problem is visible quickly and attributable immediately.
Explicit contracts and testable interfaces are what busy-work companies keep trying to simulate with meetings, dashboards, governance, and translation layers. The autonomous unit does not improve the coordination. It removes much of the need for coordination.
There is a simple executive test here. When the CEO asks, “Who owns claims?” the answer should be a name, a unit, and a process definition. Not a committee. Not three dotted lines. Not an explanation that starts with “it depends.”
Before any unit can operate this way, the organisation has to answer a prior question: which processes actually exist, who owns each one, and where do they touch?
That answer should not live in somebody’s private understanding of the business. It should live in a short artefact I would call the process catalogue. Think of it as an org chart for what the company actually does rather than who reports to whom. Instead of boxes with titles, boxes with processes. Instead of dotted reporting lines, explicit contracts and dependencies. The catalogue names the handful of value-creating processes that matter, assigns ownership, and makes the organisation legible to itself.
The process catalogue is a board-level artefact and a CEO artefact. Not because the board needs to read process minutiae, but because the board needs to know whether the company’s structure matches the thing it is supposedly governing. When the CEO asks “who owns claims?” or “who owns renewals?” the answer should come from the catalogue, not from an escalation chain or a six-person conference call.
For most mid-sized organisations, the catalogue is not long. Five processes. Eight, perhaps. Ten if the business is unusually sprawling. It changes rarely. The process definitions underneath it change more often because the units learn, discover drift, fix misconceptions, and revise their understanding as the system evolves. The catalogue is stable because the core business is stable. The definitions move because reality moves.
If you work in a regulated industry, you may be thinking: we already have process documentation. Audit has it. Compliance has it. The regulator has seen it. That is not the same thing.
Most compliance process documentation records what the organisation has claimed to do. A governing artefact records what the organisation commits to do and is attached to the system closely enough to be tested against it. That is the difference between paperwork and governance.
The test is simple. When an engineer changes the system, does the process definition change with it? When the definition says one thing and the code does another, does anybody know this week or next year? When the board asks who owns a process, does the answer come from a living artefact or from the person in the room who happens to have the most scar tissue?
In the busy-work organisation, the compliance documents and the running system coexist peacefully because nobody compares them. The documentation satisfies the audit. The system satisfies the customer, usually. The gap between the two grows one unreconciled change at a time.
The process catalogue is different because it is not there to satisfy the audit pack. It is there to govern the company. The pleasant side effect is that a governing artefact that is tested against the system tends to be much better compliance evidence than a compliance artefact that never governs anything.
The deeper change is not technical. It is social.
In the old model, engineers were outside the business and had to be brought into contact with it through tickets, priorities, product briefs, and OKRs. In the unit model, engineers are in the business because the process is their problem too.
They do not need a quarterly objective to connect their work to outcomes. The connection is obvious. If claims are escalating too slowly, the unit feels it. If the error rate rises, the unit feels it. If the customer journey degrades, the unit feels it. The feedback loop between code and consequence becomes direct.
The direct feedback loop between code and consequence is why the alternative feels faster even before it becomes faster. The organisation stops spending energy translating one reality into another. The people who understand the process and the people who change the system are finally in the same conversation.
The unit model also changes what management looks like. The unit does not need a separate narrative layer explaining whether it is healthy. Its health is visible in process outcomes, deployment speed, contract failures, remediation time, and the weekly list of discrepancies the synthesis found and the unit resolved. Management becomes less theatrical and more specific.
For the engineer, the change is practical before it is philosophical.
She no longer writes code against a specification produced by someone who does not understand the system. She writes code against a process definition she helped shape with the people who operate the process every day. The specification and the implementation live in the same universe. When one changes, the other is expected to change with it.
She no longer attends alignment meetings because there is much less to align. In the old model, a discrepancy between two teams would have triggered a bridge call, an impact assessment, and a release discussion across multiple stakeholders. In the unit model, the person who can verify the problem sits next to the person who can fix it, and the process definition tells both of them what the correct behaviour is supposed to be.
She no longer spends her week producing upward-facing narrative about whether the unit is progressing. The unit’s progress is visible in the operating numbers: claim resolution time, deployment frequency, contract violations, remediation speed, the discrepancy queue. These are not perfect measures, but they are attached to the work in a way a programme status summary never was.
She deploys more often because she is no longer negotiating across five invented boundaries before every meaningful change. The energy that once went into translation, sequencing, and choreography returns to the system itself.
For the executive, the change is more uncomfortable.
The old quarterly review was a narrative exercise. Each function arrived with a locally coherent story. The executive’s job was to absorb the stories, manage the contradictions, and leave the room with a version that could survive a board meeting. The new review is less soothing. It is an evidence review. Here is where the definitions drifted. Here is where the contracts failed. Here is what changed in the operating metrics. Here is what the unit is doing next.
This does not require the executive to become a technologist. It requires the executive to govern through testable ownership instead of interpretive fluency. The process catalogue tells her which processes exist and who owns each one. The synthesis tells her where the definitions do not match behaviour. The metrics tell her whether the boundary is producing results.
The discomfort is not incidental. The executive’s own claims become testable. The strategy can be compared against the process catalogue. The budget can be compared against unit outcomes. The gap between what the organisation says and what it does loses the protective fog that narrative used to provide.
The claims unit did not arrive fully formed. Here is what the first nine months actually looked like.
Week 1: The process was named (claims adjudication) and the owner was named (Anna, a domain expert with eight years in claims operations). The CTO and CEO jointly authorised the boundary. Nobody else was consulted, because consulting the functions whose authority the boundary displaced was the mechanism through which every previous attempt had stalled.
Week 3: Anna and two engineers produced a v0.1 process definition. It was imperfect and acknowledged as such, with several items flagged as “requires validation against production behaviour.” It was also the first description of the claims process that could be tested against the code.
Week 5: The first AI synthesis ran. It flagged an initial wave of discrepancies, roughly half of which were false positives caused by the definition being too vague and the synthesis being too literal. The team spent a week arguing about what the process actually did versus what everyone assumed it did. The arguments were occasionally heated. A handful of the discrepancies were genuine: the escalation timer was wrong, a triage path existed in code but not in the definition, and a business rule had been changed months ago without anyone updating the documented process.
Week 8: The first contract with the payments unit was formalised: what the claims unit sends, what the payments unit returns, in what format, with what time guarantee. The payments unit’s lead initially resisted (“we’ve never needed a contract before”), then saw the first contract violation detected automatically and resolved in hours instead of days.
Week 10: The first real incident under the new model. A batch job failed overnight and the synthesis flagged it at 7am. The unit lead looked at the discrepancy, checked the process definition, and realised the failure mode was not documented. She added it. The fix was deployed by lunch. In the old structure, the same failure would have been logged as a P2 incident, triaged on Monday, assigned to a team that did not own the process, and resolved in the following sprint. The unit resolved it in hours because the problem and the authority to fix it were in the same place. It was not elegant. It was fast.
Month 3: Claims resolution time had started to improve. The weekly synthesis was catching real drift rather than producing noise. Marcus, the programme manager who had held the process together for years, moved into the unit and began translating his knowledge into the process definition. Discrepancies he identified had been invisible to everyone else.
Month 6: The central compliance function requested a “lightweight governance overlay” on the unit’s deployment process. The CTO declined, citing the charter. The compliance function escalated to the CEO. The CEO upheld the charter. This was the moment the transition became real rather than experimental.
Month 9: The board saw the first quarterly evidence: resolution time materially improved, cost per claim down, continuous deployment replacing the old quarterly cadence, engineering attrition near zero. The evidence was specific, attributable, and produced by the operating artefacts rather than by a narrative assembled for the occasion.
The transition was not smooth. The first synthesis was noisy. The first contract negotiation was tense. The first governance confrontation was political. The results were also measurable, visible, and structurally different from anything the organisation had produced through its previous transformation programmes.
The transition to autonomous units is not free, and the simplified version of this argument should not pretend otherwise.
The transition costs money because shared databases, shared infrastructure, and shared authority are real things that have to be untangled. It costs political capital because every real boundary removes someone else’s informal control. It costs honesty because some of the roles created by the old structure become less necessary in the new one.
Marcus is the humane version of that story. His process knowledge had direct operational value, so he moved with the work. Not everyone will. Some coordination roles disappear because the reasons for them disappear. The honest choices are redeployment where the knowledge matters, or an honest separation. The dishonest choice is the holding-pattern title: change lead, transition adviser, strategic coordinator, professional delay.
The other cost is false autonomy. Central functions begin to creep back in with review gates, reporting requests, and optional meetings that are only optional if you enjoy losing arguments. Left alone, the old coordination layer regrows itself under service labels and enterprise standards. That is why the transition needs concentrated authority for at least the first year. Somebody has to protect the boundary while the results become visible.
False autonomy is the most common failure mode of the transition because it rarely arrives as overt opposition. It arrives as prudence.
A security review gate here. A mandatory reporting template there. A cross-functional check-in before a release. An enterprise architecture sign-off because this exception is surely too important to be left to the people who actually own the process. Each addition is individually defensible. None feels large enough to fight. Six months later, the unit is still called autonomous and is quietly spending a growing share of its time serving the central functions the model was meant to demote.
The board’s test is simple. Ask the unit lead, directly and in plain language, what percentage of the team’s time is now consumed by obligations imposed from outside the unit. If that number is rising, autonomy is becoming decorative. The organisation is paying the political and financial cost of structural correction while allowing the old coordination layer to regrow itself behind enterprise language.
Real autonomy is not the absence of standards. It is the presence of standards that bind through contracts and outcomes rather than through ambient permission-seeking.
The risk of creeping re-centralisation is also why the first move should be small. Do not announce an enterprise reinvention. Pick one process that matters, give it real ownership, write it down in a form the machine can read, and protect it long enough for the evidence to appear. When the evidence is visible, the politics change. Before the evidence is visible, the politics win.
Some readers will hear this argument as a demand to abolish coordination altogether. That is not the claim.
Coordination is real during a major incident that crosses genuine boundaries, when a regulatory interpretation has to bind across several units, when capital has to be reallocated between competing investments, or when a shared standard for identity, security, or customer data must apply firm-wide. Those are real enterprise problems. Pretending otherwise would be theatre in the opposite direction.
But those coordination needs are episodic and explicit. They should appear as decisions, standards, and interventions that serve the units, not as a permanent operating layer through which the units must route ordinary work. When the security standard becomes review theatre for every minor change, or the regulatory forum becomes a place where people without ownership delay people with it, the coordination layer has slipped back into being the product.
The test is simple. Does the coordination help two real boundaries interact, or is it compensating for the fact that the boundaries are still fake? The first is necessary. The second is the old structure in a new blazer.
If you want to know whether this model is serious, do not begin with an enterprise transformation programme. Run a contained test.
Pick one process that matters enough to be politically real and bounded enough to be owned. Name one owner. Write down the current process in a form the machine can read. Define the contracts to the adjacent units. Run the weekly synthesis. Then watch what becomes visible.
Track four things. First, how long the process takes from trigger to resolution. Second, how often the unit can change the system safely. Third, how many discrepancies the synthesis finds between the definition and the behaviour. Fourth, what share of the unit’s time is still consumed by obligations imposed from outside the unit.
Not all four numbers will improve immediately. The discrepancy count may rise at first because the unit can finally see what was previously hidden. That is not failure. That is diagnosis becoming operational. Failure is when ownership remains ambiguous, the contracts remain soft, and the unit spends the same week feeding the same coordination layer under a cleaner label.
The right opening move is not a grand transformation programme. It is one process, one owner, one boundary, and one unit that can produce visible evidence quickly enough to survive the organisation’s immune system.
The board should expect very plain signs that it is working: fewer meetings, faster changes, cleaner ownership, lower incident resolution time, and better retention among the people who care most about reality. The board should also expect discomfort, because the new structure makes claims testable in a way the old one did not.
That discomfort is not a bug in the model. It is the point.
Marcus’s old job existed because the structure was incoherent. His new work matters because the structure is becoming legible. The machine compares the claims unit’s definition against its code every week. When the two disagree, the discrepancy is flagged, attributed, and resolved.
The competitor does not need better programme managers. The competitor needs fewer reasons to need them.
See also: All articles · Illusions in the Boardroom · Illusions of Work