Direct insurance agile transformation

Higher and more valuable delivery. A skeptic might argue that we just started breaking work into smaller pieces. But we didn't just break it into smaller tasks—we broke it into functional units that went straight to production. Every story was an independently deployable increment of value (no-estimate approach, value mapping), not a sub-task waiting on others. Nothing spilled over between sprints, individual work gave way to teamwork—and if it were just about dividing work differently, chaos and error rates would have increased. For us, it was the exact opposite: the number of errors dropped by 50%. The result is 2.5x more delivered, complete value increments, not just more individual tickets.

A fast and secure path to production. We could deploy anytime without downtime (CI/CD), so value reached the customer immediately—not just in batches at the end. This opened the door to continuous data collection and real-world feedback: we could see how the product behaved and how customers used it, allowing us to adjust it on the fly. The ability to react to change this quickly is not the industry standard in insurance—and it showed externally: Direct was perceived as a strong, efficient partner that external firms found easy and fast to work with.

New product in 3 months instead of 8. We shortened the entire creation process for a new insurance product—discovery, design, development, and release—from the historical 8–9 months to 3 months.

‍

You might recognize this

The company is growing. More people, more products, more systems. And somewhere along the way, a flexible organization turns into one where:

• a change in priority affects multiple teams at once — and no one can say what it will cost or what won't get done;
• everyone is focused on their own piece without an overall vision, so features are built, but no one is checking if they actually create value;
• the client receives an inconsistent experience across touchpoints (web, mobile app, broker, branch), because each application lives in its own bubble;
• there is no time left for feedback from the business or clients — the pressure for more features never lets up;
• collaboration between teams and agencies is strained — there is more waiting and handing off than actual delivery;
• quality takes a backseat, because as soon as you finish something, two more things are waiting in the backlog.

If you recognize yourself in any of this, you are not alone. This is not a story about a company that was doing something wrong — it is a story about a company that was growing and had to find a new way for people to work together to sustain that growth. And above all, it is a story about how to implement such a change from within, gradually, and without losing momentum.

‍

The starting point: two companies in one

In 2015, there were about 130 people at Direct Insurance. Within five years, it grew to two and a half times the staff and five times the revenue; three years later, hundreds more people joined, and an entire group was formed.

Growth is great news. The trouble is that an organization built for 100 people stops working for 400 — and no one can just issue an order saying, "from Monday, we work differently." It just starts to creak one day.

At Direct, things were grinding to a halt on two fronts. The company operated in two separate worlds: the process side (internal processes, digitalization), where analysts stood between business and development and where the feature cycle time stretched into months — and the product side, closer to the client, where we started trying something different: we appointed our first Scrum Master and Product Owner and put business and development on the same island, without intermediaries.

Otherwise, analysis, development, and product were separate disciplines, each with its own director. Accountability for the outcome was nowhere to be found. There was a lot of waiting and a lot of handoffs.
‍

The decision that defined everything else

We didn't have a mandate from leadership to "carry out a transformation." Yet we did it anyway — and the fact that we started from within, without a grand order, ultimately defined its entire course, its benefits, and one hard lesson.

Instead of redrawing the organizational structure, we empowered teams to determine their own way of working, setting the direction through practice rather than titles. In practice, this meant giving a product-focused team its own Product Owner, removing intermediaries between business and development, and letting the team own the entire customer journey — I break down the specific tools (matrix support, merging analysts, 50:30:20...) further in the 2023 section. It sounded subtle. But this is exactly where most transformations die, and it's worth saying why:

Change driven "only from the top" is quickly communicated, but people don't understand it or take ownership of it. Change driven "only from the bottom" has energy and understanding, but one day it hits a ceiling — it lacks the mandate and backing. For change to take hold, both paths must meet at some point.

We started from the bottom. In the crisis-filled summer of 2024, we hit that ceiling. This isn't a weakness in the story — it's its most important lesson, and I will return to it.

‍

2021–2022: Four teams, four paths, one breakthrough

As the company grew, the CEO gave the order: build more teams. We didn't know which direction to take — we suspected what worked better, but we hadn't measured it. So we made a reasonable compromise: we scaled both approaches simultaneously to four teams and started comparing them — using hard data (handover costs, waiting times, cycle time, rework) and soft data (do people enjoy their work?).

In one team, a breakthrough occurred. A strong Product Owner synthesized business needs and brought them to technically skilled developers. And the team realized a fundamental truth: they couldn't just "tinker" with one application. For a client to see their payments, for example, it has to be in the client zone, the mobile app, the broker's portal, and the internal system — four applications. The team had to learn to work on all of them. But the business knowledge behind it remained the same — they didn't have to learn it four times.

That was the moment: Value doesn't flow through a single application. It flows through end-to-end delivery across the entire company.

Out of those four teams, one "made it" — and the other three showed exactly what makes or breaks it:

• Team 1 — succeeded. A strong Product Owner carried the business knowledge and context, and the team learned to deliver end-to-end across applications. This is where the key insight about value across the company emerged.
• Team 2 — failed due to leadership. The leader became a bottleneck: the team didn't progress or learn, waiting instead for his decisions. Meanwhile, from the business side, he only received orders and goals without context or a "why." Without their own space and purpose, even capable people went nowhere.
• Team 3 — failed due to poor structure. It was composed solely of business analysts with no developers of its own. Development had to be provided by the fourth team — and it failed to deliver any measurable results to production. For a long time, it devised a "perfect solution" designed for an as-is state the company didn't want, instead of addressing future needs. Years later, everything was redone, and the supposedly perfect solution was scrapped.
• Team 4 — drowned in dependencies and operations. Because it relied on Team 3 for development, it was essentially juggling two backlogs. It never gelled as a team — the members remained isolated individuals, lacking focus and planning. Meetings dragged on, sprints were chaotic, and stories were endlessly pushed from one to the next.

A 25% success rate — is that low or high? For us, it was huge, because we quickly and painlessly found our direction, while also seeing exactly what to avoid. And then came the mandate: build more teams like this.

‍

2023: From one success to a system

One functioning team is not yet a transformation. To repeat the success on a large scale, we had to name the problems company-wide.

This time, however, we didn't go in without cover — and that is the fundamental difference compared to previous years. That one successful team wasn't just internal proof for us; it was an argument we could take to leadership. Based on it, the Board approved the concept of a new way of working and the division of the company into value streams and gave us the mandate to launch it fully — not as another local experiment, but as the official direction that both engineering and the business would take.

This was the moment when "bottom-up transformation" first met top-down support. And that is exactly why the subsequent workshops carried weight and why the business participated: it wasn't my private idea that I was trying to push on someone, but an approved company decision. I continued to drive it — but now with a mandate behind me, not against the current. Without that endorsement, the whole thing would have dissolved into daily operations.

We kicked things off with a two-day workshop for 100+ people and launched adoption in two directions.

In engineering — and this is advice I give to anyone afraid of a major reorganization — we took essential steps without redrawing the organizational structure:

• Matrix support: every developer remained in their technology but gained affiliation with a value stream and two people to help them — a technical leader (for growth in technology) and a "right hand" (the Product Owner's deputy, responsible for delivery). We avoided the two-boss conflict by having the backlog clearly dictate the work.
• Merging analysts into development: instead of an analysis team, a Low Code Development competency was created — requirements were transformed directly into functional solutions, not handover documents.
• The 50:30:20 rule: a framework for time management (new development / growth and technical debt / preparation). Not a whip, but a long-term average that protects both quality and people.
• Shift-left QA: quality as part of the team from the beginning, not the last link in the chain.

🔗 Detailed module: Engineering teams — matrix, "rakes," self-design scaling, and competency model

On the business side, we took a step that was ultimately much bigger than the changes in engineering: we split the entire company into four business segments (value streams) — claims, client care, and two commercial streams. This wasn't just a logical division on paper; each segment received its own backlog, its own goals, and its own team that delivered from start to finish. Instead of dozens of partial backlogs scattered across departments (and constant arguing over who has time for whom), four clear value streams were created, cutting across the entire vertical slice of the company — from business through analysis and development to deployment.

‍

We also taught the business the difference between a requirement and a need. This narrowed the scope for every development team to a manageable slice: you don't need to understand the entire insurance company — but you must understand this part, and be a partner to the business. It is precisely these four streams and their backlogs that the crisis of summer 2024 would later impact.

Running in parallel was one of the most technically demanding tasks—rebuilding the insurance company's core system during full operation, iteratively instead of a "big bang."

🔗 Detailed module: How to rebuild an insurance company's core while it's running

‍

Summer 2024: The crisis that tested everything

This is where the story takes a turn. In 2024, a new law on mandatory motor insurance came into effect—it drastically changed how contracts were handled for auto insurance, which was Direct's flagship product at the time.

The requirement fell into the backlogs of all four value streams at once—it affected claims, customer care, and both commercial streams (the B2B segment also handled cars). Each stream took its own piece. Yet, the topic formally had an owner—a stakeholder who brought the requirement and was supposed to hold the big picture across all streams. But they couldn't handle the role: individual adjustments were covered within the given streams, but no one was actually overseeing the whole, and everything ran in a "it'll get done somehow everywhere" mode. The problem escalated until it was almost too late, and we had to pull the emergency brake. It wasn't a system failure, but a failure of an individual in a key role.

At that moment, the new way of working was "taught a lesson." But the real cause wasn't the new model; it was that we hadn't fully completed the adoption on the business side—specifically: Product Owners hadn't yet transitioned from the role of "task assigner" to a strategic role, prioritization across streams wasn't ingrained, and key stakeholders from the board weren't maintaining the big picture. The process from the bottom up was complete, but it lacked a counterpart from the top down to support it—engineering, on the other hand, showed it was ready. It was uncomfortable and personally demanding. And it was exactly that ceiling: you can go far from the bottom up, but not indefinitely.

What happened next is the most important part—and it's easy to misinterpret. We took the topic and, within a few days, broke it down using story mapping—a technique that decomposes a large functional area into a map of specific user steps and tasks, ensuring the full scope is visible and nothing falls through the cracks. (We write more about this in our blog post.) Then came the sharp cut: for a few weeks, we merged the work into one common backlog, shortened sprints to one week, and focused the entire engineering department on a single goal.

At first glance, it looks like a typical crisis task force—"get everyone in line and manage them from the top down, week by week." And the form was indeed crisis management. But what made the difference wasn't the crisis management itself:

• People reorganized themselves. No one said, "you do this." Using story mapping, the engineers self-organized into new teams in a way that made sense for the backlog. You can't mandate that—a team either knows how to do it, or they don't.
• We benefited from two years of groundwork. The fact that 60 people were able to meaningfully reorganize in a single day and immediately start delivering end-to-end was just because, that they were no longer narrow specialists waiting for tasks. The crisis didn't create that capability—it just brought it to fruition.
• It wasn't a step back, but a leap forward. The merged backlog was a temporary response to a specific, bounded issue, not a new organizational structure. After the crisis, we didn't revert to four streams—we moved toward product teams.

In other words: it wasn't the directive that weathered the crisis, but the capability built by the transformation. CxOs know how to whip people into shape. What you cannot mandate is for dozens of people to organize themselves around a common goal overnight and deliver without waiting for instructions. That was the ultimate proof that the new way of working actually works—not a refutation of it.

Result: everything deployed to production on time within four weeks. Feedback from the market confirmed that Direct was one of the best-prepared insurance companies for the legislative change.

‍

2025: Product teams and proof of speed

Paradoxically, the crisis triggered the best in us. The company saw that development could be fast and seized the opportunity: to launch a brand-new insurance product (pet insurance) with a TV campaign at the turn of the year.

Creating such a product historically took 8–9 months. We had three.

We held a one-day customer journey workshop for 50 people and ruthlessly cut the scope based on a single criterion: the primary goal is to be able to sell the product — everything else is secondary. One Product Owner then held the main backlog and cooperated with the others; handovers happened from sprint to sprint, sometimes from day to day.

We delivered the product in three months. And a pattern emerged: a virtual product team with representatives from all affected teams in the organizational structure, which plans, builds, tests, and launches together — instead of each department handling its own piece only for things to "not meet up" later. The key shift: priorities no longer fall into departments in parallel, but into a product team that has all the roles and competencies together.

🔗 Detailed module: Pet insurance: a new product in 3 months instead of 8

💡A side discovery worth mentioning: a quick price tag on value. By learning to calculate labor costs at an hourly level and working with the sprint cost of the entire team (instead of individual man-day estimates), we were able to quickly assign a real price to any initiative. "This feature is estimated at 4 sprints, which means a real cost of 500k — do you really want it?" is a sentence that changes decision-making. And it’s not a given — many companies still resist measuring the cost of delivered value. For us, it finally gave the business hard feedback for prioritization: for every item, you could see not just "what it brings," but also "what it costs."

‍

April 2025: Flat structure — when change just catches up with reality