Sharing functionality across domains

In partnership with

It really seems as if insurance companies are at the forefront of platform evolution, although in some cases, the companies themselves have not recognised this. Perhaps it is because, although a regulated industry, insurance companies have more flexibility to innovate than other financial services.

Insurance companies often evolve in similar ways. It may be that someone set up an insurance startup. The startup develops one car insurance product and brings an outsourced dev team to build functionality for insurance quotes, billing and claims. All goes well; they get customers, and the startup becomes well-established in the car insurance sector. They want to apply the insurance domain knowledge they have built, so they expand their portfolio by again bringing in a dev team to add functionality and offer quotes, billing, and pet and car insurance claims. And then, having expanded, they add quotes, billing and claims for house insurance.

Engineers at clients who have followed this pattern sometimes complain that no one owns the platform. Any teams needing to add functionality for insurance types must make changes across all of the code. The issue is that people act as if they all own the platform.
Another higher-level issue is that the company is not making the best use of the systems they have already paid for by sticking to this project mindset, whether with external or internal dev teams. One way to deal with this might be to treat quote, billing, and claims as a platform that each Stream-Aligned team can choose to use.

Matthew Skelton, co-author of Team Topologies, thinks that quote, billing and claims may be platforms but that it is for the organisations to decide this.

If they do decide to build a platform, then "the org needs to "own" and steward the evolution of the shared capabilities, just as it would if those outsourced dev teams were internal teams - it's the same dynamic. The teams need incentives to share their innovations and allow a core platform to "harvest" them and re-common the capabilities beck for other teams to use."

Stefan van Oirschot recently gave a talk about a 'fictitious' insurance company called Parasol, which was also having issues. Although this company had built a platform, there were still issues stemming from the way insurance companies seem to evolve. The platform was in place, and there were 'stream-aligned' teams; however, the platform team was not delivering in terms of reliability and functionality.

The stream-aligned teams were mired in firefighting, and time to market took so long that the team never had time to look at tech debt. Time to market is a very important metric in this type of organisation—it means that you miss the bus and may lose customers. A coalition of the willing was formed around the claims customer journey, focusing on one customer journey and improving that 'top to bottom'. The teams decided to stop reinventing the wheel, remove the turbulence, and focus more on differentiation.

In a wider sense, the teams learned about colleagues' motivations and looked at what the other stakeholders needed. The C-suite needs to know what they are paying for. They needed to capture the hearts and minds of all stakeholders.

There exists a gap between: Stream-aligned teams who are dealing with high customer expectations and Platform - Keeping the lights on

Both have limited cognitive capacity

This issue is often - perhaps not always - dealt with by the stream-aligned teams having to 'reach down' and get too involved in the platform side. Platform teams don't often want to step up, and there is perhaps an issue there. In a later newsletter, I will look into how we need to look long and hard at ops and the need for a stable, supported base for the platform. This also reminds me of the ongoing problem of the empty silos in that; becasue we have got rid of ops and DBA teams, the stream-aligned teams end up having to do all the work even tho they lack the specialist knowledge necessary. Stream-aligned teams realise they are selling their own customers short by doing the job the platform team should be doing. Platform can't expect stream-aligned teams to be full stack. Ironically, since this was often said of DevOps engineers when they were more Ops than Dev, stream-aligned teams become jack-of-all-trades masters of none.

One of the reasons for this is that platform teams start too low in the stack. The platform team themselves need their own platform stack, a stable base upon which they can build. They need a complete platform they can consume. The platform group can then focus on delivering value to stream-aligned teams. This ties into the ongoing debate on whether Kubernetes suits most teams. It is definitely a power tool which needs to be supported and resourced effectively,

Stefan used a powerful metaphor: platform teams run out of energy because they start at a low level of the stack and must push through and go higher to deliver for the stream-aligned teams at the top. Once the platform team have pulled features up so they are working on a consolidated platform, you can then reach higher. This metaphor also works the other way. The more functionality that is 'pushed down' into the platform by stream-aligned teams, the higher the platform on which they can build and differentiate.

Instead of measuring the platform by how many features are added to the platform, instead measure it by how many features are delivered by the teams using your platform. As well as measuring stream-aligned teams on what they deliver, organisations should also measure what they recommon. It's interesting that the Foraging - Harvesting - Recommoning loop can work for one shared capability at a time. Once it has been done for claims, this can act as a model for other parts of the organisation.

Start learning AI in 2025

Everyone talks about AI, but no one has the time to learn it. So, we found the easiest way to learn AI in as little time as possible: The Rundown AI.

It's a free AI newsletter that keeps you up-to-date on the latest AI news, and teaches you how to apply it in just 5 minutes a day.

Plus, complete the quiz after signing up and they’ll recommend the best AI tools, guides, and courses – tailored to your needs.

Sign up to start learning.