How Visa decoupled deploy from release and made feature flags the default

Customer Snapshot

At Visa, deployment and release were the same event. Shipping code meant releasing it, with no way to expose a change gradually or pull it back without a redeploy. FeatureOps was not yet a concept the organization worked with, and that gap carried real risk on a platform where partners depend on every change behaving as intended.

A platform engineering team, working with Visa’s Developer Effectiveness group, set out to close that gap. They introduced Unleash, decoupled deployment from release, and turned feature flags from an unfamiliar idea into the org’s default practice.

Results

• Deployment and release are now separate activities. Teams plan a release strategy on its own terms, where the two words used to be interchangeable.
• Kill switches in production. A  misbehaving partner-impacting feature was disabled in seconds during a staged rollout, with no rollback or redeploy. That moment converted the skeptics.
• A built-in audit trail replaced forensic log digging for “when did this flag change, and in which environment.”
• Governed change. Engineers request a toggle, product approves and chooses when it applies, through Unleash’s approval flow.
• Pull, not push. After the pilot, teams asked to skip the queue, and other Visa product areas reached out to start their own rollout.

The challenge: no way to release gradually

Visa’s product platform had a capability gap. Deployment and release activities were tightly coupled, so the team had no way to roll a change out to a subset of customers or reverse it quickly if something went wrong.

“FeatureOps was an unfamiliar concept within our org, and deployment and release activities were tightly coupled. We wanted to reduce the blast radius and the risk associated with our feature delivery.” — Mark Jackson, Engineering Manager, Platform, Visa

The goal was to decouple the two, introduce gradual rollouts, and shrink the blast radius of any single change.

Why Unleash

Visa ran a POC across several platforms. Two things mattered most, and they pulled in different directions: the experience had to work for engineers and for the product people who own releases.

“The two things we really looked for were the developer experience and the release experience. What stood out was the intuitive UI that Unleash has. It considers both the product and the engineering experiences in the platform.” — Mark Jackson, Visa

That dual fit showed up immediately in the feedback. Product managers got control over when and how software releases. Engineers got control over deployment, and something less obvious but just as valuable: the confidence to touch code they used to avoid.

“Some of these are legacy areas with a massive blast radius that teams traditionally didn’t want to go into. With feature flags, gradual rollout, and the ability to rapidly roll back, those constraints have been removed. Engineers hate legacy code they can’t improve, so a tool that gives them the ability to do that is a big win.” — Gavin Lees, Senior Consultant Software Engineer, Developer Effectiveness, Visa

One piece of early feedback stuck with the team: a product manager on the pilot called Unleash the most transformative improvement they had seen in a decade of product management within the org.

The rollout: how Visa won over partners with kill switches

The team was deliberate about scope. They started with a POC, then a pilot with a single engineering team, watching feedback from both product and engineering and evolving the platform offering as they went.

Most of it went smoothly. Both engineers and product people got up and running on the Unleash UI quickly to create and manage flags, which Mark credits to the focused, intuitive interface. The one rough edge was managing the technical API keys, so the team built an in-house layer to reduce that developer friction.

The turning point was not a slide. It was a live save.

“One of the very first features wasn’t super risky, but it needed to work for the partner. During the staged rollout, something didn’t quite go right. Because it was behind a feature flag, we could turn it off pretty much straight away. The partner was blown away, and they said, ‘That’s how we want all our stuff done in future.'” — Gavin Lees, Visa

That sealed it. Anyone still on the fence got on board, and requests started coming in to skip the queue and onboard early. The standout use case turned out to be the one the team had underrated going in.

“We thought a feature flag as a kill switch might be a good use case. We didn’t initially realize it would be the standout case to start with. They’re encouraging us to adopt feature flags as our de facto practice within the org.” — Mark Jackson, Visa

The impact: control, governance, and a mindset shift

For a payments organization, governance is not a nice-to-have, and it is where Unleash earned trust.

“When strategies get added or changed, when flags get enabled in different environments, we can audit that. Something that traditionally would have taken forensic detective work digging around in logs, we can now see very easily.” — Gavin Lees, Visa

Product teams also lean on the approval flow: in controlled environments, engineers request a toggle and product approves it and chooses when to apply the change. The team built feature flags into their secure software development lifecycle from the start, involving their security review and architecture group early and defining a process for reviewing partially delivered features.

The clearest sign of success is in how teams now think. Decoupling deploy from release was the stated goal, and it landed.

“Teams now talk about ‘what’s our release strategy, how and when are we going to release this,’ whereas previously that was conflated with deployment and the terms were used interchangeably.” — Mark Jackson, Visa

“What’s changed is that teams are working backwards from the end. Before, they focused on getting in and building the thing. Now they think about the end game: what’s the approach to release, and how do we manage the risk around it?” — Mark Jackson, Visa

On metrics, Visa is honest that this was not initially a numbers exercise. Now that adoption is broadening, the team is starting to look at change lead time for feature delivery, along with the severity and rate of change failures.

Use cases they didn’t expect

Two patterns emerged once teams had the capability in hand.

A product delivery group made a major platform change, and the receiving partner asked for a staged rollout across four phases. Using Unleash strategies, the team turned the feature on for phase-one groups while everyone else waited for their turn, accommodating a partner-driven request that would have been an impossible mission before.

Another group needed to modernize a large, wide-ranging product made up of discrete chunks of functionality. The old plan was a risky big-bang rewrite released all at once. With feature flags, they can now modernize it one piece at a time.

What’s next

Visa is looking at standardizing release templates with its product management team, using reusable release strategies for predefined use cases. The team is also reopening a conversation that flags made possible.

“Before we had the feature flag capability, the conversation about trunk-based development just wasn’t an option. Now, when it comes up, it’s not a hard no. It’s ‘yeah, that sounds pretty cool, let’s explore that.’ There’s a shift in the vibe within engineering.” — Gavin Lees, Visa