On Paper, Yes

I have worked at quite a few large organizations now, and I have started to notice a pattern. The pattern is that there is much less of a pattern than anyone lets on.

From the outside, and to be fair from most of the inside too, a large company looks like a coherent thing. There is an org chart. There is a strategy. There are quarterly priorities, and roadmaps, and town halls in which someone explains the roadmap using the kind of slide that has four boxes and an arrow. It all seems quite orderly.

Then you actually start doing the work, and you discover that the orderly version is roughly as accurate as a tube map. Useful for navigation. Not, strictly speaking, much else.

The visibility economy

The first thing you notice is that visibility matters more than output. I do not mean this cynically. I mean it almost descriptively. In a sufficiently large organization, nobody can see what anyone is actually doing, so the legible signals of work become the work. The Slack message at 9:02. The presence in the meeting. The status update that uses the word “alignment” twice. None of these are the job, but they are the evidence of the job, and after a while the evidence becomes harder to distinguish from the thing itself.

This produces some genuinely odd behavior. I have watched two teams build the same internal tool without ever discovering each other, because each team’s existence was more visible to leadership than either tool was. I have sat in meetings whose entire purpose, as far as I could tell, was to establish that the meeting had happened. I have seen people promoted off the back of other people’s work.

Nobody is doing anything wrong here, exactly. It is just that ownership is fuzzy, communication is patchy, and politics, as ever, prevails. The org chart describes who reports to whom. It does not describe who actually decides things, who is owed favors, who went to university with the CTO, or who has the kind of unspecified seniority that means their objections in a meeting carry more weight than others’ regardless of who is technically right. That second org chart is the one that matters, and it is not written down anywhere, which is part of why it works.

The estimation problem

The second thing you notice is that non-technical managers often can’t estimate the length of technical tasks. It is genuinely difficult, from the outside, to tell which software tasks are trivial and which are quietly nightmarish. The two often look identical on a slide.

At one company, a manager once asked me to do something they were braced for me to say would take a week. It took about an afternoon. They were, I think, slightly suspicious that I had not done it properly, and I had to walk them through the result twice before they believed me. At another company, years later, I was asked to build something in a few days that any honest estimate would have put at a month of work for a small team. We landed, after one of those gentle British negotiations in which nobody quite says what they mean, somewhere in the middle. The thing eventually shipped, and the original ask, I am now fairly sure, was not what was actually needed.

The two-hour task budgeted as a quarter, the quarter-long project expected by Thursday. Both are versions of the same thing, which is that an enormous amount of engineering time is spent not building things but explaining what the things actually are.

The keepers

Every company I have worked at has had at least one. The person who built the thing. The person who is the only one who fully understands the thing. The person whose holiday is, quietly, a small organizational risk.

They are almost always pleasant. They are almost always overworked. There is a particular expression they wear when you ask them about the system they maintain. Somewhere between fondness and quiet resignation. The look of someone who has been having the same conversation about the same thing for a very long time. They will tell you, with great patience, that yes, it was supposed to be temporary, and yes, it has been seven years, and yes, there is a known issue with the part that handles dates, which they work around by not handling dates.

The system the keeper maintains is invariably more important than the org chart suggests, and the keeper themselves is invariably more senior, in real terms, than their title indicates. If you want to know what a company actually does, find the keepers and ask them. They will tell you, in a slightly weary tone, exactly what is going on.

The fragility nobody mentions

You put all of this together: the visibility economy, the estimation gap, the keepers and their slightly haunted look. What you get is a thing that is somehow both extremely advanced and slightly held together with sellotape. A project pauses for three weeks because one person is on holiday and nobody else has the access. A migration stalls because nobody can establish, after several meetings, who actually owns the system being migrated. A critical workflow turns out to depend on a spreadsheet that lives on one person’s laptop, which is, in the strictest sense, fine, right up until it isn’t.

None of this is a scandal. It is simply what large organizations are actually like, beneath the slides. The remarkable thing, honestly, is that they work at all. Most of them do. The economy keeps moving, the payments keep clearing, the planes keep landing. It is just that, if you spend enough time inside the machinery, you stop believing the version of events in which any of this was planned.

The same shape shows up wherever an institution gets big enough to have its own org chart: hospitals, governments, anywhere with a building and a logo.

Somewhere right now, in an inbox no one has opened, an email from three weeks ago contains the file that would answer the question everyone is still asking. The person who sent it is on holiday.

The meeting continues.