Shipping isn’t the finish line: a fireside chat with Allianz

A fireside chat from FeatureOps Summit 2026 with Cédric Radicia, a senior engineer at Allianz, with earlier stops at Expedia, Wipro, and a startup of his own.

There is a particular kind of project that teaches you more than any success could. For Cedric, it was migrating Expedia’s HomeAway over to the Vrbo brand. On paper it was straightforward. Flip the experience, show the new name, done. The code worked exactly as designed.

The customers had other ideas.

You can push the button and display the Vrbo brand exactly the way Expedia wants. But the customer says “no, I don’t want to go to that website”.

The technical migration succeeded and the business goal did not, at least not at first. A 1% test on mobile came back bad. People had a relationship with the old brand, and being moved somewhere new, even somewhere identical, broke it. Cedric reaches for the old Steve Jobs idea that people often do not know what they want until you show it to them, and adds the harder corollary: sometimes you show them and they still say no. The full migration took years to actually land.

That is the thread running through everything Cedric talked about. Shipping software and creating business value are not the same thing, and the gap between them is where the interesting work lives.

Flags turn opinion fights into experiments

Cedric has been doing feature flags since before the term FeatureOps existed, learned at Expedia, where the culture was simple: you do not deliver anything without an A/B test or a flag behind it. What he took from that is less about tooling and more about how teams argue.

This is the difference between a dev and an engineer. A dev just does what’s written on the ticket. An engineer says “no, I don’t fully agree”, maybe there’s something different we can propose.

The flag is what makes that disagreement productive. Instead of the loudest or most senior opinion winning, you ship two versions, run them for a couple of weeks, and let the data settle it.

In the end, who wins? The customer. Sometimes it’s the product’s idea, sometimes it’s the dev’s. But the customer decides.

Measure both sides, or you are guessing

Cedric is wary of any single metric standing in for success. He learned this watching teams optimize a conversion rate in a session while quietly hurting something that mattered more downstream.

At Expedia he worked in an open-plan space with TVs in every corner, running live dashboards that showed both the business signal of an experiment and the technical health underneath it.

If the dashboard is red everywhere, you click a button and roll back.

The point is the pairing. A faster product that converts worse is not a win. Lower latency that tanks revenue is not a win. You need the business metrics and the technical metrics in view at the same time, which is exactly what we mean by full-stack experimentation. As Cedric put it, there is no single right answer, but you have to keep control, and to keep control you need tools.

FeatureOps is an operating model, not a pipeline step

A lot of teams treat becoming more agile as a tooling milestone. Get CI/CD in place, automate the deploys, done. Cedric pushes back on that.

FeatureOps is more a way of working, a lifestyle. It’s about how we organize all the departments together to give the best customer experience. You can’t do that only in CI/CD.

His version of the practice is product, business, and engineering deciding together what to build and how to measure it, with the flag as the shared mechanism. Automation gets you speed. The operating model is what makes the speed safe and pointed at something worth doing.

AI changes the speed, not the discipline

When the conversation turned to AI, Cedric was measured rather than evangelical. More productive, yes. A reason to drop your guard, no.

You’re faster, that’s a fact. But you have to keep in mind how we did things before AI.

His framing matched something we keep coming back to: the software development lifecycle is the same with or without AI. What changes is velocity. So feature flags and the ability to deactivate something in one click matter more when you are moving faster, not less. He is honest that you can take an AI suggestion, say “yeah, go, go, go,” and ship a mistake. The kill switch is what lets you do that and recover.

Doing it inside a regulated enterprise

Cedric has worked across the full range, his own startup, scale-ups, a large US company, and now Allianz in Europe. The lesson about big regulated organizations is not technical.

You can convince a lot of people and still get blocked at the end, because it’s just not possible. Sometimes you need to find the decision-maker.

The work, he says, is communication: being able to explain why a capability provides business value when there are a hundred other things to spend on. He points to his own experience using Unleash on a claims application migration during his time at Wipro, where pushing a change without a rollback path simply was not acceptable. The answer was to migrate the application page by page behind flags, so there was always a way back. The technical problem was solvable. The harder part, as ever, was making the case and earning the room.

That is the version of FeatureOps worth taking away from Cedric. The tools are real, but the discipline is about staying close to the customer, measuring honestly, and never confusing “we shipped it” with “it worked.”

Cedric joined us at FeatureOps Summit 2026. You can watch the full session here: