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.

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.

There are some unifying themes here, and ones that I would want to know about if I was doing product at any of these big companies.

1. I didn’t ask for that!
2. You screwed up my workflow.
3. This is consuming resources in ways I don’t want.

Now, this isn’t just a straightforward “you should always listen to what people want from their software”, because I assure you that the average professional wants very few changes, and then only to fix things that are obviously annoying, like the “sub-tasks” comment in the second image, or memorably for me, more than one level of “undo” in FrameMaker. We damn near threw a party for that release. But we do have to keep things updated and moving along.

Consent culture in software

In other parts of my life, I teach teenagers that consent is fully-informed, freely given, and ongoing. In my workday, I accept that my company has the right to choose software that I don’t like, software that I find hard to use or unhelpful. I think most of us have had work experiences where the mandate comes down that we’re going to use this email or that meeting suite, because the whole company is switching, and that’s just the way it is.

We have a choice. We almost always have a choice. It’s just that I don’t know a lot of people who have cited “They’re making me use PolyWidgetExec” as a reason to quit a job. Instead, we sigh, we install the new thing, we change our workflows, we may use it grudgingly and with hate in our hearts, but it’s just how work goes.

But look at how angry those users are.

Because they feel they have been forced, or tricked, or coerced, they are actively angry at the software. It’s not a cute little experiment to them, it’s excessive loading times and extended task completion. Some product person has decided that the “tried the feature” metric they are being measured on is more important than keeping the relationship with the user positive and consensual.

We know that user sentiment matters – we wouldn’t measure it all the time if we didn’t. But sometimes the parts of an organization that ask and the parts that roll out feature appear to not be talking to each other, let alone the users.

Counterexample

On the other hand, this just popped up in my Slack today with a cute little pumpkin emoji:

They’re little touches that are like dressing your workspace up for Halloween. The color themes all have creepy names, the status suggests you could dress that up, too, and it even has some whimsy in a randomizer. It’s all strictly optional, it mostly only affects your own experience, and because they asked, I feel included, instead of coerced. And it all goes away again when the holiday is over. Charming!¹ I don’t feel like cussing Slack out at all.

The Progressive Delivery angle

I am morally certain that someone at each of these not-Slack companies sat in a meeting and said “Users will not like this. They do not like having things surprise them, and it’s rude to make their work harder without permission.” I have been in those meetings myself. Often the person saying this is not in a position of power. Frequently they have a title like “Accessibility PM” or “Technical Support”.

But in a world with Progressive Delivery, they can point at the instrumented results from the 1% rollout and say “50% of users turned off this feature the next time they opened settings” and then you don’t get the weird numbers games where it looks like everyone is fine with Microsoft pushing voice-controlled computers with Windows 11. (Microsoft says this makes sense, because people spend millions of hours talking to their computers already. On TEAMS they do. Not to the computer. To other humans.)

Progressive Delivery helps teams make better software by making software rollouts smaller and safer, and feedback more accurate and immediate. So maybe we could all be a little less angry.

1. I think there should ideally be an option to say “this is not a holiday I celebrate” and none of the nonsense and frivolity shows up for you on that or any other profile again, but that’s advanced-level user customization. ︎

Alignment isn’t the same as agreement, or cooperation, although it can include those elements. It’s not unity or unanimity.

When we talk about “business alignment”, sometimes we get sloppy and use it to signify agreeing to the goals of the people in power, or a superficial arrangement of shared interests.

What alignment is

Alignment is the active choice to make your vector match something else. Vector includes both direction and movement. The moment of being aligned is a snapshot of a dynamic state.

If we take a moment to think of alignment as movement, it changes how we understand what we’re lining up to.

Alignment in software is considering the state and direction of our teams, our dependencies, and most of all, our consumers. Where are we now, and where are we going, and how can we do that together?

Software has always been about aligning the computer, the code, and the consumer. Sometimes that means thousands of developers across dozens of divisions to make an operating system, and sometimes it means one hobbyist building something for herself, but in order to make something that really works, you have to understand what you want it to do.

How we got to today

Much of early software came from command-and-control environments. Admiral Grace Hopper was not a title distributed by a bridge club. In the military creche that software was born to, it made sense that the purpose and outputs of software would be clearly defined before anything was created. As software expanded in capabilities, from decryption and trajectory calculation to communication, multi-directional inputs showed up. Software had to not only execute commands, but respond to context.

Commercial software experienced the same moment, from a time when companies were in control of what software was used for, to a time when software was useful to communicate back to the company. No longer was software something that was distributed. It became something that was uploaded.

In large software projects, a single developer or project manager doesn’t have the power to shift the entire mass very far — software projects, like anything else, have inertia related to both their mass and velocity. If the iconoclast gets too far from alignment, the organization either rejects them or convinces them to re-align. 

The rise of open source and the abundance of cloud computing has allowed for very small teams to make a much larger impact than we would have assumed possible for most of software history. With enough time and infrastructure, ConcernedApe (Eric Barone) coded an indie game that took the world by storm¹. It is common to think of software features as being created by triads or small teams.

Even indie developers and moonshot teams need to find alignment with their systems of distribution and their users. The first thing that startup advisors try to get through to founders is the absolute necessity of understanding product-market fit — what are you making, who is it for, why do they care?

Hacking and growth mindset

Once it was possible for ordinary human users to change software, we did. We used artillery physics to bomb hapless worms into radioactive rubble². We attempted to assert control of what our printers could talk to and do. Early hacking was almost always an attempt to get software to align better with what the user wanted.

Knowing what your software is doing is a surprisingly difficult problem in computer science. Almost all our stacks are complex, and few of us understand every layer of them. One snippy letter from Ada Lovelace to Charles Babbage begs him not to alter things in a way that seems to improve them, because it throws off her calculations. The first debugging argument! 

Complexity

When we started splitting our programming into server and client, data and operations, front and back end layers, we multiplied the complexity of getting everything to work together. Alignment is harnessing all the constituencies of the socio-technical system and getting them pointed in the same direction.

When Amazon promoted the idea of the 2-pizza team, they also talked about how every team would communicate with other parts of the organization with APIs. The entire organization was aligned on using APIs to communicate anything that needed to pass between team or service boundaries. In that case, it was an implicit contract, since everyone was working for the same organization. 

If software has eaten the world, it has eaten humanity too–and we are symbiotic with software. When we say socio-technical system, it isn’t just the global software/humanity gestalt, but the systems within the greater system. The smaller the system, the easier it is to align. It’s easier to go on vacation alone than with anyone. It’s usually easier to go with just your partner than your extended family. Each time you add nodes to the family-vacation system, you increase the difficulty of decision-making and alignment. 

Software makers knew that adding nodes added complexity, but it’s inescapable complexity. It meant that alignment had to be both stronger and less prescriptive. It’s the difference between personally planning a vacation where all participants agree to all activities, and booking a cruise, where “get on the cruise ship” is the main alignment, and activities can be more independent. We’re all on the cruise ship, going to the same places.

However, building the kind of trust that enables this strong alignment and weak direction is not easy to do from a command-and-control mindset. 

Alignment goals

It is hard to do alignment if you don’t understand the goal.

It is tempting to make alignment itself the goal. But that’s how you get echo chambers and groupthink. The goal you’re aligning to needs to be broad enough that everyone can see their place in it and narrow enough that they can tell what isn’t part of the goal. When you get something that well-defined, you can hold up every action and choice to it and tell whether it will help or hinder the goal. 

Alignment to an overall goal helps groups within a company and keeps them from veering off into their own weird things. Alignment with customer needs and desires keeps a company from ignoring its own long-term interests. Especially in software, it’s easy for us to get hypnotized by the potential of new and shiny things and forget that our assignment is to help users get things done. Alignment and frequent course corrections helps us keep in touch with the people who want to be our users.

Conclusion

Alignment is a moment in time, and it is never finished. You will have to keep working on it over and over again, for as long as you’re trying to do a project. This may feel like an exhausting task to add to all the complexity of building something, but if you don’t have alignment, then what you are making means nothing.

Progressive Delivery wants your team to build the right thing, for the right people, at the right time. In order to do that, you will just have to keep aligning, over and over again, like driving a car, like telling a spouse you love them, like going for that jog. Alignment is doing the actions that fit with our values and desired outcomes.

1. ︎
2. ︎

Apple scales back the glassiness of its ‘Liquid Glass’ design in latest test version of the iPhone software by Henry Chandonnet.

What happened was this: Apple’s designers developed a new design language they called “Liquid Glass”, which was basically a floating transparent distortion layer for controls. In one sense, this is an extension of transparency-as-menu, which has been coming back around since 2004 or so, such as in the form of Windows Aero.

This insider.com story covers what’s been going on since then:

In June, Apple released its first beta version of iOS 26, opening it up to developer testing. While the Liquid Glass aesthetic has its fair share of fans, some early testers found the new design to muddle the user experience, with background text and colors shining through the glass bubbles. The iPhone’s Control Center was a specific point of contention, with some saying the buttons were difficult to navigate given the level of shine-through.

They are now on version 3 of the beta, and each successive version has walked back the transparency of the ‘liquid glass’. Now it’s getting to the point where the people who liked the transparency are complaining because it’s not as innovative as it was when it debuted, and the people who are more concerned about visibility/usability are still not satisfied.

I think the key point is this quote: “While Apple does not currently let testers control how glassy their displays are, users can enable reduced transparency, a pre-existing accessible feature that unifies the background color.“

and this one: “I got used to the new design language,” Popov said. “As an Apple fan, I’d love to have a customized option so I can choose what effect to use.”

The assumption by Henry Chandonnet, the author of the article, and Popov, is that this could easily be configurable, and it’s reasonable and easy for Apple to allow users to change their own opacity to meet their own needs and aesthetics.

That assumption of configurability is a core part of Progressive Delivery – we don’t all need to have the same experience, even if we’re using the same software. Using feature flags and sticky settings, everyone gets their preferred interaction style.

If Apple Design is as smart as their reputation indicates, they would not just collect this “loud” feedback, but they would enable configurability and then collect information on where people set the defaults to. Developers are an important audience, but you’d want to be sure that the general audience got something closer to “correctly pre-set”, since the general audience doesn’t always think of configuring their experience.

I’ve sorted this post into “Alignment”, because alignment isn’t just about team alignment as software gets made, but aligning the experience of using the software with the needs of the user.

— Heidi

We’re not here to give you certainty, or assurance, we’re here to help you work with change instead of being worked over by it.

Progressive Delivery is a set of practices to get the right users the right thing at the right time in a way that is sustainable for everyone. Yes, everyone. This includes executives in the boardroom, leaders managing departments, engineers, designers, product managers, marketers, partners, and most importantly – the actual product users. 

Progressive Delivery is a way to understand what you’re already doing, so you can do it more effectively.

Progressive Delivery is not about tools, and it’s not about certifications. It’s about what you care about and where your organization places focus. It’s more of a lens than a prescription. Products are not only the point in time when we deliver to a user, but a thriving conversation where building, use, and retirement are all visible and trackable.

Once you start seeing the world in terms of progressive delivery, you see it everywhere – ripe mangos in midwest supermarkets and tap-to-pay parking meters, Calendly links and same-day electronics delivery. It looks like convenience to us as users, but on the provider side, it takes a combination of investment, will, and effort. 

What is progressive delivery?

What do we mean when we say “Progressive Delivery”? Like every buzzy technical term, it’s going to be redefined as people actually use it and grapple with how it applies to them. It’s a way to get curious about the whole lifecycle of your product, including after it leaves your control.

Progressive delivery asks: 

• What is your definition of finished? 
• What do you expect to happen?
• What if your users want a different cadence of change?
• How are you stewarding the information you collect?
• How are you incorporating feedback?
• Who are ALL your constituents?

We have found four inflection points that organizations need on the way to Progressive Delivery: abundance, autonomy, alignment, and automation. Here are our definitions for this project:

Abundance

Do you have enough resources to do what you want? That’s abundance. “Enough” may define money, time, humanpower, clean water, physical health. 

In a computer sense, when software started to merge with business, we were limited by computing power, and finite storage, and distribution speed. Compiling took hours, testing took weeks. Cloud computing enabled by virtualization solved that problem, while also creating others. For progressive delivery, our systems need to have enough capacity to avoid constraints.

Autonomy

Can you do your job without waiting for other people? Being able to deposit a check after the bank is closed or change a business process without a meeting means that you have autonomy.

When Git and containers became available, they ushered in a trend of microservices and distributed systems. Developers could build faster without waiting for other teams – they were autonomous. Decoupling teams and using service agreements and expectations instead of forcing the whole organization to move at the same speed allows everyone to perform better. 

Alignment

Do you know what you’re trying to accomplish? Do you have clear goals, and do other people share those goals with you?

When teams are less co-located and interdependent, it is easier for them to drift away from a shared vision and output. We can’t settle for the old measurements about how many widgets were produced – we need to know how each team is doing, and how they are interacting. DevOps was a software movement to use people, process, and technology together to improve outcomes, and the success of that movement was solidified by the research of the DORA group.

Automation

Does your system “just work”? Can you assume that your train will arrive in time to get you to work, or that your pictures will be safe in the cloud, or that your grocery store will have milk? That is automation working to deliver goods and services predictably.

When you have abundance, autonomy, and alignment, you are approaching operational excellence. The way to lock in those victories and free up capacity for further improvement is to automate everything known and predictable. Automation is both a force-multiplier and a training tool for new teammates.

Each of these “A’s” reinforces and enables progress in the others. None of them is something that can be fully finished – you can always automate a little more, or a re-alignment will reveal a way for a team to become more autonomous.