• john garrish
Software is (mostly) not waste
A focus on "efficiency" is the catnip of turnarounds. To the untrained eye, software companies are chaos factories and need to be "run better."
A focus on “efficiency” is the catnip of turnarounds. To the untrained eye, software companies are chaos factories and need to be “run better.” It is axiomatic that a company that requires a “turnaround” has had some measure of success, and is currently slowing, or perhaps flatlining. By transitive axiom, it is obviously not “well run.”
In this instance, two fundamentally different types of solutions to inefficiency are often conflated, treating them as equivalent when they are not.
In its most fundamental form, the business of software is inherently inefficient. The tools of the trade are experimentation and validated learning. Experimentation requires time, iteration, and the acceptance of dead ends. Product teams must explore new problems and test novel solutions. This is not waste per se - it is the cost of discovery and innovation. Waste in this sense is actually probably more efficient in the long run - it is risk reduction in the form of NOT building ideas that have no future.
Yet, as companies scale, this kind of inefficiency abounds. Pejoratively it might be called bureaucracy. It’s a natural consequence of growing larger as an organization. Sean Goedecke lays this problem at the feet of “legibility” which is an all-purpose explanation. It’s a masterful argument:
“By “legible”, I mean work that is predictable, well-estimated, has a paper trail, and doesn’t depend on any contingent factors (like the availability of specific people). Quarterly planning, OKRs, and Jira all exist to make work legible. Illegible work is everything else: asking for and giving favors, using tacit knowledge that isn’t or can’t be written down, fitting in unscheduled changes, and drawing on interpersonal relationships.”
Source: Seeing like a software company
To be clear, this is a valid efficiency problem. But solving this problem is a fairly straightforward exercise in minimal systems. Just enough control surface to ensure that the strategic intentions of the organization can be steered toward realization. Just enough process to reduce the (otherwise legitimate) waste from TOO MANY experiments, TOO MANY technology science projects, masterpiece building or any of the many pathologies that legitimately disrupt software companies.
Sadly this problem often produces a category error, of sorts. It’s what happens when the wrong solution is applied to the problem.
Consider an analogy of the company as a V8 engine. There is a belief, founded on any number of factors that the engine can be producing much more output. The engine therefore must be made to be more efficient, and therefore sources of inefficiency must be relentlessly eliminated.
But how? This is where the category error comes in. The prescription for improving efficiency is built around cost centers, and not around mission. To stretch the analogy, it is a philosophy based on each of the cylinders individually, not on the system as a whole.
It would be absurd to believe that each cylinder in a v8 should run differently, one with a turbo-charger, and another with a super-charger, and maybe a third with nitrous. Yet, this is the approach that is applied. Eight cylinders, eight individual approaches. The premise is that each individual cylinder can achieve optimal performance in isolation, and when combined, will result in a performant engine. However, in software as with engines, this fundamental misalignment tends to cripple the engine.
Such is the self-inflicted wound of many software companies that are in crisis. In the quest to run the engine better (i.e. the legitimate need for more legibility), the organization over-rotates and deploys a set of locally optimized functional improvements. And in doing so, actually GENERATES unrecoverable strategic inefficiency. It is the ill-conceived idea that functions can be individually organized for success, and that by doing so, all the “better run cylinders will make the engine run better.”
Unfortunately, as each team gets tasked to optimize its own metrics, the organization begins burning fuel at an alarming rate because it lacks a unified yardstick - that is, a reason to say no to bad ideas. People are doubled-up everywhere and new processes emerge to control the cross-org chaos. Leaders who “drive” across pillars are gradually replaced with experts in function. Gradually, the sum performs worse than its parts, and the essential capacities of the organization (sales, dev, product) begin to degrade. New leaders of the functions do all-hands and talk about HOW EXCITED THEY ARE TO BE A PART OF CHAPTER 2 but the sinking ship vibe is palpable.
In short, the fight against experimental inefficiency generates strategic inefficiency.
Software companies are notoriously fragile, and mostly operate as a faithful congregation. The employees tend to notice when the pastor is drunk, and spending a lot of time at the casino. After a few quarters, the drivers in the organization stop driving and burrow in - better to live to fight another day. Or worse, just go.
The solution of course is not complex, but it’s certainly hard. And as such, it means that it is out of reach for all but the most authentic teams, the 1 in a 100. It requires low ambiguity decisions, from the top. Relentless paring. Daily cadence. Strategic simplicity. Over-communication. Trusting teams. A willingness to interlock decisions on every dimension and coalesce every “cylinder” around a big idea. One big thing.
Frank Slootman articulates this nicely in his books and online:
“We compensated the ServiceNow exec team on just one metric. It was unquestionably the purest performance metric for a cloud software company. Our board fought me on this. They were convinced a grown up company had to have a balanced scorecard, arguably the worst idea to ever come out of academia. People say they want focus, but their actions do not bear it out, quite the opposite. Focus is hard once you understand what that means. What are you not going to do?”
From: Amp it up!
It can be said that the only real cost in software is opportunity cost: spending time on something less valuable, and missing the opportunity of something much, MUCH more valuable. In the quest for efficiency, the prescription is to remember the mission. The main thing is to solve revenue-bearing problems that matter and this is EVERYONE’S JOB. Missing those opportunities is the real inefficiency.