Launch vs. Maintenance Culture

Let me preface what I’m about to write by noting that I actually feel blessed to be gainfully employed and that any criticism I levy is not absolute. I am also writing from a particular vantage point that may not be fully representative.
One of the most frustrating aspects of my current employer is what’s commonly referred to as a launch culture; it’s what happens when you over-index on developing the new and exciting, sometimes at the expense of maintaining what already exists. During some moments of a product life cycle, this can be an absolute boon, but there’s risk when that focus becomes institutionalized.
Our ever-evolving internal processes, particularly those focused on employee recognition and reward, continue to, by and large, be fixated on the notion of impact. On the surface, that makes sense. The more impactful your work, the more valuable it’s likely to have been. The question that arises is how do you calibrate around a nebulous term like impact? Ideally, there’s a basis in measurable effects, but in reality, there isn’t always a readily quantifiable valuation—more loosely, measuring everything accurately is hard.
In a large organization, there’s unlikely to be a universal methodology anyway. In my experience, one of the easiest ways to define impact is to look for a few basic indicators. These can be simply directional; coming up with actual numbers isn’t even wholly important. We can focus on hypotheticals, the wargaming of possible scenarios where your work is held up against other prospective deliverables. I imagine most people would assume that impact boils down to revenue. How much money did this make or how much could it make over some period of time? While it’s a reasonable expectation, I’d argue that the leading factor is often something much harder to quantify.
Tell me a fable
A launch culture fixates on delivering new and shiny things. It focuses on the delivery of a new feature, a new product, a new process; anything that you can look at as being a transformative multiplier of the metrics you care about. The shinier, the better, and the easier to sell the story to leadership. “Leadership” of course refers to the people who are in turn responsible for repackaging your deliverables, impactful or not, and pitching them to their leadership. Who in turn package all of their reports’ impact into an ever larger story of impact and value-added. Each layer adds further and further need for scale and reach.
Zooming all the way out, you might see why the contributions of an individual feel like they matter less and less the further up the chain, but altogether, they’re leveraged to tell a grand story of all of the delightful impact that everyone has worked toward. Put another way, leadership generally values stories of wide scope and reach. That isn’t inherently a bad thing. Certainly, I have to imagine that most people would prefer to contribute to projects that are both interesting and meaningful. Unfortunately, it’s in the attempt to decipher relevancy and meaning that we can run into difficulty.
Launching something new is appealing because of all the fan-fare that generally goes along with it. There’s the immediate buzz associated with providing some kind of new experience. There’s a performative piece as documentation evangelizing the new delivery is written, the sales people get to pitching and selling, and finally, customers have a new thing to explore. All of this is good and incredibly valuable; expanding the capabilities of existing products, venturing into new untapped product areas—these are a boon to continued success.
But there’s another kind of work that can get lost in the weeds. Maintenance.
Maintenance matters
This work is equally important, if not more so. It’s the sort of effort that keeps operations flowing smoothly. Identifying and fixing bugs, streamlining processes, or more holistically, it’s the kind of work that keeps our previous launches generating all of that incredible impact I alluded to earlier. Otherwise, cracks can quickly emerge. Technical debt accretes further and further pain, oftentimes to the detriment of customers.
However, maintenance work provides a less fun story to tell. Of course, if you’re fixing a bug that winds up unblocking millions of dollars, then that’s a great and easy win to notch. But not every bug can tell that story, not every act of maintenance can be readily reduced to an enthusiastic pitch. And therein lies the rub. As engineers are often disconnected from customers, they rely on other teams to help understand where opportunities exist. Members of those other teams have their own considerations to worry about and their own stories to weave. In a world where impact is everything, it’s all too easy to devalue the time investment required to just keep the engine oiled, the wheels greased, and to make sure that the lights are kept on, so people can actually see a damn thing.
When you incentivize launches over maintenance, you establish a culture where the latter is not equally valued. Taken to the extreme conclusion, many people will follow the unspoken directive and prioritize delivering new launches over investing time in service. That’s how you wind up in a situation where everybody is fixated on the next new thing, instead of anyone worrying about the current thing. This sounds like an engineering problem, but really it’s a leadership failure. There needs to be an acknowledgement that maintenance matters, that solving existing problems is just as important as creating new things to solve other challenges. 
Admittedly this seems like a function of human nature, where we’re so quick to try flashy new things, yet we’re loath to put the hard work in. It’s the same sort of attitude that sees a person try all the latest fad diets but refuse to commit to one, or to any other kind of more foundational life change to reach their goals. One of the common truisms in engineering is the https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule
 rule. Loosely translated, it means that getting a project to 90% complete is generally the easier part. It’s the last 10% that takes substantially more time and effort. Now couple that with a launch culture where we’re also looking to move fast and break things.
Not all launches are easy. Not all maintenance is hard. Anyone who tells you otherwise is misleading you. The reason that the first 90% of a launch might feel easier is because oftentimes that’s the part where builders are allowed the most freedom to, well, build. It’s often in that last 10% where the less glamorous work hides; are there tests and documentation to write? Both of those will pay dividends to future consumers, including you or your teammates. The easiest bugs get fixed during initial development, and often the most obscure and challenging bugs get resolved in that final sprint.
Speaking in absolutes is foolish and the following certainly isn’t universal, but consider the refrain: “Let’s launch this as is and we’ll fix those bugs or add those missing features in the next version.” It’s more common than you might think, and how often do you actually get to work toward that second iteration? When leadership fixates on story-telling, it’s often the initial launch that’s most meaningful anyway. That’s got the most bang, the most immediate impact to the story. So fire off a launch and then move onto the next one, because there’s more impact readily available elsewhere.
To be clear, I’m conflating several aspects of product development here; fixing bugs is different from adding features. But from a maintenance perspective, I don’t think they’re completely separate. At a baseline, as a customer, I expect that a product will work. If there’s a missing feature that was promised, I expect it to be delivered. If there’s a requested feature, I expect it to be considered. And I expect bugs to be resolved in a reasonable amount of time. But what if leadership doesn’t see the value proposition in fixing a bug when there isn’t an obvious revenue component? What if the bug results in requiring an awkward, yet feasible workaround? Can you put a price on user satisfaction in those terms? Absolutely, but how does that stack up against adding a new feature entirely? Not well, I’d argue, at least not to a launch-driven culture.
Do all the things
The fact of the matter is that all of this work is valuable. The new features, the bug fixes, core optimizations, and new product launches. Leadership should recognize this, and work to incentivize all kinds of efforts, as we work both to meet customers where they are, as well as get ahead so we can meet them where they’d like to go. Otherwise, you may wind up in a situation where there’s a trail of poorly maintained launches, relying on the superhuman effort of heroic employees who go above and beyond to do work that is seemingly unappreciated. That simply isn’t sustainable. It leads to frustration, burn-out, and the abandonment of those efforts.
Launch culture focuses on the excitement of new features or products, while maintenance culture emphasizes the importance of ongoing service and improvement. Both are critical to long term success and perfect equilibrium is impossible. Skew too hard in either direction and you wind up over-indexing on either the novel or the existing, when ideally you want to excel at both. The key to navigating this impossibility is to recognize the value of both perspectives, and to invest in both as much as feasible. Even if the results are less dazzling at times, maintenance matters. It should be valued and incentivized by leadership too.

https://netigen.com/read/launch-vs-maintenance-culture