Engineering leadership was never the headcount.

Will Larson's argument, delivered on Gergely Orosz's podcast last week, is that the engineering manager of the 2010s was a zero-interest-rate artefact. Cheap money bought headcount, headcount needed managing, and a profession grew around the managing.

The numbers he gives are the ones in the ledger above. Managers who used to run 4 to 8 people now run 12 to 14. His own move was from a team of 250 at Carta to 25 at Imprint. His advice to the middle manager caught in that squeeze is blunt: retire or re-skill. And he offers one line that explains the whole decade: he was once told, as a manager, to never make a technical decision again.

I have spent 18 years in this industry, 8 of them leading teams, and the last 4 running AI platforms in production. I run engineering at Max Planck Dev and sit in the fractional CTO chair for a series of client leadership teams, which means I arrive after the hiring was done and before anyone has said out loud what went wrong. From that chair, Larson's diagnosis is right about the shape and wrong about the cause. The profession is not disappearing because the money got expensive. It is disappearing because it was measured on the wrong output, and the cheap money hid that for a decade.

What the job was built to produce

Ask what a 2010s engineering manager was accountable for and you get a consistent list. A hiring plan and the pipeline to fill it. An org chart that made sense to the board. Throughput, measured in whatever the tooling counted that year. Retention, one-on-ones, performance cycles, the quarterly reshuffle.

Every item on that list is about people. None of it is about the thing the people were building. "Never make a technical decision again" was not an insult. It was the job description, and a lot of good people followed it faithfully.

Which leaves an obvious question. If the manager was told not to decide, who did?

Decision backlog

The accumulated set of architectural choices an organisation is living with that nobody explicitly made. Each one was settled by default, by whoever was in the file that day, and has never been written down, owned, or priced for reversal.

Decision record

A short document stating what was decided, why, what the alternatives were, what it would cost to reverse, and who owns it. The architecture decision record, or ADR, is the common form.

Reversible

Not "easy to undo". Reversible means the cost of undoing it is known at the time it is made, so the company can change its mind at a price it agreed to in advance.

The decision backlog

The companies that call me have someone with the title. A VP of Engineering, a Head of Technology, sometimes a CTO who came up through product. The org chart is fine. The hiring plan is defensible. What they do not have is an answer to the question I ask first: who made your last three architecture decisions, and where are they written down?

The honest answer is usually the same. The database was chosen by the first engineer. The queue was added by the second, during an incident. The model vendor was picked by whoever ran the proof of concept, and the proof of concept became production without anyone deciding that it should. None of it is written down. None of it is reversible at a known price, because nobody priced it.

That is the backlog. It does not show up in Jira. It shows up as "the architecture", which everyone complains about and nobody owns, and it is what the roadmap is secretly downstream of.

The backlog is not features. It is decisions nobody owned.

The clearest case I have worked on was not a startup. It was a hotel group with more than 20 properties, three property-management systems, an SAP ERP and over 50 active tools spread across eight operational layers. Nobody had decided on any of that. It had accreted, one property and one vendor at a time, each choice reasonable on the day. The engagement was an AI adoption and governance roadmap, and the first deliverable was not a roadmap at all. It was a map: every system, every layer, every place where data had to cross a boundary.

The most expensive finding on that map was what I came to call the golden track. Several systems already produced the KPIs the leadership team said they lacked. The numbers existed. They were computed every day, inside tools that nobody had decided should feed the BI layer, and so they never got there. Each gap was an unmade decision about which sources must reach reporting, and each had been invisible precisely because nobody had been asked to make it.

That is what a decision backlog costs. Not a dramatic failure. A company paying for insight it already owns, because the decision to connect two systems was never anybody's job.

What a record looks like

The fix is unglamorous, and it is the part of my work that a leadership team most often tries to skip. Decisions get made explicitly, written down, and priced for reversal. I use architecture decision records for this, and I have yet to find a format that needs more than one page.

Notice what the record is not. It is not a design document. It does not explain how the thing works. It states a choice, the alternatives that lost, the price of changing course, and a name. Anyone in the company, including the person who joins next year, can read it in two minutes and know whether the ground under them was chosen or merely found.

Notice also what it makes possible. When a vendor doubles its price, which one major model provider has already scheduled for December, the question is not "how exposed are we?" It is "the record says one afternoon; let us check that is still true." The decision backlog turns a price change into a crisis. The decision record turns it into a Tuesday.

Why agents make this urgent

Everything above would have been true in 2016. What changed is that the organisation is no longer only delegating to people.

The open-source agent workflow I maintain runs ten specialist roles, and the rule that makes it work is that every role hands the next one a versioned artefact. A durable document, not a recollection. An agent has no hallway. It cannot ask the engineer who was in the file that day. It has exactly what was written down, and nothing else.

That is the delegation boundary now, for people and for software alike. "If it is not written down, it does not exist" used to be a documentation principle, the kind of thing a conscientious team lead said and nobody enforced. It has become a hard limit on what you can hand off. A company that cannot write its decisions down cannot delegate to agents, because an agent only has the record. The same company will struggle to delegate to a manager with 14 reports, for the same reason. Nobody with 14 reports is in every file either.

An agent has no hallway. It has what you wrote down, and nothing else.

This is why Larson's squeeze and the rise of agentic development are the same story. Both remove the thing that was quietly substituting for a decision record: a manager with enough slack to be in the room when the choice got made. Take that away, and either the record exists or the decision gets made by default again, now by a tool.

What this does to the role

Larson says hiring is the least interesting way to solve every problem. I would go further. For a technical leader, the decision record is the most interesting output there is, and the 2010s manager was trained not to produce it.

Running an engineering organisation end to end, which is the job I do at Max Planck Dev and the job I do fractionally for clients, means owning the hiring, the technical direction, the delivery process, and the conversations with clients and investors about all three. Every one of those gets easier when the record exists. The investor who asks why this stack gets an answer with a date on it. The new hire gets a reading list instead of a tour. The roadmap conversation stops being an argument about architecture nobody chose.

So the role Larson sees shrinking is the one that managed people and declined to decide. The role that replaces it is smaller in headcount and larger in consequence: fewer people, more decisions, each one written. That is not a demotion for the people doing it. It is the part of the job that was always supposed to matter.

What I am not claiming

• That managers are obsolete. People still need managing. The point is that managing them was never the whole job, and for a decade it was treated as if it were.
• That AI replaces this. It consumes it. A tool that has to be told what was decided makes the absence of a record more expensive, not less.
• That I can show you a chart. I cannot prove that decision records raised anyone's velocity. The control group would be the same company without them, and that company does not exist. What I can show is the backlog, every time, in the first week.

Monday

If you run a company and want to know whether you have a decision backlog, you do not need an audit. You need three questions, asked of whoever holds the technical title, and you need to notice how long the answers take.

1. Who made our last three architecture decisions?If the answer is a team, a committee, or "it kind of evolved", nobody made them.
2. Where are they written down?A Slack thread is not a record. A Notion page nobody can find is not a record. If it cannot be handed to a new hire or an agent and read in two minutes, it is a recollection.
3. What would it cost to reverse one of them?Not whether it would be hard. What it would cost, in weeks and money, stated before the day you need to know.

Those are the first three questions I ask in a new engagement, and the answers decide what the next 60 days look like. In most companies the answers are not bad. They are absent. Which is the whole argument in one observation: the title was filled, the org chart was tidy, and the one thing the job was for was never asked for.

The job was never the headcount. It was the record.