The Container

It isn't about AI adoption, silly.

At one of my jobs, we spent three months debating whether to build a feature.

Not building it. Debating whether to build it. First we estimated the potential ARR we thought we’d get. Then we debated the estimate. Then we re-estimated it with different assumptions. Then we estimated the engineering hours. Then we debated those estimates. Then we had a meeting to reconcile the ARR estimate with the engineering estimate to determine if the ROI justified putting it on the roadmap. Then we debated the roadmap.

Three months. Exposed to the full salary cost of every person in every one of those rooms just in order to decide whether or not to do the thing.

The people in those rooms were not stupid. That is what made it hurt. They were smart, capable people who had been turned into professional guessers. Their job was not to build. It was to estimate, debate, and justify. Everyone in the room knew the estimate was a fiction. We built it anyway because the system needed a number before we’d let anyone touch the code.

In the world I live in now, I would have just built it. In a week or less and shipped it. Then known.

But that was not an option then. Building anything took so long and cost so much that you had to be sure before you started. So you spent a quarter making a guess and calling it “your plan.”

You and I know that every company is shaped by its constraints. This is so obvious that nobody says it out loud.

The number of people on a team is not often determined by the complexity of the problem. It is determined by last year’s budget plus whatever headcount someone managed to negotiate. The org chart is not a map of the work. It is a map of decisions that few remember making.

A product with a mobile app, a web app, a backend, and an external API needs at minimum four people who can hold those things in their heads at the same time. Add a design system. Add more infrastructure. Add a PM to coordinate the humans. Add a manager to keep the PM sane. Add a second manager because the first one now has ten reports. Soon you are at fifteen people and you have not added a single feature.

You have added the capacity to add features.

This is the container. Every company builds one. It gets sized for the work, and then the work is sized for the container.

Nobody designs their container on purpose. It accretes.

But first maybe you start with three people who can do everything. Then you hire a fourth because someone needs to own the thing the other three keep dropping. Then a fifth because the fourth created a coordination problem that did not exist when there were three. Then a sixth because the fifth needs someone to talk to about the coordination problem.

By the time you have thirty people you have real structure. Maybe HR? Definitely standups and sprint planning and soon quarterly reviews. Career ladders. Comp bands. All of it reasonable. All of it necessary.

None of it “the work.”

You know this. You have lived it. You have sat in rooms where smart people spent an hour talking about talking about the work, and you looked around and thought: this can’t be right.

And then you stopped looking around. You got used to it. You learned to call it process. You started defending it to new hires who asked why everything took so long. That is the part that should sting. Not that the system is broken, but that you made peace with it.

It isn’t right. But it is organizational physics.

I was Chief Product Officer at a company that had hundreds of engineers. The product was good. The people mostly talented. And I would estimate that less than thirty percent of the total organizational energy went toward making the product better for customers.

Thirty percent.

The rest went toward coordination, alignment, communication, planning, re-planning, and the dreaded meetings about the meetings.

That number is not a failure of execution. It is not a management problem you solve with better standups. It is the cost of running a human system at scale. Coordination costs grow faster than headcount. Communication complexity is n-squared. Every person you add creates new edges in the graph. The work does not get harder. The container gets harder.

I’ve spent twenty years inside containers.

At Google, at Dropbox, at GitHub, at Pluralsight. Big orgs, talented people, impactful work. And at every one, the same pattern: the roadmap was primarily shaped by what the container could produce.

The container set the ceiling.

The roadmap filled the container.

The metrics measured how well the container performed.

Nobody measured whether the container was the right shape.

Few leaders can really ask: Is the container the right size, or is it the only size we know how to build?

Those are different questions. The first is about optimization and the second is about both assumptions and internal honesty.

Most operational thinking is optimization. Better processes. Better tools. Fewer meetings or better meetings. All good. All necessary. All operating inside a fixed assumption: this is how many people it takes to build this thing.

But what if that assumption is mostly wrong? Not just slightly wrong but structurally wrong. What if the size of every software company was always set by execution constraints, not by the complexity of the problems being solved?

If that were true, the right response would not be better processes. It would be questioning whether the container should exist in its current form at all.

In the old world, ninety percent of the work was execution and ten percent was judgment.

Knowing what to build took a week. Building it took a year. So you hired for the year, and the organization took the shape of the year.

That ratio was the container’s foundation. Not the complexity of the problems. Not the ambition of the roadmap. The ratio. In relative terms, judgment was cheap. Execution was expensive. Every company on earth (at least in Tech) was organized around that fact.

What if the ratio reversed?

What if someone built the product surface of a fifty plus person company with a handful of people in five months?

That is not a hypothetical. We are launching in April. Just a handful of people. I am one of them.

Preview the product here. I co-founded our company, SpecStory, with Jake and Sean in late 2024.

AI.

The reason this was possible is the reason this meditation has not mentioned the word until now. Not because management theory changed (we talk to one another daily). Not because someone invented a better planning process (we use a weekly markdown file). Because the execution constraints that determined the shape of every software company for the last twenty years are fundamentally different. The container has always been a function of how many humans it took to do the work. And when that number changes so does everything else.

Building this product has been a crucible.

The hard part was the same thing it has always been: knowing what to build, why it matters, and which tradeoffs to accept. Intent. Context. Judgment. Those did not get easier. They got more important, because the cost of executing a bad idea dropped to near zero and it’s easy to build the wrong thing faster than ever before.

We’ve been building in the new ratio. Most of the work has been deciding what to build, how it should feel and how it should fit. The execution has followed.

Now. Here is where most people hear this story and jump to the wrong conclusion.

They hear “a handful of people built what fifty used to build” and they think: so we need fewer people.

That is the lazy version. And it’s wrong.

Think about what people in a fifty-person engineering org actually spend their days on. Translating requirements into tickets. Breaking work into pieces small enough to hand off. Sitting in standups to synchronize those pieces. Reviewing code not because it really needs a review but because no single person has enough context to ship without it. Writing status updates. Reading status updates. Negotiating what gets built next quarter because building anything takes so long that you have to choose carefully.

That is not the work. That is the container.

Now remove those constraints. Not the people. The constraints.

When execution is AI fast, you do not need to break work into twelve tickets across four engineers. One person can hold the whole thing. If one person holds the whole thing, you do not need the same type of standup. If you do not need the standup, you do not need someone to run the standup. If building something takes days instead of months, you do not need a quarterly planning process to decide what to build. You just build it and see.

What you get is not a smaller team. You get a team that does different work.

The engineer who used to own one microservice now owns an entire product surface. The PM who used to write tickets now is involved hands on making and executing product decisions. The designer who used to hand off mockups now ships the design. Everyone moves closer to the work that matters and further from the process that existed because humans are slow and need coordination.

This is the hard part. Not cutting. Redesigning.

Most leaders, when they hear that execution constraints are possible to collapse, reach for the obvious lever: same work, fewer people. They have not built anything with these tools. They have not sat with an agent for a weekend and felt the floor move. They read a breathless LinkedIn post, skimmed a McKinsey deck, and concluded that AI means headcount cuts. That is not a strategy. That is a spreadsheet reflex. And all it does is shrink the old container. Same assumptions about scope, speed, and ambition. Fewer people carrying them.

They burn out.

You lose.

The better version is harder. If your team can now move at three times the speed, do not cut two thirds of them. Ask what you would build if you could build three times as much. Ask what you never attempted because the coordination cost made it infeasible. Ask every person on the team what they would do if nothing stood between them and the work.

Then redesign the container around the answers.

The question is not headcount. It is ambition.

The container was always a ceiling on what you could attempt. The ceiling just moved. The interesting question is not how to run the old org with fewer people. It is what you build now that the ceiling is gone.

That question is uncomfortable. Not because it threatens jobs. Because it threatens assumptions. It forces you to admit that the roadmap was never a map of what customers truly and honestly needed or deserved. It was a map of what the container could produce. And now your container could produce almost anything.

Most companies will not ask this question. They will optimize the old container. Better metrics. Better tooling. Fifteen percent improvement. Dashboard green.

And somewhere, while they are doing that, a small team is building the thing their fifty-person (or hundred person) org is planning to start next quarter. Not because they have fewer people. Because they have fewer constraints. And they are using that freedom to attempt things the old container would never allow.

They will not estimate the ARR first. They will not debate the engineering hours. They will not reconcile the estimates in a meeting and then debate the roadmap.

They will just build it. Ship it. And know.

The container is changing shape. You can redesign it or you can keep optimizing the one you have until you're made irrelevant.