273 days after request
The customer wanted to correct one number.
Felix was twenty-six when he first encountered her request.
Her motor insurer had carried forward an estimate of her annual mileage. The figure appeared on the renewal offer. It was wrong, and she wanted to correct it before accepting.
The contact centre could already make the correction. The website could not. A customer had to leave the renewal, telephone during opening hours, repeat the information to a handler and wait for a revised offer.
The contact centre took 250 calls a week just to correct mileage.
Nothing about this was controversial. Operations wanted fewer calls. Digital wanted customers to remain online. Underwriting already allowed routine corrections within defined limits. Compliance wanted the decision recorded. Finance agreed that paying somebody to re-enter information the customer had just attempted to enter was unlikely to become more economical at scale.
Technology estimated that making the field editable would take a few days. That was an accurate estimate for the page and an irrelevant estimate for the renewal. A correction had to invoke the right underwriting rule, produce a new price, preserve the old offer, update policy state, satisfy the appropriate controls and communicate terms the customer could legally accept. Those steps were implemented by systems owned by different teams. The teams planned independently, except when they needed to change anything together, which was often.
Nine months after the request entered the portfolio, the field remained read-only.
By then it had acquired a programme manager, an architecture review, a risk action and a monthly report to the steering committee.
The insurer could change something quickly in three circumstances. The change could remain inside one team's authority. It could be an incident serious enough to trigger emergency command. Or it could become a transformation, with a budget and a senior sponsor paid to assemble the necessary permissions.
The mileage correction was ordinary, cross-functional and worth doing. None of those routes covered it.
Felix's father always drove Toyotas and later a Lexus. He had no interest in production systems. He liked cars that started. The customer wanted the same kind of achievement from a field: that it should perform its ordinary function when she used it.
Felix's master's thesis asked why firms exist if markets allocate resources so efficiently. Ronald Coase's answer included the cost of finding the other party, negotiating the bargain and checking that it happened. A firm can put related work under common authority instead of buying cooperation again for every transaction. The thesis received 9 out of 10, which made him dangerously confident that the idea would survive contact with a company.
Toyota and, later, Amazon supplied the operating version. One made improvement daily work and stopped when the process revealed a defect. The other showed that teams owning software in operation could expose changes gradually and recover without treating reliability as the enemy of improvement. Neither was a template for an insurer. Together they changed what he considered normal.
He entered consulting with a fairly uncomplicated belief: a company should be able to improve its running system without first declaring an emergency or a transformation.
Eighteen months into his first consultancy job, he was assigned to a six-week diagnostic intended to explain why Technology was failing to deliver enough value.
Thirty-one interviews followed. Each function described its part of renewal clearly and, considered separately, reasonably.
Underwriting owned the rule but not the customer journey. Digital owned the journey but not the policy state. Operations owned the manual correction but not the software. Technology owned the software but not the priority. Architecture owned standards but not the outcome. Risk could stop the change without owning the time it spent stopped.
Product owned the roadmap.
The insurer had brought all these functions inside one company while leaving renewal outside any common authority. Every ordinary improvement still needed a fresh bargain among the holders. The transaction cost had returned. It came with no visible price because everyone was already on the payroll.
He called that fragmented authority. He would shortly learn that the phrase was not suitable language for a client.
Each group also had a plausible account of the delay. Digital was waiting for an interface. The interface team was waiting for an agreed event. Underwriting had supplied the rule but could not confirm how the old offer would be superseded. Operations had a manual procedure and therefore did not classify the issue as a service failure. The programme reported the work as dependent on architecture.
No individual account was obviously false. Collectively, they explained why the customer was still on the telephone.
Four management layers below the executive committee, a senior engineer named Elliot drew the actual renewal path across the back of a printed risk pack. He knew where the process state was stored, which service could alter it and why two systems disagreed about whether an amended offer had been accepted.
He drew for fifteen minutes before saying, “You probably shouldn't put my name on this.”
“Why?”
“It's been raised.”
“What was the response?”
“That we shouldn't hold up customer improvements for perfect architecture.”
He was not proposing perfect architecture. He was proposing that one owner should control renewal state and the means of changing it. Somewhere between his explanation and the steering committee, that proposal had become a request to rebuild the estate. Rejecting it then counted as commercial pragmatism.
“Why did you stop pressing it?”
“I haven't. It's in the risks every quarter.”
The issue was already in the quarterly risk pack, a bound document thick enough to hold a door open:
Cross-platform dependencies may affect delivery confidence.
The sentence was accurate, professional and almost entirely free of information.
The project had access to programme plans, organisation charts, committee papers and selected incident reports. It had no production access and no permission to examine customer cases from beginning to end. The restriction was described as appropriate scoping for an operating-model review. Looking at the operating model while it operated would apparently have made it a different sort of engagement.
The material showed the shape of the problem. The customer experienced one renewal. Inside the insurer, the same renewal had been divided into a journey, an underwriting decision, a set of services, an operating procedure, a control and a budget. Each part had an owner. Changing the whole required them to assemble a temporary owner from their combined consent.
The title on slide 37 became “Why Simple Changes Become Programmes”. Beneath the diagram, Felix wrote:
Fragmented authority prevents ordinary customer changes from moving with the decisions, systems and operating work required to complete them.
The sentence was short, accurate and explained most of the previous thirty-six slides. He was pleased with it.
On Friday afternoon, Marianne, the engagement partner, reached slide 37. She read it twice.
“Fragmented authority, Felix,” she said.
“Yes.”
“Whose?”
The diagram was still on the screen. “It's distributed across the functions.”
“I can see that. Who fragmented it?”
No one person had. It had emerged from old systems, reorganisations, controls, budgets, acquisitions and decisions whose original reasons had expired before their consequences.
“So it isn't their description of the problem,” she said.
“It's what I found.”
“In private interviews.”
“And in the decision history.”
“Which we haven't validated.”
She was not telling him the sentence was wrong. She was asking what kind of truth the consultancy could afford to place in front of the people paying for it.