My friend read the first article in this series: Engineering Built it. Now You Drive It. She works in pharmaceuticals, not software. Her reaction surprised me.

“This doesn’t feel new,” she said.

She was right. And wrong. Let me explain.

The familiarity problem

If you’ve worked in operations, logistics, manufacturing, or healthcare, Progressive Delivery does sound familiar. You already do phased rollouts. You already test in small batches. You already have safety checks before full deployment.

Pharmaceutical companies don’t ship a new drug to every pharmacy on day one. They run clinical trials. Phase 1. Phase 2. Phase 3. Then limited release. Then full market launch.

Manufacturing doesn’t retool an entire assembly line overnight. They run pilot lines. They test at one plant. They prove it works before scaling.

So no, Progressive Delivery is not brand new. The pattern is older than software.

What is new is that software teams need to find a way to do this while operating at faster and faster rates of production.

Who Progressive Delivery serves

Progressive Delivery exists for three people:

1. The engineer who wants to stop getting paged at 2am because something broke for everyone at once. The engineer who wants to move fast without breaking trust. The engineer who knows that staging environments never perfectly predict real world behavior. (Have you seen the internet lately?)
   
2. Business partners who depend on software working: marketing, sales, customer success, finance, operations. The people who need software to be reliable so they can do their jobs. The people who have been passive passengers on the big bang release roller coaster, holding their breath and hoping.
   
3. The person on the other end of the screen–the user. The customer who just wants things to work. The user doesn’t care about your deployment process. They care that the checkout button is where they expect it to be. They care that their banking app works. They care that the feature they were promised actually delivers value.

Why software teams and why now?

Here is the honest answer.

Software teams have spent the last 20 years moving fast. Really fast. Deploying dozens or hundreds of times per day. That speed created a problem.

But to understand why now, you need to understand the path that got us here.

A very short history of software delivery:

The Waterfall era (1970s–1990s)
This is a process designed for a time when software was tied to hardware. Engineers planned everything up front. Requirements. Design. Build. Test. Deploy. All at once. Big bang releases were the only option. It was slow (this process could take years!), but it matched the pace of business. They shipped software on a compact disc (CD). If something broke, they mailed a patch. Yes, mailed. As in postal service.

The Agile era (2000s)
Teams said: “What if we could update our software as we’re building it? Let’s work in small chunks and adapt as we go.” This was a cultural revolution. But the release at the end of each chunk? Still mostly big bang, with some smaller bangs. What changed is the rate at which they were delivering. Instead of annual releases, they’re sharing updates quarterly.

The Continuous Delivery era (2010s)
Now we’re cooking. The cloud has arrived and everyone is talking about it. Engineers don’t need to deliver apps on CDs, they could host services in the cloud. Teams deploy to production many times per day. Even still, deploying code to production means it’s also visible to everyone.

Progressive Delivery (now)
Finally, someone asked: “Why do deployment and release have to happen at the same time?” They don’t. Separate them. Release to 1% of users. Watch. Then 5%. Then 25%. Then everyone.

That’s the technical history. But the real reason progressive delivery is emerging now has less to do with software and more to do with the world.

The real reason: Future Shock

When we wrote the book Progressive Delivery, we kept coming back to Alvin Toffler’s Future Shock, published in 1970. Toffler defined future shock as “too much change in too short a period of time.” He argued that society was moving from an industrial era to a super-industrial era, and the accelerated rate of change would leave people feeling disconnected, stressed, and disoriented.

He was writing about society at large. But he could have been writing about software teams in the 2020s.

Consider what has happened in just the last 15 years: Software moved from your desktop to your pocket to your car to your refrigerator to your watch. Every company became a software company, whether they wanted to or not. A single bug can now break air travel for the whole world. Customers expect updates continuously, but they also expect nothing to ever break.

This is the software version of future shock. The rate of change is dramatically increasing, and many software development teams are still using release strategies designed for CDs and quarterly production cycles.

Why Progressive Delivery is the answer to Future Shock

You cannot slow down the rate of change. The market won’t let you. Your competitors won’t let you. Your customers won’t let you. But you can change how you handle the risk that comes with speed.

So what’s different now, and why can’t we continue to use the old phased rollout playbook?

First, the speed. Before 2000, software shipped on physical media. You had months (sometimes years!) between releases. That slow cadence gave you time to test, to plan, to catch problems before they reached customers. Today, teams deploy to production multiple times per day. The rhythm of delivery has accelerated past what traditional QA can keep up with.

Second, the environment. A CD is a known universe. The software runs on a predictable machine, with predictable inputs, in isolation. The cloud is the opposite. Your code runs alongside unknown services, integrates with APIs you don’t control, and interacts with real user behavior that no staging environment can simulate. The unknown unknowns are not edge cases, they are the mainstream.

Progressive Delivery is the answer to both problems. It matches the speed of modern development (deploy often, deploy fast) while adding safety rails for the complexity (release slowly, release to small groups first).

Progressive Delivery is not about moving slower. It is about moving smarter. It gives you a way to keep up with the accelerating pace of software without breaking everything (and everyone) along the way.

Alvin Toffler warned that too much change too quickly causes shock. Progressive Delivery is the shock absorber.

What Progressive Delivery helps you accomplish 

Separate deployment from release
Deploy means the code is on the server. Release means customers can see it. These used to happen at the same time. Progressive Delivery pulls them apart. You can deploy on Tuesday and release on Thursday. Or next week. Or to 1% of customers for two weeks while you watch what happens.

Shrink the blast radius
When something goes wrong in a big bang release, it goes wrong for everyone. Every customer. Every transaction. Every region. Progressive Delivery limits damage. If a bug slips through, it affects 1% of users. Not 100%. You fix it before most people ever see it.

Turn releases into experiments
Instead of guessing whether a feature will work, you watch it work (or not) at small scale. You get real data from real users. Then you decide whether to proceed. Marketing doesn’t have to commit to a launch date six weeks before anyone has seen the feature work in production.

Give non-engineers the wheel
Engineering builds the dimmer switch. But marketing, sales, customer success, finance, and operations decide when to turn up the lights. You have the business context. You know the customer risk. You should have control.

What this means for people who work with software teams

If you are in marketing, sales, customer success, finance, or operations, here is what changes:

You stop waiting. You no longer sit around hoping the big launch goes well. You have visibility into how the release is progressing. You see what percentage of users have the feature. You see if something went wrong. You can ask engineering to give you the controls so that you can pause or roll back features as you see fit.

You gain leverage. You can say things like “We have a Black Friday campaign next week. Can we put the promo code feature behind a feature flag so we can turn it off instantly if something goes wrong?” That is now a reasonable request, not a ridiculous one.

You become part of the feedback loop. Engineering needs to know what you see. A strange bug in the 5% canary? Tell them. A VIP customer who wants early access? Ask for it. A metric that needs to hit 15% conversion before you spend ad dollars? Define that. You are not a passive consumer of releases. You are a sensor network.

The bottom line

Progressive delivery feels familiar because the pattern is old. Phased rollouts. Small batches. Safety checks. Many industries have been doing this for a while. Early software development relied on these practices too, back when they shipped on floppy disks and CDs. Then the industry got faster and forgot its own safety habits. 

Progressive Delivery is the return of discipline, not the invention of something new. Engineering built the dimmer switch. Now you get to drive.