For thirty years, the “build versus buy” debate was the persistent game of tetherball in the CTO’s office. It was a rational, if often heated, accounting exercise. On one side: the allure of ultimate control—software tailored perfectly to your unique business logic, free from the constraints of a vendor’s roadmap. On the other: the pragmatic realization that recreating wheels is a waste of talent. We bought SaaS because we wanted to offload the “undifferentiated heavy lifting.”

We weighed compute, storage, and networking against the total cost of ownership (TCO). We calculated the “maintenance tax”—the reality that you are responsible for the security, stability, and updates of that application for its entire natural life.

Then came Generative AI, and the math didn’t just change—it broke.

Today, we are witnessing the “SaaSpocalypse.” AI has significantly increased the speed at which developers can produce code, effectively tricking us into believing that the cost of building has plummeted to near zero. A VP of Engineering looks at a $200k/year SaaS bill for a feature flagging service or an observability tool and thinks, “My lead dev could prompt a replacement for that in a weekend.”

But that thought is a trap. It is a fundamental misunderstanding of what we are actually paying for when we “buy,” and a dangerous undervaluation of what it takes to actually operate software at scale.

The Deployment Delusion: Why AI Speeds Up Shipping but Not Value

In the world of Progressive Delivery, we have a foundational mantra: Deployment is not Release. AI is a world-class “deployer.” It can spit out a feature flagging service or a messaging app in seconds. But as I’ve argued before, moving bits to a server is the easy part. The hard part is the release—the controlled, observed, and staged rollout of functionality to users in a way that doesn’t break the business.

When you use AI to “build” a replacement for a specialized SaaS, you are optimizing for the “typing” phase of software development. But as Fred Brooks famously noted in The Mytdhical Man-Month, there is no “Silver Bullet.” AI addresses the accidental complexity (the syntax, the boilerplate, the CRUD operations), but it is powerless against essential complexity (the intricate, messy business logic and the high-stakes coordination required to keep a system running, and compliant).

AI-built software often lacks the “guardrails” that come standard in a mature SaaS. It doesn’t know how to handle a “thundering herd” problem. It doesn’t understand the nuance of cross-region latency. It simply does what it was prompted to do. You might have saved $200k on the subscription, but you’ve just inherited a million-dollar liability in “Day 2” operational risk. And this does not even consider what this does to your security and compliance posture. 

The Cognitive Toil : “Day 2” is Where SaaS Wins

What about the ongoing maintenance? If AI builds the system, it will pull open-source packages and services. You will need to regularly check the code for security, patch it, and ensure third-party integrations are maintained.

One of the most important frameworks for modern technical leaders is Team Topologies by Matthew Skelton and Manuel Pais. They argue that the most successful organizations are those that minimize the cognitive load on their “Stream-aligned” (product) teams.

When a product team is forced to build and maintain their own infrastructure tools because “AI made it easy to write,” their cognitive toil explodes. They are no longer focused on delivering customer value; they are focused on patching their internal billing system or managing the security updates for their DIY observability stack.

This is cognitive toil; or the “Day 2” trap.

• Day 1: You prompt the AI, the code is generated, the tests pass, and everyone celebrates the “savings” as you successfully deploy to production.
• Day 2: The API you’re hitting changes. A security vulnerability is found in an underlying library. The database starts locking up under a new load pattern.

SaaS vendors exist to solve Day 2. They are “Platform Teams” as a service. By paying that subscription, you are ensuring that your team stays focused on your mission, not on the plumbing. If your “AI-built” tool requires one-quarter of an engineer’s time to maintain, you haven’t saved money—you’ve just hidden the cost in your payroll.

Plummeting value of “Code”

If we sort out the quality and completeness aspects of AI code creation, the cost of creating new software plummets, and I can build a feature myself faster and cheaper. The value we get from a SaaS service is diminished from a purely feature-functionality perspective.

If the SaaSpocalypse comes and the value of any particular feature is reduced, what new value does a SaaS company bring to the table?

In this possible future, the shifting value will move from feature functionality of the product to the community that surrounds it. We’ve seen this movie before. OSS projects are only as successful as the community that supports them. For the non-OSS software company this represents a drastic shift in how you deliver value to the customer. Features still matter, after all you still need to be able to use the software to complete the task at hand, but the moat—what makes you stand out from all the other vendors and competition—shifts to your people, and the experience they provide. Your people—and not your technology—are the feature your customers value. 

Your developers still need to build (most likely using AI) to continue to optimize and expand the value you create for your customers. But in this brave new world that is no longer a defensible moat you can rely on. Increasingly, customers will look for how you respond to their feedback and support of their use and success with your products.

Human Connections are the New Moat

A universal feeling these days, for anyone who is not living under a rock, is the increase in frustration when you encounter a corner case. FAQs and chat bots are great when the problems you’re facing are common and anticipated. But what if your problem is not in the FAQ or covered by the docs? Welcome to the evil hellscape that AI has wrought upon the customer service industry. 

We all thought pre-recoded phone trees were bad in the 90’s, then AI chat bots showed up and just said, “hold my beer.” Large companies have been quick to use this slick technological wizardly to increase margins and reduce customer service staff, leading to short-term gains at the the cost of diminished customer good will. 

There are some companies that have navigated this well. They have kept human representatives available and made it easy to “escape out” of the standard chatbot or phone tree automation and mainstream troubleshooting to quickly reach someone who can solve a detailed, in-depth problem that the product didn’t account for.

So, what is the new moat? It’s Human Connections.

In her book Working in Public, Nadia Asparouhova discusses how the value of software is shifting toward the people who maintain it. This is even more true in the SaaS world. The real value of a vendor is the human feedback loop after the initial application is deployed to production.

Anyone who has ever built a product knows that the way you intended a technology to be used is rarely the way the customer actually uses it. Users are creative, messy, and unpredictable. They often operate in what I call the “Creative User Context.”

Here is a recent thread with some examples of creative context from last week: 

This is where AI fails. AI is built on the training data of the past—on the definitions we have already put into the system. It cannot foresee the unexpected ways a creative or frustrated user will break your system. It cannot “think through” a corner case that hasn’t happened yet.

The companies that will survive the SaaSpocalypse are those that realize Customer Success is the new Use Case. The value isn’t the feature; it’s the person you can call who can contextualize your specific “creative context”. It’s the feedback loop that helps you understand adoption patterns rather than just click-through rates.

This is going to be the new model in the future. We will see the rapid adoption of AI and automation technologies in products and services. But the companies that will rise above and continue to be sought after—the ones we are willing to pay for—will be those that actually have the ability to deliver the right value, to the right users, at the right time.

Conclusion: Knowing What “Good” Looks Like

The “build vs. buy” math has changed, but not in the way the AI evangelists want you to think. AI has made it easier than ever to build something, but it has made it harder than ever to build the right thing and keep it running.

As technical leaders, we need to stop being seduced by the speed of the “Day 1” prompt and start obsessing over the “Day 2” reality.

The moat is no longer the code. The moat is the human capacity to navigate the unexpected. It’s the expert knowledge of what “good” looks like. This is achieved through experience, critical thinking, and the feedback loops that turn a tool into a solution.

Before you decide to “AI-away” your SaaS bill, ask yourself:

Who is going to answer the phone when the “creative context” hits? Who is going to manage the cognitive toil of maintenance?

Who is going to ensure that your deployment doesn’t just move bits, but actually delivers value?

If the answer isn’t a dedicated, specialized team with a proven track record, then you aren’t saving money. You’re just buying a ticket to a very expensive disaster.

In the age of AI, the most valuable “feature” you can buy is the empathy of a human who has the ability and desire to help when the AI gets it wrong. Choose your dependencies wisely.

In physics, the rate of change in acceleration is called Jerk.  In software development, Technological Jerk is that jarring, motion-sick feeling users experience when the product changes faster than their ability to adapt. When you ship a “Big Bang” update, too often you’re not delivering value; you are delivering a shock to the system.

For years, we’ve heard the goal of “moving fast.” But speed without control isn’t progress, it’s a hazard. As we enter the era of AI-augmented development, the throttle is wide open. The question is: do you have the suspension system to handle it?

The Shift to e13n

To solve for Jerk, we have to treat experimentation not as a buzzword, but as a core technical constraint. We need a shorthand for it that reflects its complexity and its necessity. Let’s call it e13n—the 13 letters between the ‘e’ and the ‘n’ representing the heavy lifting of building, measuring, and learning.

Just as i18n (internationalization) ensures your app works across cultures, e13n ensures your app works for human behavior. It is the architectural discipline of building the “suspension” that allows you to accelerate smoothly—without the Jerk.

The New Abundance: Beyond Compute and Storage

When we talk about the strategic framework of software delivery, we focus on the Four A’s: Abundance, Autonomy, Alignment, and Automation. For decades, “Abundance” referred to the falling cost of compute and storage. We had plenty of “stuff,” but we had a scarcity of time—specifically, the engineering time required to build multiple paths for a single feature.

Historically, e13n was expensive. Building three versions of a feature meant triple the unit tests and triple the UI work. Many teams substituted “gut feeling” for data because the toil of building variations was too high.

AI has fundamentally changed the Abundance pillar.

Today, AI-assisted coding has collapsed the cost of variation. The “toil” of writing boilerplate and scaffolding UI components has dropped toward zero. We no longer have a scarcity of dev-hours to build experiments; we have an abundance of opportunity.

Practical Example: The e13n Manifest in Action

Imagine a high-friction checkout. Analytics show a 40% drop-off at the shipping stage. The “old way” would be to have a meeting, pick a new design, and force it on 100% of your users. That is a recipe for Jerk.

Instead, we use a structured e13n Manifest to guide our AI agents in creating variations:

1. The Hypothesis: Reducing form fields will increase conversion by 15%.
2. AI Scaffolding: We prompt our AI assistant to generate two distinct variants: a “Stepper” (multi-step) and an “Express” (single-page). The AI handles the repetitive task of mapping these different UIs to our existing backend APIs.
3. Decoupling with Flags: We deploy both to production behind feature flags. They are “dark.” We’ve separated technical deployment from the user-facing release.
4. Progressive Rollout: we show the variants to only 1% of traffic. We aren’t just looking at conversion; we are monitoring the “Blast Radius”.
5. Third Loop: we monitor both quantitative and qualitative feedback on how the variations are performing. 
6. Clean-up (now with AI!): no experiment is complete until we clean-up our lab space. Make sure to remove variations that you are not going to move forward with, ideally documenting that the experiment was tried and the outcome. This is another great use of AI to reduce toil.

The Third Loop: The System Health Dashboard

As a developer, you aren’t just responsible for the “Buy” button; you’re responsible for the whole machine. E13n isn’t just about UX metrics, it’s about system physics. When we run an experiment, we monitor three specific dimensions:

Solving for the “Leftover” Code: Post-Experiment Toil

The biggest objection to e13n is often technical debt. “If we build three versions, our codebase becomes a graveyard of losing ideas.” This is where the AI-powered cleanup comes in. In a Progressive Delivery model, once a winner is declared, the same AI agent that built the variants can be tasked with generating the “Decommissioning Pull Request.” It identifies the losing flag branches and strips them out. The advantage of building with feature flags is that removal of code wrapped in a feature flag is as protected as inserting code with a feature flag. AI ensures that the abundance of ideas doesn’t lead to a scarcity of maintainability.

The Goal: A Culture of Learning and Safety

If you are only using AI to write code faster so you can ship more features, you are just increasing the Jerk. You are accelerating a car that has no suspension. Eventually, you will hit a bump in user sentiment and the whole thing will fall apart.

The real power of AI is that it gives us the psychological safety to be wrong. When the cost of an experiment is low and the blast radius is controlled, your team gains the Autonomy to innovate without fear.

We have to stop treating “The Release” as a finish line. The finish line doesn’t exist. There is only the continuous process of Alignment—ensuring that the software we build actually serves the humans who use it.

AI has given us speed. Progressive Delivery gives us the steering wheel. And e13n provides suspension. It’s time to stop jerking your users around and start delivering with intention.

This discussion is a must-watch for anyone invested in the modern software delivery lifecycle. It provides a compelling vision for the next step after establishing CI/CD: building a system that is not just fast, but also resilient, adaptive, and deeply aligned with user experience.

In other awesome news this week, Progressive Delivery (the book) won the DevOps Dozen community award! Amazing.

We love this. 

However it’s also worth mentioning there is an upside down world to product delivery. Though it does not have to be scary and evil like in Stranger Things, sometimes it can be. This upside down is seen and entered when we make the decision to remove a feature or product. In software delivery terms, we refer to this as sunsetting. In the book we use the following description:

The reference paints a beautiful picture where we gradually remove features and products like a beautiful sunset providing a user with a delightful experience as the feature slowly sinks below the horizon. 

In an ideal world, the user is afforded the time and guidance to adopt the new workflow, migrate their data, and say goodbye with a sense of closure and completeness. They are then ready to embrace the new features, workflows, button colors (design) with all the excitement of a toddler discovering a glockenspiel. Because, as builders, we have hopefully built the new features to offer greater value, reduce toil, and increase joy for the completion of their task.

The road to innovation is paved with good intentions; and often the substrate underneath is the user experience that has been ripped away from the white knuckled clutch of a group that will recall the day the feature disappeared with greater scorn and longing than Author Dent when the Vogons destroyed Earth.  In some cases this can cause such strong emotions people will build entire websites dedicated to the devastation.

“Valid” Reasons to Sunset Software

The decision to sunset software is likely to be a point of contention, but here are some popular rationalizations:

• No one uses the feature: This is possibly the best rationalization that I have ever had for eliminating a feature/product. Of course the caveat is that ‘no one’ has to be validated to mean literally users = 0
• Cost to serve (CTS): The cost to provide the feature is too great. This could be as extreme as the cost to provide the feature is greater than the amount that users are willing to pay, but more likely means the business is not meeting the target for margin on the feature and is seen as a drag on the business.
• Code is harmful or broken, and too costly to fix: This often occurs when external dependencies change. Examples of this are a deprecated API, SDK, or protocol (TLS, I’m looking at you).  
• Newer features or workflows: This is unfortunately the most common rationalization and often presents the greatest challenge for positive user experience. The goal is usually to provide more efficient methods to reach the same outcome. However, without proper preparation and planning for the transition, users often feel the ‘new’ experience is not an improvement.

Regardless of the reason you may have for sunsetting the feature or product, there are ways to reduce the impact and harm to your users. 

Staging the Sunset: A Communication and Observability Framework

It is important to acknowledge that for some people in some cases regardless of your best intentions, sunsets will be difficult. People can become dependent on a feature or workflow and as builders we may not always have a full understanding of how users have creatively adopted our software. But we can use tools to observe and measure usage and even infer the user experience. 

Observability tools (Honeycomb.io, Datadog, Dynatrace, etc.) can provide valuable insight about the frequency of use of a particular workflow or portion of code. Even providing insight into the latency a user experienced or the percentage of users that start a workflow and never finish it. Instrumenting features to gain this type of insight into user behavior allows for more informed decisions around which parts of your product or service are most heavily utilized.  These are likely the parts of your code you should be most cautious about changing or features you should do the most planning for when updating or removing.   

Once the decision has been made to remove a feature or End Of Life (EOL) a product, the most important step is to communicate with your users. Ideally, you plan the communication in stages that map to a gradual progression of feature sunsetting.  

A common framework for this progression looks like this:

Starting from General Availability (GA) when your feature or product is available to everyone the first step in sunsetting is to stop selling the feature or product. This is also a great time to communicate the planned timing and progression of the rest of your sunset or EOL process. The following stages are End of Support and then removal of code. 

For features and products with established user base or Enterprise scale customers there is often an Extended Support period required depending on contractual obligations or customers that are willing to pay increased rates to avoid moving to a new product or workflow. 

At each stage communication is a superpower in maintaining positive user opinion. And your observability tooling is the key to understanding actual usage and which users/customers may require additional communication to help them move to the new version or reminder of the scheduled end of the functionality. 

The type of communication will vary based on the type of software you’re building and the expectations of your users. For Enterprise software this could be email and a call to the customer from an Account Executive. But for a video game this could be an in app message or channel broadcast on a Discord server. The key is to know your users and how best to communicate. In the case of sunsetting, it is best to assume that there will always be users that need a little extra incentive or nudge to move to the next version or new workflow. Communicating directly with those users can help them understand the urgency and also allow them to feel valued. 

Technically, it is just Rayleigh Scattering

Sunsets in nature are so amazing due to a physics principle known as Rayleigh scattering. This is the scattering of light by particles much smaller than the light’s wavelength (like atmospheric molecules), causing shorter blue wavelengths to scatter more than longer red ones, this means that during the day the sky appears blue a at sunrise and sunset as more of the blue wavelengths are scattered the sky appears more orange and red.

To achieve the equivalent moment of zen on the technical side of your software sunset, feature flags can provide an excellent mechanism of feedback and control that using the inverse of the process for rolling out a new feature you can progressively remove access to a feature or product to a select cohort of users. 

Leveraging a Feature Management platform (LaunchDarkly, Statsig, Harness, etc.) you can integrate the progressive removal with observability tooling as well as Marketing tools for communicating with your users. This also has the added value of providing visibility across teams internally to understand what a user is experiencing at a particular stage in the feature removal.

Green Flash! (with the right conditions)

While some software is worth the investment to keep running without changes, most software is not. Changes in hardware, operating systems, integrated applications, or just people stop coming to your store to rent VHS tapes. As software has eaten the world, the rate of  change is only accelerating and it is increasingly difficult to find aspects of our lives not impacted by software.

When the sunset process is handled with meticulous care—when you have successfully guided your users to the next version and minimized harm—you achieve an outcome as rewarding and rare as a meteorological wonder. There is a meteorological phenomenon called a ‘green flash’. As the last sliver of the sun drops below the horizon there is a flash of green light due to atmospheric refraction. It is as breathtaking as it is rare.
If we take the time to observe and communicate with our users we can create the right conditions for them to appreciate the old version and embrace the new—a green flash sunset.

In a recent conversation, we reflected on the most memorable tech jerks of 2025. These ranged from frustrating platform overhauls to unexpectedly positive shifts in how we interact with technology. Below is a summary of our discussion, highlighting the good, the bad, and the lessons learned.

The Bad Jerks: When Change Feels Like a Step Back

Windows 11: The Upgrade Nobody Wanted  

Heidi kicked things off by calling out Windows 11. Despite Microsoft’s push for an “AI-enhanced” experience, over 500 million eligible users have refused to upgrade. For many, especially corporate users and gamers, Windows 10 still works just fine. The perceived lack of meaningful improvement—coupled with significant UI changes and compatibility concerns—has created a massive adoption hurdle. As James noted, this isn’t new for Microsoft, but it’s a stark reminder that users won’t move unless the value is clear. 

HBO Max’s Identity Crisis

Kim shared her frustration with HBO’s streaming service, which has rebranded and relaunched multiple times in recent years. Each transition required downloading a new app, losing watch history, and retraining recommendation algorithms. The final straw was the loss of content and a clunky, slow interface. Forced migrations with no continuity are a classic jerk—users are left feeling penalized for a change they didn’t ask for. (Read more.)

British Gas’s “Smart” Meter That Wasn’t 

James recounted a personal experience with British Gas, which installed a “smart” meter that failed to connect to the network right out of the gate. The installer casually mentioned that connectivity issues were common—effectively admitting they’d shipped a brick. It’s a prime example of how overpromising and under-delivering can erode trust, especially when the fix involves navigating a cumbersome support process.

Solar Panel System Hostage Situation  

Adam described a solar panel nightmare: his provider, SunPower, went bankrupt, leaving him with a broken inverter and no support. He was forced to migrate to a new system by Enphase, the original equipment manufacturer, to regain functionality and data access. While the new system works better, the transition was involuntary, costly, and stressful. It’s a jerk caused by ecosystem fragility and poor customer continuity planning.

The Good Jerks: Change Done Right

Gemini’s Gentle Integration  

Kim pointed to Google’s Gemini as an example of a well-managed rollout. On Android and in Google Workspace, AI features are introduced as opt-in enhancements—summarizing emails, improving documents, or assisting with search—without forcing the change. Users can ignore or disable them. This respectful, user-controlled approach reduces friction and encourages exploration rather than resistance.

Cycloid’s Feature-Flagged AI  

James highlighted Cycloid, a platform provider that built an MCP (Model Context Protocol) server to bring AI into its internal developer platform. Crucially, they placed the feature behind a flag. Nine out of ten on-prem customers chose to leave it off—a clear signal that enterprises are cautious about AI in sensitive environments. By letting users decide when to adopt, Cycloid preserved trust and avoided a potential jerk.

Slack’s Spooky Seasonal Fun  

Heidi praised Slack for its Halloween-themed “Spooky Slack” options—customizable icons, colors, and backgrounds that were entirely opt-in and automatically reverted after the holiday. This temporary, playful change acknowledged that users sometimes want novelty without permanence. It’s a small but thoughtful example of progressive delivery in action.

mRNA Vaccines + ML: A Jerk That Saves Lives 

Adam brought up mRNA vaccines and how they’ve been impacted by advances in machine learning (ML) as a positive technological jerk with monumental impact. Initially accelerated during COVID-19, the technology saw breakthroughs in 2025 for cancer treatment. This rapid, life-saving acceleration demonstrates that jerks aren’t inherently bad—they can represent transformative progress when the value is profound and well-communicated.

The AI Jerk: A Double-Edged Sword

AI dominated our conversation as both a source of good and bad jerks. 

OpenAI’s Model Rollouts often feel like a rollercoaster—initial excitement followed by backlash when models behave unpredictably (e.g., “grumpy” GPT-5.2). James noted that evals (evaluation frameworks) and tools like Statsig (recently acquired by OpenAI) are becoming essential for measuring and mitigating AI jerks before wide release.

Google Search’s AI Overviews have rewritten the rules of SEO and content discovery. While some users appreciate quicker answers, creators and publishers face an existential challenge as clicks decline. As Heidi put it, “We’re eating the seed corn of future knowledge.”

AI Slop and Misinformation are now pervasive, but as Kim reminded us, “slop” existed long before AI—search engines have always battled low-quality content. The difference now is the speed and scale at which AI can generate and amplify it.

Lessons for Managing Jerks in 2025

Our discussion reinforced core principles from Progressive Delivery:

1. Give Users Control. Whether through opt-in features, feature flags, or rollback options, choice reduces friction.
2. Test Before You Ship. Avoid “shipping bricks” by validating functionality and user experience early.
3. Respect Different Adoption Speeds. Enterprises, individuals, and industries move at different paces. Allow for gradual uptake.
4. Communicate Value Clearly. If users don’t understand why a change is beneficial, they’ll resist it.
5. Embrace Temporary Changes. Not every innovation needs to be permanent. Seasonal or experimental features can delight without disrupting.

Share Your Tech Jerks!

We’d love to hear about the tech jerks you’ve experienced in 2025—good or bad. How did they affect you? How could they have been handled better? Your stories might even feature in a future podcast or blog post.

Let’s continue the conversation. After all, in a world accelerating faster than ever, managing jerk isn’t just a technical challenge—it’s a human one.

—

This article is based on a conversation from the Progressive Delivery Third Loop podcast. This series will be launching soon, stay tuned for more info.

So we were really excited to give a talk at IT Revolution’s conference, the Enterprise Technology Leadership Summit. It gave us a chance to lay out our vision of what Progressive Delivery is, and what it may be in the future.

What does it mean to get the right thing to the right person at the right time? How do we build teams that can break the silos separating software makers from users? How do we show that consent, accessibility, optionality, and humanity are a crucial part of the software story? We don’t have all the answers, but have a listen here:

If you want to know more, pick up the book!

ETLS talk Transcript

Adam Zimman: All right. We are here to talk to you today about progressive delivery. And contrary to my eldest child this is not about a book on liberal birthing. instead, we’re talking to you about the next iteration of the product development lifecycle. specifically thinking about how you build the right thing for the right people at the right time.

So there are actually four authors to a book that we recently wrote. Three of them are here before you. The fourth one is currently in London so he will not be joining us today. but myself, I’m Adam Zimman.

It’s a pleasure to be here with you today.

Kim Harrison: I’m Kimberly Harrison.

Heidi Waterhouse: I’m Heidi Waterhouse

Adam Zimman: And our fourth author is James Governor.

So we came together about seven years ago when we started to notice some patterns in our industry. Who here has ever used an application or any device that actually has software and experienced the creator, the manufacturer of that device or the owner of that application making a change that they were not prepared for ?

Heidi Waterhouse: Adam.

Everyone loves change.

Everyone loves it when their phone does a new thing.

Adam Zimman: Exactly. I completely concur. Everyone loves change.

Heidi Waterhouse: All the time. All the time. Every day.

Adam Zimman: And this is one of those things where we’ve talked a lot already today. And I’m sure you’ve been to more than one, talk in the past, decade hearing about how you can ship faster, how you can remove bottlenecks from your development life cycle. Who’s been to one of those talks? Maybe one. One. Yeah. It seemed like a good idea at the time, didn’t it?

Alright, so we think that there’s actually something missing, with regards to all of this. Increase in pace and increase in change. First off, it’s the recognition that change is hard, right? Change is hard for all of us. Now there’s a caveat to that. There are some things, some changes that we personally want.

That we will push for, we will fight for, we will work for, but that same change is not necessarily going to be appropriate for everyone, right? A good change for me may not be a great change for you, right? But it’s really hard to know who fits into which category, which segment of your user base. So one of the things that you need to understand is that there’s this concept in physics.

So my background is in physics. There’s this concept that I feel like captures this perfectly. It’s actually in physics, it’s called jerk. All right.

Heidi Waterhouse: We wanted, to name the book Jerk, but we decided to be nice.

Adam Zimman: We were told by our publishers, thank you, IT Rev, that, maybe that would be an awkward thing for you to hand a book called Jerk to Your Boss and say, I think we should talk about this, which we had to concede that was probably true. but the concept of jerk. In physics and also in the context of the book and how we talk about it for progressive delivery is jerk is actually the third derivative of position. For those of you that don’t recall your college physics or didn’t take college physics, because that sounded like a horrible idea, ultimately this means that it’s the change in your rate of acceleration, right?

So think about that. If acceleration is your change in velocity, right? You’re starting to move faster, right? Jerk is that next iteration, that next degree that you’re talking about. And this is what we kind of experience, like the most, obvious, type of physical jerk is if you’ve ever been in an old elevator that abruptly stops or you’ve been in a car where someone slams on the brakes, it’s that rapid change in acceleration.

That you just feel right. It’s a physical feeling. And what we started to notice is that this was very similar to how people were describing and reacting to changes in their software, right? And this was something that we wanted to really get people that are building software to start to think more about and more directly about, because we believe that as builders, we need to be actually better at understanding this concept of jerk in the context of our users so that we can actually provide a better experience that will actually accelerate adoption of the things that we’re building.

So when AI started to become the thing that everyone was realizing, wait, this is a game changer. We say we were in the middle of writing this book, right? And we’re just like, oh, we should probably make sure that we’re incorporating something around AI. And as we started to have some conversations about it, we realized, wait a second, this is actually validating everything that we’ve been doing, everything that we’ve been talking about.

This is, something that we took a look at it. And I remember actually Nathen gave a talk, last year on some changes in the door report and how they were thinking about ai and they’re just like, oh wait. Same thing. This is just validating all of the data that we’ve been collecting for years, right?

We’re starting to see how AI is once again, making it even easier for people to ship more product, to be able to ship more features. Nothing is getting slower from the perspective of building software. But that doesn’t necessarily mean that people are capable of adopting things faster because we are still humans.

And so one of the things that we talk a lot about in the book is this notion of how do we actually decouple this idea of building and innovating from the experience of change. How do we make this easier for users and make sure that they are actually in greater control of how they’re experiencing all of the amazing awesomeness that we’re all building?

That one.

Heidi Waterhouse: So we think that it’s important to provide some factors to teams that are building so that they can understand the effect that they’re having on their users and their consumers. we grouped these into four As and they’ve held up for the entire time we’ve been writing this book. It’s been very interesting to us.

We were talking literally this morning about whether it. Whether we would reorder them if we were writing the book again, and maybe not. Maybe we got it right the first time. So the first one, or the, what we need is to accept the changes that come into our teams as they come. So it turns out all of the Tetris pieces have names, and I’m fascinated by this also, orange Ricky is such a weird name that it had to be an actual software designer who did this. But we can’t control when we’re going to get more of these factors. We can only say we have an organization that is going to get these factors at different speeds. So the first one is abundance. When we think about abundance, the easiest example is the cloud.

I’m looking at most of you in this room and you remember. When the cloud came in, when your data center started to shrink, when you could have elastic scaling, all of a sudden whether we had enough computers physically on our campus to do something stopped being a limiting factor. It started being, okay, we can do that.

If we pay enough money, we can do anything. And that abundance really enabled the transformation to a cloud native accelerated rapid pace deployment and development system. Then we need enough autonomy. The thing that abundance gave us was the ability to do anything we wanted. And the curse that abundance gave us was the ability to do anything that we wanted.

And it turns out, if you give developers all of the scope in the world. They won’t all use it the same way, and they won’t all use it in the same direction. What we need is enough autonomy, enough independent action for our development teams to be able to feel internally rewarded, to feel like they’re creating something and to get something done.

Many of you have been on teams where you’re like, I would like to fix that, but I cannot fix that because I am not authorized to fix that. We want to fix that with more autonomy. So that’s another Tetris piece that’s dropping down to add to the capabilities of our system. Then we need enough alignment for direction.

Remember when I said that developers will do anything they want? I want them to have that feeling, but I also want them to point in more or less the same direction. It would be great if we used all of our autonomy to accomplish things together instead of squirreling around and doing a lot of independent projects.

And when we talk about alignment in the software development life cycle, frequently what we talk about is internal alignment. Are teams aligned with each other? Are they aligned with the platform? Are they aligned with the corporate vision? Progressive delivery is really challenging you to say, are you aligned with the user?

Do you know what the user experience is when they use your software? Do you know what it’s like to use your application in a low data environment? Do you know what it’s like to use your application on a tiny screen? These are things that we think of as accessibility, but if we think of aligning ourselves to the needs of our users, we’re always going to make better software.

Then automation. We need enough automation for ease and efficiency. We need to be able to say, this is a platform. Build on it. Pick the software that you want to make some, other software. We’re, not going to make it difficult. Like here, there’s some preset templates, some guardrails, some tests.

Go to town and you don’t have to do this re-creation work all the time. When we combine all of these four as abundance, autonomy, alignment, and automation, we get this transformative work where we can do things together in a way that gets the right thing to the right people at the right time.

We’re gonna iterate this over and over. When you’re playing Tetris, the blocks don’t stop falling. We’re always getting resources. We’re always getting demands. We have to keep saying, okay, we cleared that bar. We cleared that line. What’s the next thing that’s dropping? Shipping software is not the goal.

Shipping software is part of the process. The goal is delivering value to users, not just what they want, but what they need, what they’re going to use, what’s going to make their life more productive.

Kim Harrison: So this is progressive delivery. It is chat GPT, even in its imperfect state, giving people the ability to query large amounts of information with natural language. It is the ability to do things in a low code or no code environment. The ability to vibe code. It’s offloading work you don’t want to do using a platform that’s helpful managing processes that you don’t want to be distracted by so that your team can focus on providing value.

for myself, I’m more on the marketing side. This is something like Grammarly or language programs that automatically give me captions, or notes from meetings that I’m in. So how did we get to progressive delivery? In the beginning there was waterfall. I think some people here might remember that time.

yeah, some people still remember that going from waterfall to Agile was possible because of abundance. suddenly we had the cloud. This meant that instead of delivering products on physical media once a year or every few years, we could provide updates directly to our users more frequently, such as quarterly.

Then we had Agile moving from Oh yeah. So moving from Agile to continuous delivery, was about developer autonomy and the rise of DevOps. We did a great job of improving development pipelines, to the point where continuous delivery became the new normal. Now, in whatever moment this is, we’re asking you to bring that focus back to the user.

Consider the most recent tools that have become available, how you can take all of this focus and align so that you can better prioritize actually delivering value to your users.

So the right thing lets your users do their work, the right people are the actual users. That’s where the rubber meets the road. And the right time is the moment that it’s useful, not too soon and not too late. So we’ve talked about progressive delivery as a theory, but what does that look like in practice?

How do you actually do it and how do you know that you’re doing it well?

Adam Zimman: And so go for, there we go. And. So for progressive delivery to actually be used, it ends up looking a lot like continuous delivery. Okay. This is something where, this is an iteration, above and beyond what we’ve been talking about for the past decade, right? Continuous delivery was all about smoothing out that pipeline from build to deploy to release.

Now one of the things that we are talking about with progressive delivery, that is a, the two core concepts that we wanna make sure that people are starting to adopt because it has such a significant impact on the way in which you’re not only building, but the way in which you’re publishing and releasing software is progressive rollout, right?

This is simple things. This is feature management, feature flags. This is observability. This is all the things that you want on that kind of, standard DevOps, infinity loop, right? Everything that takes you from the building of the code all the way through to the release to the users.

But start to think about it in the context of this, progressive approach that allows you to expose your code to the right people at the right time. If you think about this, in the context of individual users of a B2C type organization. This could be something where you’re actually going out to a set of beta users, first or early adopters, exposing them to a new feature, getting some feedback.

Then you’re gradually rolling it out to your power users. Then you’re finally rolling it out to your entirety of your, user base in a B2B context. Similarly, if you’re actually a B2B business, this is something where you should be thinking about which customers, which actual, companies are going to benefit from your features first.

Now the advantage in the B2B context is you may also put this behind some type of pricing and packaging, right? And have that actually be a part of how you’re actually bringing that to market. But you wanna still be mindful of how do I make sure that I have those controls in place, these control points in my code, to be able to choose who I expose these features to and when?

How do I know that they’re ready? How do I make sure that I don’t just roll something out to 100% of my audience and have 50% hate it and 50% love it, right? How do I expose it to the people who love it and make sure that they are as satisfied and, feel comfortable with it and either never expose it to the people who don’t want it, or do so over time when they’re actually ready for that change.

And part of this, knowing when is the right time is the second core tenant of progressive delivery, and that’s what we refer to as radical delegation. So radical delegation is a concept, from the Navy. That, or that’s where I first heard about it. This is something that was first, brought about as a terminology that was used when you are referring to orders given to a captain on ship, right?

If you are unable to communicate between the captain and the shore or multiple captains that are headed towards a similar objective that are apart by an ocean, right? There needs to be the ability for the captain to make the decisions that are most appropriate to meet the objectives that are set.

Similarly, with regards to how you are thinking about change and introducing change to your users, the best possible outcome is for you to be able to delegate that change as close to the user as possible. So in some cases, for a consumer product or B2C type organization, this is gonna be how do you provide the properties or settings page to your users to allow them to opt in to an experience.

Examples of this are, Google has Google Labs, right? Which was the ability for you to be able to basically turn on and off individual feature flags in products allowing you to see, functionality that was still in development prior to it being released to the general audience.

There are a lot of other examples of organizations that do this to be able to provide preview or have early access to new functionality. In the enterprise context oftentimes this may still be something that you actually are not exposing all the way down to the end user.

But something that you’re exposing at a company level, and maybe that’s being managed instead of by an engineer, it’s being managed by a customer success representative or a sales person who is actually closest to the account. You’re giving them the ability and the functionality to be able to turn on and off features, whether that’s because of a pricing and packaging decision, or whether that’s because of a new UI that you’re rolling out and you know that there’s actually a requirement of one of your regulated industry clients that says, Hey, wait, you actually need to give us time to be able to do training before you roll out a new UI across our company. These are all real world examples that we’ve seen in the course of our research for this book, where we really wanted to make sure that people understood these ideas.

And so being able to, articulate these as the two core tenets that make this the next iteration from continuous delivery tends to be really helpful for folks. Another way to think about this.

Heidi Waterhouse: Is to look at what we think of as the DevOps cycle. This is not the DevOps cycle, obviously, because there are three loops.

What we want to do is add the user into our understanding of how the DevOps loop works. So building the right thing, that’s, your software creation and your testing and all of the things that go into making software. And the next loop is the ops loop, the deployment, the maintenance, the uptime, the resiliency, the observability, all of that goes into the second loop.

None of this is new to you. The third loop we put sparkles on because it’s about the user. The user is the person who decides how they feel about software. They decide if it is useful to them or if it is something that is annoying, that is bloatware, that is yet another AI feature shoved down their throat when they don’t want it.

The user is an essential part of the software development lifecycle, and we’ve been ignoring them for all of these years. The way that progressive delivery is reaching out to pull users in is not just surveys like, who here, flew here and then got a thing from your airline about how your service was, which you promptly ignored, right?

I’m not answering that. I got here. I don’t care. we don’t, we can’t just rely on surveys. That’s, it’s very lossy data. It’s very, like any statistician will tell you why they’re so broken. We have all of these cool tools that we could be using to look at how people feel about our software. Do they click the link?

Do they dwell on the page? Do they download the app? Do they talk about the app? Do they do anything besides click X to close it? I want to know, and I have the ability to tell how people are using my app. And so if we instrument properly, we’re going to get observability, not just from our systems that are computers, we own, but from our systems that are the sociotechnical systems that encompass the entire working life of our software, and if we do that properly, we are going to make so much better software because we’re not going to be imposing it on someone.

A lot of media critics talk about how important it is to understand that once a film is released it is not just an artifact. It is an artifact. You can frequently buy a physical disc with a film, but it’s also a conversation with the viewer. People bring their own understanding of what’s happening in a film, their own background, their own context. If I watch Sinners, it’s a different thing than if you watch Sinners because you are bringing a different context.

We want to have that kind of relationship with the people who are consuming our content. We want to say, we care about your context. We care about what you’re doing. We care about what industry you’re in. Because if we’re not doing that, what the hell are we doing here? Okay, we sold some software and what does that mean?

So we really want. Progressive delivery to be about using all of these tools to bring the user into our software development lifecycle and to consider them co-creators and partners of our work.

So we’re doing a book signing tomorrow night. We are so excited about this book. We, fought about the name and the cover and the justification and the kerning. We fought very little about the content. We, all pretty much agreed that the stuff that we put in there is the stuff we want to say to you.

We want to say, here’s how we think you can do it. We want to hear your stories about how you’re doing progressive delivery, because I assure you. All of you have a progressive delivery story.

Kim was talking about how her hotel room has well labeled light switches. And I was thinking about the first time that I came to Vegas. I stayed at the Cosmopolitan and the hotel room freaked me out. Like I walk in the hotel room and the curtains flew open and the TV turned on and all the lights came up. And I’m like, what happened? And then Kim said. A

Kim Harrison: few years later, I arrived at the Cosmopolitan. The nothing was on, the curtains were closed, the lights were off.

Could not figure out how to turn the lamps on. I had the opposite experience.

Heidi Waterhouse: Neither of these was a great experience. Neither of them was what we wanted. But yesterday when we checked into our hotel room, the hotel room politely greeted us. The curtains were already open so we could see the beautiful view and all of the switches were labeled that we can tell how to turn them on and off from different points in the room. This is a story about progressive delivery. They got angry calls when the room was too dark and nobody could see it, and they probably got a little bit of Yelp whining when somebody was like, my hotel room was like a very excitable puppy.

This is information that they took in and made physical changes to better reflect user needs. All sorts of progressive delivery examples exist everywhere around you. Vaccines like the mRNA vaccine story, it was going for a long time, but we did a lot of progressive delivery to get it here really fast.

Even things like supply chains are affected by progressive delivery and an understanding of how the user affects the whole life cycle.

So we are hoping that you come to our book signing tomorrow, and we want you to come to Adam’s talk

Adam Zimman: with Brian Scott from Adobe. one of the case studies from our book will be, Brian, and I’ll be doing another kind of deep dive on progressive delivery and its impact on, Adobe’s adoption of AI, on Thursday.

Hope to have many of you come by that. Also we’d encourage you to read the book and if you like it as Corey Quinn says, leave a five star review, on your reviewer of choice. If you don’t like it, just leave a five star review on your, review site of choice.

Heidi Waterhouse: That’s not very, good feedback though.

I. I’ll take it, you’ll take it.

Adam Zimman: If you got issues, we want to hear about ’em. Absolutely. just not on the review sites. No. anyways, we also have a podcast, coming out. So if you’re interested in learning more about that, you can find us at progressivedelivery.com as well as on Blue Sky, at progressivedelivery.com.

And, feel free to come up to us and ask us any questions. and we are out of time. Happy to, take questions off stage. If you have trouble finding me, better glasses. Yeah. But thank you very much.

Heidi Waterhouse: Thank you all.

What are they celebrating, anyway? AI? Stonks? Liquid Glass? Hmph.

You and I, we have good reasons to be skeptical of their hijinks. It’s like every time marketing tells people there’s something new, they lose their everloving minds! But we know. We’ve been bitten by early adoption before, and now, as Pebble is my witness, we’re going to wait until v2.

It’s not that I’m against all innovation, I just know too much about it to be excited about it right away. I’m not buying a car until I can have buttons again, because it turns out some things don’t work with mittens. And don’t get me started about the dangers of lane keep assist in snowy conditions!

I was raised by a man who bought betamax, CPM, and laserdisc. If I’m not excited about your floozle or whatever, it’s hard-won suspicion. And why on earth does anyone turn desktop alerts on?

So fine, I’m a curmudgeon. Progressive Delivery was made for me. I can buy something after the initial rush has died down and still get all the benefits.

Right now, I’m sitting in the light of my Nanoleaf hexes. I loved them when I bought them 4 years ago. In that time, they’ve continued to work! Also they’ve added Thread support, more programmability, and a way for me to feed my music directly into the controller from my computer, instead of using the microphone. The value of my investment has increased because the software continues to be upgraded, but it stays interoperable with all the hardware. (I am not paid to do this, but Nanoleaf, if you want to leave something in my stocking…).

When we’re making software, it’s easy to have our hearts and minds focused on The Next Thing, the new hardware that will support it, the rate of adoption. But it’s worth remembering that you may have devoted customers who are not going to install your new things right away. They’re worth listening to. Or you might end up like Microsoft, who estimates that 500 MILLION capable PCs are not being upgraded to Windows 11, because lots of people don’t trust the product and don’t feel heard.

Listen to the users, expand your heart, don’t try to tell them what the value of your stuff is – only they know the true meaning.

We’re deeply invested in the future of software development, specifically how we can deliver exceptional value to users while minimizing risk. That’s why we’re excited about Dr. Nicole Forsgren and Abi Noda’s new book, Frictionless: How to Outpace Your Competition in the AI Era.

For years, Dr. Forsgren’s work—from the DORA research to the Accelerate book—has provided the quantitative science behind high-performing teams. Now, Frictionless gives us the human blueprint: Developer Experience (DevEx). This book isn’t just a friendly suggestion for happier teams; it’s a strategic necessity that perfectly complements and empowers the Progressive Delivery narrative.

The Progressive Delivery Mandate

The philosophy of Progressive Delivery evolved from the need to move beyond Continuous Delivery (CD). While CD focuses on the technical ability to release at any time, Progressive Delivery focuses on control, safety, and business value. It’s about building the right thing for the right people at the right time, minimizing the risk to users.

Our framework is built on four core pillars: abundance (do I have the resources I need, when I need them?), autonomy (as a developer can I safely move at my own pace?), alignment (as a developer are efforts aligned with user needs and business outcomes), and intelligent automation (are my products removing toil for my users). We show that success isn’t just a technical trick, it’s an organizational system that focuses on delivering software responsibly and iteratively.

Why Frictionless is Progressive Delivery’s Engine

If Progressive Delivery is the strategic framework for how we safely roll out changes, then a Frictionless Developer Experience is the high-octane engine that makes that framework possible, fast, and sustainable.

Dr. Forsgren’s work on DevEx illuminates the “invisible barriers” that kill innovation, which is the very thing Progressive Delivery is designed to accelerate. Her research highlights three critical dimensions of a good DevEx:

1. Fast Feedback Loops: Progressive Delivery relies on swift, accurate data from production (observability, user analytics) to decide when to expand a feature rollout. If a developer’s local feedback loop is slow (i.e., flaky tests, slow builds, cumbersome code reviews), they lose context and momentum. Frictionless ensures the Progressive Delivery tools themselves don’t become the source of delay.
2. Low Cognitive Load: Progressive Delivery inherently adds complexity. Developers must understand feature flag states, deployment strategies, and monitoring dashboards. If the underlying processes—the internal platforms, documentation, and tools—are convoluted, the complexity of Progressive Delivery practices becomes overwhelming. Frictionless reduces the mental tax required to engage with modern delivery tools, allowing engineers to focus on building features, not fighting infrastructure.
3. Achieving Flow State: A developer in flow is productive, innovative, and engaged. Frequent interruptions, broken tools (the #1 cause of bad days in Forsgren’s research), and process inefficiencies are pure friction. A team struggling with a painful, manual release process cannot possibly adopt the rapid, iterative, and autonomous release culture required by Progressive Delivery.

In short, you can define the perfect, safe release strategy (Progressive Delivery), but if the developers are constantly slowed by flaky CI/CD pipelines, unclear ownership, or burdensome context-switching—all forms of friction—your delivery velocity will grind to a halt.Nicole Forsgren’s Frictionless provides the research-backed, systematic methodology to identify and remove those barriers. By investing in the day-to-day lives of our engineers, we are not just investing in “happiness”; we are making the most strategic investment possible in our ability to execute Progressive Delivery’s promise: safer, faster, more aligned software delivery. The lesson is clear: Frictionless teams are the only ones who can truly achieve Progressive Delivery at scale.

You can hear more about Dr. Forsgren’s perspective on the software engineering craft in this clip: Dr Nicole Forsgren’s CONTROVERSIAL Take On Software Engineering vs. Craftsmanship.

He’s making fun of Epic, a software company that has between 42% (acute care) and 60% (health systems) of the American market. Odds are good that when your doctor is tapping away at their computer, taking their mask off to get it to do facial recognition, or cussing under their breath, they’re interacting with Epic.

And he’s right. It’s the least bad software we have for the purpose, and it’s infinitely customizable, and ubiquitous. It is what your doctor uses, the hospital uses, and even you use, if you have MyChart.

Why Is Customization Hard?

On the surface, letting people have all the customizations anyone has ever asked for seems like a great way to get alignment with what they want. They’ll just use the things they need! And maybe they want something they haven’t thought to ask for.

But that’s just the first thought, because the more options a piece of software has, the more work it takes to understand it, and the faster the users need to accept change. The interface gets cluttered. Then it gets horrendous. Then it looks like the administration view of Jira.

The options start… interacting. Maybe your organization has some users with a perfectly good reason for having both English and French interface labels, but how do they make sure the input keyboard is correct, and are those special characters being re-used anywhere, and do they render correctly in any of the 20 or 30 places that data could be accessed? And if you figure all that out, what happens when there’s an upgrade?

Customization is hard because every time you add an option, you have made the software fractally more complex. And for many many options, that’s the price you have to pay. But it’s still a price. It’s a price in testing, it’s a price in deployment, but most of all, it’s a price in usability.

So What Should We Do Instead?

If endless customization isn’t a good answer, what is?

Be opinionated!

I’m writing this in WordPress, and the blocks they think I’m most likely to use are at the top of my menu. Paragraph, image, quote, list, embed. Yes, those are the things I use most often, and should be easiest to find. There are few enough that they don’t need to be alphabetized or grouped. Much much further down are things I’ve never touched, grouped and alphabetized, in case I need them. Have I ever needed a Wolfram Embed? No, but if I did, I could find it.

Even better, as I use blocks, they get put in my “Most Used” menu. That is unique to me, but it’s not a customization, exactly, more like a preference.

Be aware

What do people say they do with your software? What do they actually do? For most users, the Pareto Principal applies. 80% of the users will use, at most, 20% of the product. That’s fine. The other 80% of the product will be useful sometimes, to some users, in some circumstances. You have to be able to track that. If you aren’t collecting metrics about what people actually do with your product, you might be overlooking a small but very popular feature, or you might be working hard to support something that should be retired. Progressive Delivery is as much about gathering information as it is about getting software out.

Be Considerate

No one sits down to work and opens their laptop with a song in their heart because today they get to use an ERP system. They didn’t go to medical school because they have a passionate drive to click software checkboxes. No matter how much we care about our software, it’s a tool for the people who use it, and we need to respect them. We need to respect their time, and their cognitive effort, and their accessibility needs. And one of the ways we can be respectful is to give them exactly what they need and nothing more.

Conclusion

It’s easy to make fun of Epic, or Jira, or IBM Tivoli, because using them feels like trying to play a Wurlitzer instead of a brightly-colored xylophone. The features they have exist for a good business reason. All of them. But no single user needs all of them, and most users benefit from not seeing them.

Be opinionated.

Be aware.

Be considerate.

Bonus Material

I need to show you what some of the offices at the Epic headquarters in Verona, Wisconsin look like. And it’s mostly individual offices.

The following is a transcript from the video. The transcript has been edited for easier reading and organization.

Mark (Host):

Okay, well thank you everybody for coming today. This is going to be very exciting. Adam is here; he’s going to be talking about progressive delivery.

Adam’s worked with a number of startups and also worked at GitHub, and he can tell you more of the things he’s done. But he’s going to be talking about progressive delivery, and I won’t steal any of the thunder from the slides that I saw. I think this is going to be very, very interesting, particularly if you’re coming from a continuous delivery approach. As that being a good thing, Adam may open your eyes to how to maybe take that up to another level.

So, Adam, I’m going to turn it over to you. Oh, and first I say that and then I take it back. Adam said he likes being interrupted. So if you’ve got questions that you don’t want to say, throw it in the chat, and I’ll interrupt Adam, because I’m happy to interrupt Adam. Or throw a hand up or anything like that. There may be some points to pause. He’s going to get through his content, and then we’re going to look at having some discussion. And then we do have a quiz at the end where you can win a copy of his book, which just came out today, if I understand correctly. So you will be one of the first people to order on the day that it was out. I’m looking forward to getting my copy and reading it. So with that, I’ll turn it over to you, Adam.

Adam:

Thank you. Thank you so much, Mark. Really appreciate it, and thank you all for joining today. I really appreciate the audience. As Mark indicated, from my perspective, I really look forward to engaging with you. Happy to share some stuff that gives it some context, but really looking forward to hearing your feedback, hearing your ideas. I would love it if you disagree with me, because if you agree with me on everything that I say, that can be a little bit boring. So feel free to speak up. Either use the chat—I’ll be trying to monitor that as I’m going through some of these slides—or interrupt me, come off mute. This is an opportunity for you to be part of the conversation and not just passively absorbing.

What Is Progressive Delivery?

So with that, I’m here to talk to you about progressive delivery. I’m also excited to say that today is launch day for the book that I wrote with a few of my co-authors for talking and exploring this topic. This is something that I have been talking about and exploring for the past seven years. And with my co-authors, we were the ones who actually invented this term and have been exploring what this means and what this looks like, and ultimately, how can we enable people to start thinking about it and being successful with paying attention to what they’re building and who they’re building it for.

So with that, let’s talk a little bit about who I am and why you should care what I have to say. I am one of the co-authors of Progressive Delivery. I have been building products, process, and teams for about 25 years in the industry. The majority of time spent has been in the areas of infrastructure and developer tools. I’ve done some interesting stints at various companies. I’ve also been an advisor and a board member for a number of other startups in the space. The common thread throughout my career has been: How can we actually enable people to be more successful with technology? What does that mean for users to be able to actually get value from the products that we’re building and from the ways in which that we’re delivering them to the end users?

All this comes from my background in physics. And as Mark pointed out in one of his LinkedIn posts about this talk, yes, my first career was actually as a street performer, juggling things like fire, knives, and circular saw blades. Basically, I’m just an attention seeker.

The Problem: Technological Jerk

I want to pose this first from the perspective of a story. This is a little vignette that makes an appearance in the book, but it’s one that I found that a lot of technologists can connect to.

It’s Friday, 9:52 p.m. You open an app on your phone to adjust an alarm on your smart speaker. You need to make sure that everyone’s alarms are all set up because you want to wake up early for a flight that you’ve got to take in the morning. You open the app and you notice it looks different because there was an update, and you’re like, “Oh, cool app update, right?” And then you go and you start to say, “Oh, I need to find the alarm to adjust it.” And you can’t find it. You’re looking and looking. Then you’re like, “Wait, something’s going on.” You go to Reddit and you’re like, “Hey, where’d this go in the new app?” You find out after reading a number of threads and subreddits that it turns out the purveyors of the app deemed that to be a non-critical feature and removed it from their latest app update. Then you get the pleasure of running around trying to find a solution that can help you because you have been jerked around by technology—technology that you chose to depend upon is no longer actually helping you; it is in fact making your life worse.

As was pointed out, Mark, this is not entirely a hypothetical situation, but I’m sure that we’ve all been there. As people who use technology on a daily basis, there’s been some instance in your life where software has been updated without your consent. You have now been jerked by that technology.

I keep using that word jerk. This comes from my physics background. In the context of physics, jerk is actually the third derivative of position. The first derivative is velocity, the second is acceleration, and jerk is the change in acceleration. The reason I use this term in the book is that this is what we experience: that rapid change in acceleration. We often feel this in the real world when an elevator moves too quickly or stops too suddenly, or if you’ve ever been in a car accident or stopped short in your car. That is an example of jerk. In the context of technology, we’re starting to see that jerk is becoming more common in technology release and adoption.

The rate of technology adoption used to be measured in decades in the early 1900s. By the end of the 1900s, that adoption rate started to collapse. We were talking about years, then months. Now, with things like ChatGPT or other AI tooling, adoption rates can be measured in days or even hours to reach 60% adoption. That rapid change is hitting the mainstream, but what does this mean for those of us that aren’t ready for that change?

A Shift in Delivery Focus

From a user perspective, we really need to be thinking about that user adoption function in the context of how we’re building products. A big part of the book is talking to the builders—the people responsible for building and shipping software—and trying to help them actually start to think more deeply about user adoption.

We developed a quadrant to explore this, based on two axes:

1. Developer Autonomy: How flexible is it for the developer to just ship?
2. User Adoption Alignment: How well do we align with the user’s adoption rate?

• Waterfall was the predominant methodology when software was tightly coupled to hardware. There was no user context or ability to provide feedback, so user adoption wasn’t a major metric. Developer autonomy was low because of the tight coupling to physical hardware.
• When we introduced Agile and started decoupling software from hardware, the focus shifted to the user. We had user stories and sought feedback to make course corrections. It had a pretty good level of user alignment, but it continued to lack a high level of developer autonomy.
• With the rise of the cloud era, developers wanted more flexibility and wanted to push code on their own. Continuous Delivery was the expected model, driven by the motivation to get code to production quickly. Unfortunately, with that, we lost sight of user adoption. The focus shifted too far toward the developers building what they thought was important, often shipping things without the ability for users to say no. This was the epitome of the SaaS movement where, “I control the entire user experience on the back end, I can push out changes whenever I want, and the user just has to take them.”
• This is where Progressive Delivery comes in. We want to start encouraging builders to think about both the speed of Continuous Delivery and the user focus of Agile. From an Agile perspective: We support your concern for users, but we think there are practices from Continuous Delivery that will enable your developers to be more autonomous and ship at a faster pace. From a Continuous Delivery perspective: We think what you’re doing is great from a developer autonomy perspective, but we think there are things you can do to actually better align with the needs and value you’re delivering to your users.

Ultimately, Progressive Delivery is about two things:

1. Enabling your developers to build and deploy without friction.
2. Enabling your users to adopt at a rate that maximizes value to them.

We are talking about building the right thing for the right people at the right time.

The Third Loop

We’ve added a third loop to the standard DevOps infinity sign—the virtuous cycle between dev and ops. That missing loop is the user adoption loop. We need to make sure we are mindful of this when defining criteria and constraints, and paying attention to it from a monitoring and observability perspective.

Core Tenets

Progressive Delivery has two core tenets:

1. Progressive Rollout: This includes things like using feature flags and cohorting to expose new functionality in production only when your users are ready for it. Start with an internal staff ship, then move to beta users or power users who are most excited for the change. Get their feedback so you can refine the feature before pushing it out to people who may be more hesitant or more impacted if you change their workflow.
2. Radical Delegation: This term comes from the U.S. Navy. In early days, pre-satellite communication, orders were issued to the captain of a ship in the form of an objective, and the captain was responsible for managing the way that objective was reached. In the context of technology, it means providing the controls and objectives, and giving someone else the ability to execute. We want to help organizations delegate control over who gets to make the decision of when a feature is available to a given user.

A good example of Delegation is when a developer has a new widget:

• Developer is responsible for control at the beginning (sharing with other developers, operations team for validation).
• Operations Team is responsible for the next cohort (beta users, staff ship) because it’s their infrastructure and they hold the pager for outages.
• Product or Marketing Team dictates the release to a broader audience, perhaps to time it with a press event or marketing push.
• Customer Support/Success/Sales Team handles feature functionality gated on licensing or tiering, performing the enablement of that customer.

Radical delegation means delegating control of who gets to see what when as close to the customer as possible. The ultimate example is personalization within an application, where users are given access to make their own choices about whether a feature is on or off. Organizations have adopted this practice by asking: “Do you want the latest and greatest version of everything that comes out, or do you want to wait?” This is the push versus pull dynamic, ensuring users who are excited get changes right away, and those not interested in change have the ability to hold off until they’ve been prompted with videos, tutorials, or documents that help them understand the changes.

The 4 A’s Framework

To measure organizational readiness for progressive delivery, we developed the 4 A’s Framework: Abundance, Autonomy, Alignment, and Automation.

1. Abundance: We live in a cloud era and have access to all the resources we could want. This asks: What have you done from an organizational perspective to ensure that your developers and builders actually have the ability to access those resources? A lack of abundance is an immediate bottleneck.
2. Autonomy: This couples closely with abundance. Are developers capable of moving their work forward on their own, or are there constraints? The goal is for any developer to push to production at any time, backed by controls, not constraints.
3. Alignment: This is the flip side of autonomy. How are you making sure that the things being built are actually relevant, needed, and desired by your user base? We must ensure the teams and individuals are aligned with the goals of the organization and the expectations of the customer. This requires paying attention to the feedback loop with your users: direct feedback (support requests, bugs, NPS surveys) and indirect feedback (observability on feature adoption, workflow dropout rates, time-in-app data from tools like Pendo or WalkMe).
4. Automation: This is extraordinarily important for organizations as they scale. We often talk about automating build and deployment systems, but a critical component is using technology to actually lighten the toil of our users. How are we monitoring user adoption and workflows to introduce automation to make tasks easier? Instead of 15 clicks, maybe it only takes one or two because you already know what the user is going to do. If you know 100% of the time the answer is going to be the same, don’t ask the question—just autofill that information.

Conclusion and Q&A

Adam:

I’m going to pause for a second for any questions.

Max (Audience Member):

Why are continuous delivery and progressive delivery opposed to the Agile quadrant? Isn’t that weird? We also talk about developer autonomy working at a team for a product, and maybe what I understood better is individual autonomy as regards teamwork, but I’m not so sure. Could you make a difference between Agile and Continuous Delivery and Progressive Delivery? What does Agile mean in this?

Adam:

I think I know what you’re saying. The point of this was to really talk about what the various different development life cycles are optimized for. In the context of Agile, it was still a very structured software development life cycle, which works for a large organization in particular. That structure gives you the ability to have visibility up the organization of what things are being worked on, as well as some level of autonomy down to the team level of making sure that you’re able to adapt to changes.

In the case of continuous delivery, the autonomy is much more about the individual developer’s ability to drive a piece of work from idea to deployment. An Agile team might not go in and just do a bunch of technical stuff because it’s very driven by “here’s what you need to do,” rather than a situation where they’ve got a lot more control over “here’s what I think needs to be done, I’m going to go do it, and I don’t necessarily have to find a user that’s asking for this particular piece of things.” That’s definitely one way to talk about it.

Mark (Host):

Does this eliminate staging or test servers?

Adam:

From my perspective, I have been advocating for a while that you consider your users’ regulatory constraints or other things. One of my favorite organizations that I worked with when I was at LaunchDarkly was Fannie Mae. Fannie Mae, a rather large, federally regulated organization, had a bunch of contracts that actually restricted the frequency with which they could update software and required them to have a certain level of training hours made available to the users prior to its release. This really inhibited their ability to adopt SaaS tools because they couldn’t control what the experience was going to be like.

One thing they tried to work with us on was becoming an evangelist for LaunchDarkly back to their supplier vendors, saying, “Hey, can you actually use LaunchDarkly so that we can have greater granularity of control of when we get new software updates from you as a SaaS product?” And then they used it themselves to make sure that they had protected releases and granular control for the software they were providing to their end users.

This is how we make it so that the notion of user adoption becomes front and center again, but at the same time, take advantage of the continuous innovation. It’s the difference between getting the update for a new online video game, which is fun, and your bank rolling out a new website that completely changes the way you log in, which can be frustrating. 

Mark (Host):

My bank put a confirmation step after bill pay that I was not expecting. I had lots of late fees because I didn’t have to click through before, and now it was there. It wasn’t a bad change, but if I could have opted out of that, it would have saved me 15 bucks.

Mark (Host):

Taylor was asking if there’s a place to learn more about the Fannie Mae case study.

Adam:

I know that there used to be a Fannie Mae case study on LaunchDarkly’s website. I haven’t been there in a number of years, so I don’t know if it’s still up or if they’ve taken it down. I know that we did do some webinars with them, so there were some other resources. I can probably check in and do some digging for you and send Mark a note, and maybe he can add this to the show notes at the end. That may be one of them.

Bringing Change to Your Org

All right, let’s talk a little bit about what some calls to action are for your organizations or your teams. As one of my favorite authors, Brandon Sanderson, says, “Journey before destination.” Part of this isn’t about getting to an end state of “Ah, look, we’re doing progressive delivery.” It’s more about how do we start to think about these ideas and make some incremental improvements? How do we bring this back to top of mind for how we’re building and interacting with our users?

• From a dev’s perspective, this looks a lot like a continuous delivery mindset: How are you looking for bottlenecks and identifying areas to increase the efficiency and speed with which your developers are able to build and deploy to production?
• From an ops perspective, this is about taking continuous delivery ideas and thinking about controls. How do you deploy feature management or feature flagging? How do you start to look at modern observability techniques instead of just simple monitoring where you’re looking at uptime? Instead, how are you looking at the number of users that initiate a workflow, how far they make it through, and what the dropout rate is? How are we actually looking at feature adoption?
• From a product perspective, what do we consider “done”? As one of my co-authors, Heidi Waterhouse, says, “Is software ever really done?” The reality is that in today’s world, the answer is often no.

From a user perspective, how are we starting to imagine this through the user’s mindset? What is the rate of change that is appropriate for the user? This is going to be different if we’re a bank that has cohorts ranging from new bankers at the age of 10 or 13 up to people in their 80s or 90s. How do we make sure that we’re providing the right level of change to all those individuals?

A review of the 4 A’s:

• Abundance: Giving your developers all the computing resources they need to move their work forward.
• Autonomy: Measures the developer’s ability to move their work forward on their own without external constraints.
• Alignment: The focus on the user, paying attention to both direct and indirect feedback to ensure what is built is actually needed and desired.
• Automation: Using technology to lighten the toil of both builders and users.

The key thing here is that you want to think about how every small improvement helps to reduce that notion of technological jerk that your users will potentially experience. This is really about removing the jerk from your software.

Thank you all so much for your time today. If you’d like to learn more, the book, as Mark indicated, launched today. So it’s available on your online book purveyors, as well as in some local bookstores, available in most Barnes & Noble. I would also encourage you, if you have a favorite local bookstore, ask them to order you a copy. I’d love to get it on their radar and see it on their shelves. With that, you can provide me with feedback in the form of a five-star review. I would always welcome that, and would love to hear from anyone that has some interesting stories either with regards to how they’ve experienced technical jerk, or how they have used Progressive Delivery to build better products.