Problem Statement
THE GAP HAS A POSTCODE. IT LIVES IN THE MIDDLE.
Business and IT in most insurance organisations are measured on fundamentally different definitions of success, funded through separate budget lines, and held accountable to timelines that rarely align.
Business measures success by outcomes — did the combined ratio move, did time-to-quote improve, did the product reach market before the window closed? IT measures success by delivery — was the system on schedule, within budget, and to specification? These are not the same thing. In most organisations, nobody is formally accountable for the distance between them.
What lives in that gap is not small. Requirements that were technically fulfilled but commercially inert. Integrations that functioned perfectly and connected the wrong data to the wrong decision. Transformation programmes that delivered everything that was specified and nothing that was needed — because what was specified and what was needed diverged somewhere during delivery and nobody noticed until the go-live celebration was over.
The underwriting team blames IT for not understanding the business. IT blames the business for not knowing what it wants. Both complaints are accurate. Neither is a complete diagnosis.
The complete diagnosis is that both sides have built structurally comfortable positions on opposite banks of the same river, and both are waiting for the other to build the bridge. In the meantime, the organisation keeps paying for the crossing.
What You’ll Learn
This piece provides a clear-eyed diagnosis of where the gap actually lives inside an insurance organisation — specifically in the accountability structures, incentive systems, and decision rights that were designed to separate business from IT and have never been redesigned to reconnect them. The reader will leave with three structural interventions that have demonstrably closed this gap in real insurance organisations, and a way of thinking about the business-IT boundary that makes the usual fixes look like what they are — attempts to patch a design flaw without acknowledging it is a design flaw.
SOLUTION
THREE INTERVENTIONS THAT ACTUALLY WORK
The organisations that have genuinely closed the business-IT gap in insurance did not do it with better slide decks or more inclusive sprint ceremonies. They did it by making it structurally impossible for either side to succeed without the other.
Intervention One — Shared Outcome Metrics
The single most powerful structural change an insurance organisation can make is to put business and IT on the same scorecard for programme outcomes. Not IT delivery metrics alongside business results. The same metrics, jointly owned, with both functions accountable for the same number.
A policy administration modernisation programme is not measured on go-live date and budget variance. It is measured on the underwriting expense ratio twelve months post-go-live, the number of product changes delivered in the first year on the new platform, and the reduction in time-to-bind for target segments. IT owns those numbers alongside the business.
This changes everything about how requirements are formed. When an IT architect knows they will be measured on the expense ratio, they ask very different questions in the requirements workshop. When a business sponsor's success is tied to the same outcome as the programme manager's, the quality of their engagement in those workshops changes materially.
Intervention Two — Boundary Roles Done Properly
Most insurance organisations have business analysts. Very few have business-technology translators. Even fewer know the difference.
A business analyst takes requirements. They document what the business says it needs, translate it into functional specifications, and hand those specifications to the development team. Valuable. Not sufficient.
A business-technology translator shapes requirements. They understand the insurance operation well enough to challenge what the business says it needs — not because they know better, but because they can see the difference between what the business is asking for and what the business is actually trying to achieve. They understand the technology well enough to know what is possible, what is expensive, and what will create technical debt that compounds for years.
The diagnostic question: when business and IT disagree on a requirement, does the business analyst facilitate the disagreement or resolve it? Facilitation is business analysis. Resolution is translation. The gap between those two is where most programme failures begin.
Intervention Three — Decision Rights Clarity
The least discussed and most consequential contributor to the business-IT gap is decision rights ambiguity. Most insurance organisations have never formally documented which technology decisions belong to the business, which belong to IT, and which must be made jointly.
In the absence of that clarity, every decision becomes a negotiation. Negotiations are slow, political, and exhausting — and in a programme context, they compound into months of delay that nobody can attribute to a single cause.
Business owns: what problem needs solving, what outcome defines success, what process changes the organisation will make.
IT owns: what architecture serves the requirement, what technology delivers the outcome, how the solution integrates.
Both must own jointly: scope decisions when budget is constrained, process-versus-system tradeoffs, and acceptable levels of technical debt in exchange for delivery speed.
A RACI matrix for decision types — built at programme inception, not retrospectively — eliminates a category of failure that most organisations have simply come to accept as normal.
IMPLEMENTATION TABLE
| Intervention | What It Looks Like in Practice | Effort | Time to Impact | Cost | Owns It |
|---|---|---|---|---|---|
| Shared Outcome Metrics | Business and IT on the same post go-live KPIs. Expense ratio, time-to-bind, product velocity jointly owned. | Medium — requires leadership alignment and comp structure review. | 6–12 months for metric movement. Culture shift in 3 months. | Low direct cost. Primary investment is leadership time. | COO and CIO must co-own or it will not hold. |
| Boundary Roles — Business-Technology Translators | Senior hybrid practitioners embedded in programme governance. Reporting line outside IT and business. | High — 12–18 month capability build. Most will need to hire externally first. | Visible within first programme where properly scoped. Typically 3–6 months. | Medium to High. Senior hybrid talent is premium cost. | Programme governance or Chief Transformation Officer. Not IT. Not business. |
| Decision Rights Clarity | Documented RACI for programme decisions. Built at inception. Reviewed at each stage gate. Covers Business / IT / Joint decisions. | Low to build / Medium to enforce. Two workshops to build. | Immediate reduction in decision latency. Faster sign-off within 30 days. | Negligible. Two workshops to build. | Programme Sponsor — senior enough to resolve disputes when claimed by both. |
What It Looks Like in Practice
Business and IT on the same post go-live KPIs. Expense ratio, time-to-bind, product velocity jointly owned.
Effort
Medium — requires leadership alignment and comp structure review.
Time to Impact
6–12 months for metric movement. Culture shift in 3 months.
Cost
Low direct cost. Primary investment is leadership time.
Owns It
COO and CIO must co-own or it will not hold.
What It Looks Like in Practice
Senior hybrid practitioners embedded in programme governance. Reporting line outside IT and business.
Effort
High — 12–18 month capability build. Most will need to hire externally first.
Time to Impact
Visible within first programme where properly scoped. Typically 3–6 months.
Cost
Medium to High. Senior hybrid talent is premium cost.
Owns It
Programme governance or Chief Transformation Officer. Not IT. Not business.
What It Looks Like in Practice
Documented RACI for programme decisions. Built at inception. Reviewed at each stage gate. Covers Business / IT / Joint decisions.
Effort
Low to build / Medium to enforce. Two workshops to build.
Time to Impact
Immediate reduction in decision latency. Faster sign-off within 30 days.
Cost
Negligible. Two workshops to build.
Owns It
Programme Sponsor — senior enough to resolve disputes when claimed by both.
ABOUT THE AUTHOR
The author has spent two decades working at the intersection of insurance business operations and technology delivery, including time embedded inside underwriting, claims, and actuarial functions before moving into technology leadership. The perspective in this piece comes from having occupied both sides of the gap described in the opening of this blog — and from the specific discomfort of recognising that the frustrations expressed by each side about the other were, with very few exceptions, entirely justified. The author no longer believes either side is the victim.
Conclusion
The business-IT gap in insurance has persisted for decades not because the people on either side of it are difficult or incompetent. It has persisted because the organisations housing that gap were designed in a way that makes it structurally natural — separate budgets, separate metrics, separate accountabilities, and a thin layer of process between them that was never built to carry the weight of genuine transformation.
Shared outcome metrics, genuine translation capability, and decision rights clarity are all within reach of any organisation willing to treat the gap as a design problem rather than a people problem.
The ones that have tried treating it as a people problem — more workshops, more communication training, more agile coaches — have the same gap they started with, along with the additional expense of the interventions.
What is required is not goodwill. Both sides generally have that. What is required is structure — the kind that makes it as difficult as possible for either side to succeed at the expense of the other, and as natural as possible for both sides to succeed together.
The bridge does not get built by waiting. It gets built by deciding, formally and irreversibly, that neither bank is the destination.
"The business-IT gap will not close the day both sides start talking more. It will close the day the organisation makes it structurally impossible for either side to succeed without the other."
