The hard part was never the code: a fireside chat with AWS

A fireside chat from FeatureOps Summit with Matias Undurraga Breitling, Enterprise Technologist at AWS and former Head of Product and Technology at Just Eat.

Most engineering war stories start with a bad deploy. This one starts with a phone call.

A customer is on the line with support. They have two kids, they ordered dinner an hour ago, they trusted the platform, and the food is not coming. That call, multiplied across thousands of orders at the dinner peak, is the thing Matias spent his career trying to prevent. Not because the code was hard to write, but because shipping change into a live business is hard to do safely.

We sat down with him at FeatureOps Summit 2026 to talk about what that actually takes.

Move fast without losing the steering wheel

Ask Matias what kept him up at night as a CTO and a Chief Product Officer, and it was never the technology.

Most of what kept me up at night was whether we could move fast without losing control. The business wanted to move faster. Product wanted to experiment. Engineers just wanted to ship. Operations wanted stability. And customers expected things to work all the time.

That is the whole job in one sentence. Five teams pulling in five directions, and a customer who only notices when it breaks. At Amazon the framing for holding it together is earning trust, and Matias is clear that trust runs both ways. Your internal teams have to trust the software as much as your customers do.

His takeaway is one that maps cleanly onto where the industry has landed. Writing code was never the bottleneck, and with AI it is less of one every month. The hard part is operating the change after it ships.

At Just Eat, a flag was not optional

In food delivery, everything moves at once. Customers, drivers, restaurants. Matias calls it a three-sided marketplace, and at peak a single change can ruin dinner for thousands of people. So the team built a rule into the culture: if you have a change, you wrap it in a feature flag.

No one would say “we’re going to roll this feature out without a feature flag”. And most of the features actually rolled out with the flag off. They weren’t enabled by default.

That last detail is the interesting one. Code shipped to production switched off, then enabled deliberately, on a schedule the team controlled. If commit number two in a hundred-commit pipeline was broken, they did not scramble to fix and rebase the other 98. They pushed forward with everything off, added a commit to fix it, and turned things on when they were ready, one at a time, watching the impact. They even had a name for it: a quarantine period, about an hour of actively watching KPIs and errors before a feature earned its place.

It did not slow them down. As Matias puts it, it was a facilitator, not a burden.

Measure the habit, not the click

This is the part product teams should sit with. It is easy to measure whether more people clicked a button in a session. It is much harder, and much more honest, to ask whether they came back two weeks later.

We didn’t live on clicks or on conversion rate on a small widget. What we wanted to achieve was a habit.

For Just Eat, that meant watching a fourteen-day reorder window. A feature that bumped conversion in the session but quietly hurt reorder rate was not a win. This is what we mean by full-stack experimentation: success is not the dashboard in front of the engineer right now, it is the larger business signal further down the line. Matias has a phrase for getting every team rowing toward it, “aligning the vectors,” and it is a good one.

FeatureOps is bigger than flags

Matias likes the term FeatureOps for the same reason a lot of practitioners do. It expands the conversation past the toggle.

A lot of companies are really good at launching features. They’re less good at operating those features.

His old team ran something called mission control: a group with playbooks, access to the live tests, visibility into errors, and a clear line from any incident back to what was released and what was enabled. Who owns this feature after it goes live? What metric proves it worked? Who holds the kill switch? Those questions, asked before the launch, are the difference between a calm incident and a five-hour one.

And he is honest about the unglamorous side. At one point the team did a full sprint just cleaning up feature flags, after a hundred thousand lines of code had accumulated where everything was on by default. Lifecycle is part of the discipline. Without ownership and cleanup, every flag is future tech debt.

The other thing he is firm on: flags belong in the back end, not just the front end. A button in the wrong place is annoying. A back end API returning the wrong result can take the whole application down. He has watched outages cascade when a dropped service met a wall of retries, front end retrying three times, gateway retrying three more, until the system effectively DDoSed itself and could not recover even after the fix. The flag is only half the story if the retries and caches around it are not designed with the same care.

AI is a multiplier, so bring your own kill switch

If two pull requests a week becomes twenty, nothing about that velocity reviews itself.

AI just adds a multiplier. If you have ten times more commits, who’s reviewing them? Who’s validating them?

Matias is not an AI pessimist. He has gone back to building, agents and all. But he gives them rules. One of his hooks: when an agent finishes a feature, it has to wrap it and prove the flag works, turning it on and off, taking a screenshot, verifying the behavior. For anyone who never wanted to write tests or create flags by hand, that resistance just evaporated. Tell the agent to do it.

His prediction for where this goes is worth chewing on. When everyone can build fast, choosing the right thing to build becomes the bottleneck. The constraint moves from engineering to judgment. Which is also why he keeps a SpaceX poster in his head: the old NASA cockpit had a hundred buttons, the SpaceX one is a single screen.

Customers don’t want a Christmas tree full of lights and buttons. Sometimes too much means we’re hurting customers.

The closing advice

We ended by asking what he would tell an engineer who wants the corner office someday. His answer had nothing to do with being the best coder in the room.

Learn how to operate software, not only how to build it. Stay close to the code, but get closer to the customer.

And the line that should go on a wall somewhere:

Tell me what you did for our customers. Don’t tell me you shipped a hundred features. Tell me how many orders, how you moved frequency, what KPIs actually impact the business. Those are your badges.

That is the whole argument for FeatureOps, told from the customer’s side of the phone call.

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