Badass developers release on Fridays. Now there’s a book that explains why.

If you’ve ever bumped into us at an event, you’ve probably walked away with some form of Unleash swag that says, “Badass developers release on Fridays.” It gets a laugh, but we’ve also heard from a lot of you that it really resonates.

Whether you can release on a Friday says something about your entire approach to shipping software. Your feature flags. Your rollout strategy. Your ability to roll back in seconds. Your confidence that a change won’t silently break something for half your users over the weekend.

And if you need some more practical tips for up-levelling the badass meter in your team, now there’s an award-winning book that can help.

Progressive Delivery: Build the Right Thing for the Right People at the Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman doesn’t specifically mention our swag (they might be saving it for the revised edition). But it does answer the question: what does it actually take to release with confidence, any day of the week, without breaking things for the people on the other end?

The answer, it turns out, involves physics, wedding cakes, toddlers fighting, and squishy meat parts (the latter two are unrelated, thankfully). While I couldn’t bring you all the juicy metaphors in this short article, I’ve compiled some of the ideas that stuck with us. For the full picture, go read the book!

Making software we feel good about

The book starts off with an idea that sounds simple but reshapes everything once you internalize it. There are three distinct moments in the life of a software change:

• Deployment = when code arrives in the production environment.
• Release = when users can actually interact with it.
• Adoption = when users make it part of their workflows.

These are not the same event. They shouldn’t happen simultaneously. And yet most organizations still don’t separate them.

Continuous delivery solved the deployment problem. Agile improved the feedback loop. But neither framework addressed what happens after code lands in production: the question of who should see a change, when, and whether they’re ready for it. The authors put it brilliantly:

“We’ve gotten significantly better at shipping software, but helping people adopt that software and feel good about it…that’s where we need to do a lot of work.”

That gap is where progressive delivery lives. It extends the software development life cycle to include user adoption as a first-class concern. Not by slowing developers down, but by decoupling the pace of development from the pace of user exposure.

Developers keep shipping. Users absorb change at a rate that respects their context. This is also the core idea behind FeatureOps: treating the runtime behavior of your software, what’s on, for whom, and under what conditions, as something that deserves its own operational discipline, not just a deployment artifact.

As Dr. Cat Hicks notes in the book, “A successful software builder wants to create a successful, positive relationship to the change they’re introducing.” I couldn’t agree more. We’re not just deploying code. We’re introducing change into someone else’s life.

Technological jerk, because… science

The central metaphor of the book is borrowed from physics. Jerk is the rate at which acceleration changes. The third derivative of position. It’s the lurch when the subway starts, the moment when steady motion becomes a jolt. The authors use it to describe what users feel when software changes too abruptly. They call it “technological jerk.”

Once you have the term, you start seeing it everywhere. CrowdStrike pushing a breaking misconfiguration to 100% of their audience at once? A bank overhauling its login flow overnight? The Sonos app update so disastrous the CEO stepped down? Technological jerk.

One of my favorite lines from the book captures this beautifully:

“We can make machines that go unfathomably fast. What we can’t do yet is make machines that go unfathomably fast without killing us: the squishy meat parts of any technical system.”

Progressive delivery is how you absorb these jerks. Not by slowing innovation, but by building shock absorbers between the pace of engineering and the pace of human adaptation. The authors provide a roadmap for building those shock absorbers through a framework they call the Four A’s.

How to get straight A’s

The book organizes progressive delivery around four key ideas. This is what the authors call the Four A’s: abundance, autonomy, alignment, and automation. I would’ve called it the Quadruple A, but that’s probably why I wasn’t consulted.

The book then expresses the relationship of the A’s as an equation:

Progressive Delivery = (Abundance × Autonomy) / (Alignment × Automation)

Or, more simply:

Progressive Delivery = Developer Experience / User Experience

If that doesn’t make sense yet, hang tight.

Abundance

Abundance is about resources: cheap compute, elastic cloud infrastructure, open-source tooling, the disappearance of the old bottlenecks that used to make developers wait months for a server to be provisioned. The book traces this from the era when a growing startup needed millions just for infrastructure to today, where a single dev can build and deploy an application from a laptop.

Autonomy

Autonomy is about people making decisions on their own, based on the objectives of their task. It’s the ability to act without context switching or friction. For developers, it means the freedom to build, test, and deploy without unnecessary gates. For users, it means control over the pace of change and the ability to adopt new features when they’re ready. The book lists the tools and practices that enable this: Git, feature flags that separate release from deployment, feature flags that minimize the risk of trunk-based development, CI/CD platforms, microservice architecture, coding assistants, and a blameless culture.

Alignment

Alignment directs all of that energy toward the same goal: building the right thing for the right people. Without it, abundance and autonomy become chaos. The authors are clear about this: alignment is where the user enters the picture. It’s the “third loop” beyond DevOps (from Deploy, release, adopt), incorporating user adoption as a first-class concern alongside deployment and release.

Automation

Automation makes the whole system sustainable by removing repetitive toil and ensuring consistency. Canary deployments, ring deployments, observability-driven rollouts, and feature flag lifecycle management are all examples of automation in the progressive delivery sense.

What makes this framework different from yet another maturity model is that it doesn’t prescribe levels or stages. It gives you four lenses. If abundance and autonomy far outstrip alignment and automation, you’ll build features nobody uses and ship changes that break things. If alignment and automation dominate, you’ll know exactly what users want but be unable to deliver it fast enough. The balance is the point.

We need autonomous humans

Autonomy is about people, not just deployment velocity. This is where the book surprised me. I expected a technical argument about developer velocity. What I got was data rooted in burnout research, psychology, and leadership theory.

The authors draw on Christina Maslach’s work to argue that lack of autonomy is a core cause of burnout. They cite Daniel Pink’s Drive on intrinsic motivation. And they bring in the DORA Accelerate report, which found that “autonomy has additional benefits. It leads teams to voice their opinions about their work, the team, and suggestions to improve the work. This transparent communication helps improve organizational culture as well.”

They also referenced Google’s research on 180 engineering teams, which found that the single most important factor in predicting a high-performing team was psychological safety: feeling safe taking risks around your team.

And then the book says something that can be hard to swallow:

“The solution to this lack of safety is to make it safer to be autonomous, not to deprive people of the power to screw up. The power to screw up is the same as the power to make something better.”

FeatureOps and progressive delivery don’t remove risk. They make risk manageable. Smaller releases. Better feedback loops. Well-defined RBAC. Peer review. Audit logging. These aren’t constraints on autonomy. They’re what make autonomy safe.

Radical delegation: pushing decisions toward the user

I also loved the concept of “radical delegation,” borrowed from Admiral John Richardson’s description of US Navy practices. In a naval context, a commander delegates an objective to a captain: meet at these coordinates at this time. The authority on the ship belongs with the captain, but the responsibility for arrival still resides with the commander. Authority can be delegated. Responsibility cannot.

For software, this translates directly. Radical delegation means a customer success manager can turn on a new feature for a specific customer when the customer is ready. The authority to determine readiness belongs to the person closest to the user. But the responsibility for the feature working still resides with the engineers who built it.

The book identifies two core tenets that make progressive delivery work:

1. Release progression: progressively increasing the number of users who can see (and are impacted by) new features.
2. Radical delegation: progressively delegating the control of access to a feature to the owner who is closest to the outcome.

That second tenet is the one that reframes feature flags from a developer tool to an organizational tool. The flag isn’t just for the engineer who wrote the code. It’s for the product manager who knows when a customer is ready. It’s for the support lead who needs to toggle something off for a struggling account. It’s for anyone in the organization who needs to control what users see and when, without touching code.

But the book pushes this even further. Radical delegation doesn’t stop at internal teams. At its most ambitious, it reaches the end user. The book describes how Google launched Gmail Labs in 2008, letting individual users turn entire features on and off from their settings. Microsoft did something similar with the “Try the new Outlook” toggle. Atlassian lets users opt into new board experiences or stay in classic mode. In each case, the user is the one deciding when they’re ready to adopt a change. As the authors put it: “Progressive Delivery is the practice of delegating control to the user while retaining a clear vision and plan for the product.” That’s the full arc of radical delegation: from the engineer, to the product manager, to the support lead, all the way to the person actually using the software.

On the organizational side, this is exactly what we’ve built into Unleash through our ‘Open by default’ principle. Our approach has always been open by default: giving non-engineers the ability to operate features safely through clear interfaces, RBAC, and audit trails, while keeping responsibility with the teams who built them. The book gave us a name for something we’ve been building toward: radical delegation requires a feature management platform because someone needs to be able to flip a flag, target a segment, or roll out a change without deploying code. And that platform needs governance so that delegation doesn’t become abdication.

And why friends don’t let friends build feature flag platforms from scratch

The book is unambiguous about the role of feature flags in progressive delivery. They are the primary mechanism for separating deployment from release. They enable canary deployments, ring deployments, A/B experiments, kill switches, and user-segmented rollouts.

But the authors are equally unambiguous about the danger of treating flags casually. The lifecycle gets complicated fast. Release flags, operational flags, permission flags, kill switches: the number adds up:

“While it is possible to practice Progressive Delivery without a feature management platform, we don’t advise it…Operating at scale without a robust way to track all the flags in the system is a recipe for disaster. It would be like trying to track all the changes to a code base without a code repository.”

They illustrate this with the collapse of Knight Capital Group, which lost $460 million in thirty minutes, partly due to the reuse of a deprecated feature flag name during a manual server update. The warning is clear: “This is also a great example of why, when using feature flags, you should leverage a feature management platform to ensure visibility and consistency.”

And in modern microservice architectures, the problem compounds. Small teams iterate independently, which is great for autonomy, but it increases the need for what the book calls “a high-level view of the user experience across the entire workflow, regardless of how many microservices, applications, or platforms (mobile, desktop, IoT, etc.) are involved.” Without centralized flag management, you end up with flags scattered across services, owned by nobody, and understood by fewer.

The Sumo Logic case study is a cautionary tale of exactly this. They built their own feature flag system, accumulated so many flags it became unwieldy, and eventually had to rewrite the whole thing. The book notes they would likely choose a third-party solution today. If you’ve ever quietly regretted building your own internal flagging tool, that chapter will feel familiar.

FeatureOps is no longer optional

The book is full of excellent case studies, each one paired with the “A” it best illustrates. The GitHub chapter, focused on autonomy, hit close to home.

It tells the story of a company deploying to production over a hundred times a day as far back as 2008, using a feature flag system called Flipper. Sam Lambert, an early employee, explained why flags were so central:

“I think feature flags are essential for Progressive Delivery, for this way of continually deploying. Because it needs to be the actual gate for what people see. And then you need to be able to fill up behind the gate continually by shipping software.”

That phrase, “the actual gate for what people see,” captures the essence. The flag isn’t a deployment artifact. It’s a user experience artifact. GitHub’s entire culture was built around this separation: developers deployed autonomously, feature flags controlled who saw what, and ChatOps provided the alignment layer with every decision surfaced in chat so nobody was excluded.

The book calls this the foundation. We call it FeatureOps. The discipline of controlling what code does once it’s running. DevOps gets code to production. FeatureOps decides who sees what, when, and how to roll it back in seconds. As GitHub CEO Thomas Dohmke told the authors, this is no longer optional in the AI era:

“You have to do it, because otherwise you can never upgrade to the next model, because you’re never going to collect enough data in your internal testing to decide whether that new model is actually better than the previous model.”

So, should you release on a Friday?

So, should we ship new products and services on a Friday? Our answer, of course, is a resounding yes. The whole point of investing in process and tooling is that you no longer need to worry about when you ship.

“If you can’t ship on a Friday, and you can’t ship on the weekend, that only leaves four days a week to ship anything new. With Progressive Delivery, deployment freezes really shouldn’t be a thing.”

That’s the promise of progressive delivery. Not moving fast and breaking things, but moving fast because things are harder to break. Automated rollouts with metrics and safeguards, and instant rollbacks. These will be your new best friends when you start to embrace shipping on Fridays.

If you read this book and think “okay, but how do I actually operationalize all of this?” then let’s talk. The book describes the philosophy. We at Unleash bring the machinery.

Who should read the book?

Basically, anyone who builds, ships, or manages software. The authors assume some familiarity with CI/CD, DevOps, and cloud infrastructure, but it’s relatively high-level. It’s written for engineering leads, platform engineers, engineering managers, and technical PMs. Anyone who has felt the tension between shipping fast and shipping safely. Anyone who has been on-call when a release went wrong.

We love this book and can only recommend it. Full of great takeaways and vibrant metaphors throughout. You can feel the different voices of the four authors throughout, which gives the text a warmth that most technical books lack. This feels like it was written by people who truly care.

The book won the 2025 DevOps Dozen Best DevOps Book of the Year, and we think it’s very well deserved.

Pick up a copy. Maybe start a book club with your team, and let us know what ideas resonated with you.

 

---

 

Explore how feature flags enable trunk-based development, canary deployments, and automated rollouts with safeguards. Or learn more about FeatureOps as a discipline.

FAQs about progressive delivery

How does progressive delivery differ from continuous delivery?

Continuous delivery is about keeping code deployable at any time. Progressive delivery adds the question of who should see that code, when, and how to measure whether they’re ready for it. The book frames it as an additive evolution: specification-driven delivery plus Agile gives you test-driven delivery. Add operations and you get DevOps. Add automation and you get CI/CD. Progressive delivery includes all the former models, “the way a pearl encapsulates its former layers,” then adds two core tenets: release progression (gradually increasing the audience for a change) and radical delegation (pushing control of feature access to the person closest to the user).

What’s the difference between progressive delivery and FeatureOps?

Progressive delivery is the philosophy: build the right thing for the right people at the right time. FeatureOps is the operational discipline that makes it work in practice. Progressive delivery tells you why you should separate deployment from release and roll out changes gradually. FeatureOps tells you how: with feature flags, automated rollouts, safeguards, impact metrics, kill switches, audit trails, and lifecycle management. You can think of progressive delivery as the framework and FeatureOps as the implementation layer. The book describes the thinking. A FeatureOps platform like Unleash provides the tooling to operationalize it day to day.

What is a ring deployment?

A ring deployment is the practice of releasing software to increasingly larger groups of people as part of a rollout strategy. The book describes it as concentric rings: the first ring might be the development team itself, the second ring might go to 1% of users, then 10%, then everyone. At each stage, impact is evaluated before expanding to the next ring. Ring deployments are often managed through feature flags and work hand-in-hand with canary testing. The key idea is that each ring acts as a safety check: if something goes wrong, only a small group is affected, and you can roll back before the change reaches a wider audience. At Unleash we refer to this as gradual rollout.

What role do feature flags play in progressive delivery?

Feature flags are the primary mechanism for separating deployment from release. A feature flag is a conditional statement wrapped around a portion of code, where the condition state is stored in a database external to the running application. When the system encounters the flag, it retrieves the value and either executes the wrapped code or skips it. This provides near real-time control points in application code. Flags enable canary testing, ring deployments, A/B experiments, kill switches, and user-segmented rollouts. It is a foundational tool, but operating them at scale without a dedicated feature management platform is “a recipe for disaster. It would be like trying to track all the changes to a code base without a code repository.”

Is progressive delivery only relevant for cloud-native teams?

The cloud is the optimal environment for progressive delivery, but the principles extend far beyond it. Disney’s case study is a wonderful example: their teams apply progressive delivery to physical-digital hybrid systems, including ride software, MagicBands, and digital twins. The MagicBand team deliberately overloaded hardware with sensors they thought might be useful down the road, then progressively enabled features through software as real use cases emerged. The hardware was deployed once; the experience was released continuously. That’s a beautiful model for how to think about innovation in constrained environments.

And the possibilities keep expanding. Autonomous vehicles ship software to physical hardware that can’t be redeployed on a whim, but feature flags let manufacturers progressively enable capabilities, run A/B tests on routing algorithms, and instantly kill-switch a misbehaving feature without pushing a full OTA update. Medical devices, industrial IoT, embedded systems. Basically, anywhere the cost of getting a release wrong is measured in safety, not just user frustration, runtime control becomes even more valuable. These are some of the most exciting frontiers for progressive delivery because the stakes are highest and the payoff is greatest.

Unleash is built for exactly these environments. It runs in your cloud, on-prem, or in fully air-gapped infrastructure. Feature flag evaluation happens locally within your applications, so no user data ever leaves your environment. Whether you’re rolling out a new UI to millions of SaaS users or progressively enabling sensor capabilities on hardware in the field, the same core idea holds: control who sees what, when, and roll back instantly if something goes wrong.

What is radical delegation?

Radical delegation is one of the two core tenets of progressive delivery. Borrowed from US Navy command structure, it means delegating authority for a decision to the person closest to the outcome, while retaining responsibility with leadership. In software terms: a customer success manager can turn on a feature for a specific customer when that customer is ready. The authority to decide readiness belongs to the person closest to the user. The responsibility for the feature working stays with the engineering team. The book defines three aspects: who owns the control, what feature is being controlled, and what the constraints or limits of that control are. It requires a feature management platform because the person making the decision needs to be able to act without touching code.

Who coined the term “progressive delivery”?

James Governor, cofounder of the analyst firm RedMonk, coined the term in 2018 after conversations with Microsoft’s Sam Guckenheimer about progressive experimentation. The book Progressive Delivery is the first full-length treatment of the concept.

Who coined the term FeatureOps?

The term FeatureOps in the feature management domain was coined by Michael Ferranti at Unleash. While progressive delivery describes the philosophy of shipping the right thing to the right people at the right time, FeatureOps is the engineering discipline that makes it operational. With FeatureOps, every change is treated as reversible. Rollouts are progressive, observable, and guided by real production signals. Feature flags are essential, but FeatureOps is bigger than flags alone: it combines autonomous runtime control, progressive delivery, and observability so that speed and control remain compatible at enterprise scale.

 

---

Sources

Book: Progressive Delivery: Expanding the Scope of Deployment to Drive Business Value by James Governor, Kimberly Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, 2025).

Figures referenced from the book:

• Figure 0.3: Deployment vs. Release and Who’s Impacted
• Figure 0.7: Ring Deployment
• Figure 1.3: The Evolution of Software Development Methods