My theory of operational work

The first time I watched a project fail, I assumed it was because someone had the wrong idea. I was wrong about that, in the way you can only be wrong when you’re young enough to think organisations are rational. The idea had been fine. The deck had been fine. What killed the project was that the one person who understood how the deploy worked had taken a week off, the documentation lived in a Slack thread nobody could find, and the handoff between two teams happened over a single ambiguous sentence in a meeting nobody had taken notes on. By the time anyone reconstructed what had gone wrong, the moment to fix it was three months in the past.

I have seen versions of this play out enough times to be confident it isn’t unusual. It is, in fact, the normal way work fails. We talk about strategy and vision and product-market fit because those words flatter us and make for better dinner parties. We rarely talk about the boring thing, which is that most outcomes inside a company are downstream of operational decisions so small that no one remembers making them. The shape of a form. The default in a settings panel. Who’s on the email thread. Whether the CMS makes a non-developer afraid to touch the homepage. These are the decisions that compound, and most companies make them by accident.

The conventional view, the one I absorbed without noticing in my twenties, is that operations is a function. It sits next to product and engineering and sales on an org chart, slightly lower in status, slightly less interesting at parties. People who go into operations are often described, by people who don’t, as detail-oriented, a word meant kindly that lands as faint praise. The implication is that the real work happens elsewhere, and operations is what makes sure the real work can happen. I think that is exactly backwards. Operations isn’t the support function for the real work. It is the work.

Operations isn’t the support function for the real work. It is the work.

This view has consequences, and the most uncomfortable one is what it implies about how most companies are currently run. A lot of what passes for management in the start-up world rests on a story called “we hire smart people and get out of their way.” It is a flattering story. It sounds humane, even progressive, a rejection of the suit-and-tie command-and-control of the previous generation. In practice, it is usually code for an absence of operational thinking, papered over with talent density. It works for a while, because the smart people are in fact smart, and they will heroically absorb the cost of the system not being designed. Then the company grows past the point where heroics scale, and the same leaders who congratulated themselves on hiring well start complaining about execution, which is to say, they start blaming the people they left to figure it out alone. Real autonomy is expensive. It requires interfaces between teams that someone has actually thought about, decision rights that are written down somewhere, documentation that doesn’t rot, and a working mechanism for surfacing what isn’t working. Skipping all of that and calling the result freedom is just outsourcing the job to the people you hired to do something else.

A second story, even more dangerous in my view, is the one in which speed is a strategy. Move fast and break things, the slogan goes, and it has now had two decades to mature into the worldview of an entire industry. It worked once, for a particular company, in a particular decade, building a particular kind of product where the things being broken were mostly inconsequential. Since then it has been adopted as a creed by people whose products break things that are not inconsequential. Payroll systems. Healthcare scheduling. Immigration paperwork. The rent. The slogan persists because it gives founders permission to skip the unglamorous work of designing how an organisation actually functions. But speed is not a strategy. It is what happens when the system is set up well enough that careful work looks, from the outside, like velocity.

Underneath both stories sits a deeper confusion, which is the conflation of efficiency with good operations. The word efficiency, in the way most companies use it, means: squeeze the supplier, flatten the team, automate the human out, then ride the resulting margin for as long as the quarterly review cycle allows. That isn’t good operations. It is cost reduction dressed in the language of rigour, and the people who pay for it are usually not the people who decided on it. Good operations asks a different question, which is harder to answer and harder to slide-deck: what is this system optimising for, over what timescale, and who carries the cost when it goes wrong? The honest answer, in most companies, is that the system optimises for whatever shows up in the next earnings cycle, on a timescale that ignores the people doing the work, and the cost is paid by them. Some of this is a moral problem. More of it, for the purposes of this essay, is an information problem. A system that runs on the silent extraction of effort from the people inside it is producing worse data about itself than it could have for free. You can’t optimise what you refuse to hear.

This is the point at which my politics enter the argument, and I’m not going to pretend otherwise, because the pretence is part of what I’m criticising. I’m on the left. I believe in equality and in dignity at work, and I think those commitments have made me better at thinking about operations rather than worse. They have forced me to take seriously a fact that most management writing tries to wave away, which is that the person closest to a process knows more about it than the person who designed it. This isn’t a sentiment. It is something I have watched be true in every industry I have ever worked in or studied. The person on the till knows things about the point-of-sale system that the executive who bought it never will. The junior engineer knows things about the deploy pipeline that the architect can’t see from where they sit. The support agent knows, with a precision no dashboard captures, exactly which feature you should have built last quarter. If your operating model has no real channel for that knowledge to move upward and reshape the work, you are operating on worse information than you could have, for free, every day. The moral case and the operational case point at the same answer. They almost always do, in my experience. The tension between them is usually a story told by people who don’t want to do the harder version of the job.

There is a version of this essay, the version I would have written a few years ago, that ends with a tidy list. Three principles. Five steps. A framework with a memorable acronym. I have come to mistrust that ending. It lets the reader off the hook. The work I am describing isn’t a checklist. It is the slow, unglamorous activity of looking carefully at how your company actually functions, talking to the people inside it as though they are the experts they are, and being willing to change the things that the conversation reveals. There is no shortcut. There is only the work, and the willingness to do it.

What I will say, because investors keep asking me some version of the same question, is what I think this means for capital. The companies that will compound over the next decade aren’t the ones with the boldest vision or the loudest founder. They are the ones whose operations have been designed deliberately enough that the vision has somewhere to land. They will be quieter than the current crop of bets. They will be harder to summarise in a tweet. They will also, I suspect, be more durable, more profitable on long horizons, and less prone to the spectacular failures that have started to define this cycle. The ones that don’t take this seriously will keep mistaking activity for progress, and keep wondering why the deck refuses to turn into the company.