This is from 2022 | 7 minute read
Your business isn't made of marble. Neither is software.
Some forms of design are permanent. When a poster or book goes to print, there’s a point of no return, where the design is finalized, the printer rumbles to life, and soon there will be thousands of copies out in the world, owned by someone and impossible to change.
This is even truer for physical products: watching toaster after toaster roll off a production line makes it intensely obvious, at a gut level, that decisions made long ago are now fixed in place forever. And in fact, a lot of those decisions were locked in much earlier, when an injection molding tool gets cut, for example, or a shipment of components leaves a dock in Shenzhen. Industrial designers and engineers lose sleep over stuff like this.
But you know who doesn’t lose sleep? Software engineers. When a piece of software “rolls off the production line”, i.e. launches, it’s just moments away from being tweaked or changed. With few exceptions, modern software is delivered online, to machines that are perpetually connected to the internet and therefore to the company that made the software. This has some very direct implications for the way companies pursue digital transformation—or at least, the way they should pursue it.
Now, there was a time when buying a new piece of software meant going to a physical store and pulling a shrink-wrapped box off a shelf, like it was a board game or a food processor. When a new version came out, you read about it in a magazine, then decided whether it was worth buying a new box, taking the floppy disks out, and installing it over your old version. It gave a lot of personal agency to the consumer, but also depressed the pace of feature advancement—for the software company, a new version meant a point of no return on par with the folks making board games and food processors.
When e-commerce showed up, one of the first things it ate was the physical software store: software is just bits, after all, and the people who buy it have computers. Updates could be uploaded cheaply and purchased quickly, so they got more frequent. Eventually, some smart companies started switching to subscription-based and SaaS models, where updates are bundled in with the software.
The current state of the art for digital products is “continuous release”, where changes push almost instantly. At this point, the only real constraints on an update, improvement, or new feature are artificially imposed: an updated interface that might annoy users who’ve gotten used to the old one, for example, or adding confusion to a crowded market at the moment when potential customers are contemplating adoption. But there’s no moment of truth, no point-of-no-return. If this update sucks you can undo it, or update it again until it’s right.
Digital development teams understand this implicitly, but their managers often don’t, and this is where we start getting into problems.
Let’s say, for a moment, that you’re in a position of authority at a large-ish company, and you worked your way up to that level over the course of several decades. Much of your career, digital or not, was defined by make-or-break points, and you got where you are today by crushing them. You caught the tiny screw-up that everyone else missed, you were organized enough to keep your team on schedule so there was no frenzied rush to hit a shipping deadline; if there was, you made sure the team hit it without making stupid mistakes.
It makes total sense to continue to run new product development projects along those same principles. So you validate and revalidate your product roadmap before making a single thing; you ensure every word of content and every visual detail is confirmed by dozens of people, socialized with marketing, and approved by legal; you dot every i and cross every t.
Meanwhile, your designers, developers and technologists are losing their minds. They work with code everyday, or interact with users and developers regularly, and they mostly understand the true constraints and possibilities of digital products. So the scurry to finish something “on time” seems weird at best, or worse, like some bizarre form of self-harm. Artificial deadlines create artificial demand for resources as the deadline approaches, but the anxiety they create is very real.
True, there are some radical changes to digital products that merit a lot of hoopla, advance warning, and a bona fide launch date, but in modern tech these are the exception rather than the rule. There’s a reason Apple’s big announcements mostly revolve around the launch of physical products, or transformative software changes like a new operating system. Everything else is gradual, evolutionary, and endlessly mutable.
In a frothy talent market, the aforementioned developers, designers and technologists are largely calling the shots, and believe it or not, they’re not all going after the biggest paycheck. A lot of people in this field genuinely love what they do, and provided they make enough for a decent living, much of what drives them to take a job—or leave one—is assurance that they’ll get to continue loving it. A quarterly or yearly development cycle is a good clue that they won’t.
Besides turning off your best talent, an obsessive “launch date” mindset also makes digital transformation efforts nearly impossible. If the state of the art is continuous delivery (and it is), then becoming a modern company that delivers digital experiences that meet user expectations and outperform competitors nearly always means shifting to a continuous mindset.
Take ed-tech as an example. Google Classroom has become just about default in American high schools at this point, because it excels in all the ways we’ve come to expect from Google products: it does a lot of things well, it’s cheap and easy to learn, it integrates with everything, and it’s always getting better. Educational publishers have watched this in horror, wondering how they, with half a century or more of expertise in the field, are getting shown up by a bunch of non-teachers from Silicon Valley (I’m sure Google has plenty of experienced teachers on staff, but they’re experts, not managers).
One of the main reasons is continuous delivery. Google is amazing at it, and traditional publishers, built on decades of paper textbooks updated at regular intervals, aren’t. This allows Google to push out small changes, see how they do, gather feedback, then update in a well-informed way. And they do this weekly, even daily. If that’s your competition, and you’re still building your product cycles around letter-perfect new editions every other year, you are fundamentally and systemically screwed.
The message to “launch date” managers is urgent—fix this or you’ll eventually go out of business—but it’s also hopeful—many of the people who already work for you know what to do. And the message should also be tempered with a little compromise: releasing sooner and seeing how it goes means you can always fix it later, but in reality, you probably won’t. One of the dirty secrets of continuous delivery is that technical debt never goes away. But for the most part, users don’t care unless it’s really bad.
The solution here, as with so many problems arising from technological progress, is to get the new guard and the old guard to have some real conversations. There’s a middle ground to be found between continuous improvement and thoughtful, informed strategy, but you won’t find it by ignoring reality…or by complaining about the C-suite. And dealing with technical debt is just as much a strategic consideration as a technical one.
The best analogy here might be an observation made in a debate I once heard:
In every house, there’s an optimal amount of dirt.
If you want to insist on a perfectly clean house, and are willing to take that insistence to its illogical conclusion, you end up with a laboratory clean room, where no actual living can take place. But neglecting cleaning tasks in favor of living life leaves you with an unlivable mess.
That’s how technical debt works when you’re delivering frequently or continuously. You’ll never have a perfect product, ever, and you have to be OK with that. But on the other hand, “move fast and break things” was never a good idea to anyone but developers under 30. So if you want to move into the modern, post-launch-date world, then the people in your organization have to get together and decide how dirty you’re comfortable letting your products be—and in which rooms the dirt ends up.
Digital product development is a messy place, and the more comfortable your organization is with that fact, and the more intentionally they address it, the better equipped they’ll be to thrive in a technical landscape that gets less permanent all the time.