The Manifesto

Most engineering organizations are not optimized for building. They are optimized for legibility. Legibility to leadership. Legibility to boards. Legibility to the kind of person who needs a dashboard to know whether the company is shipping. Layers of management exist not because the work demands coordination at that density, but because someone above needs the work translated into language they can present without asking follow-up questions. The entire structure -- the directors, the program managers, the weekly status rituals, the quarterly planning theater -- exists to make complex work look simple to people who do not do it.

This was an acceptable cost when building was expensive. When producing software required large teams, long cycles, and deep coordination across handoff boundaries, you could justify the overhead. The translation layers had a reason to exist. Somebody had to sit between the people writing code and the people writing checks. The tax was real, but so was the complexity it nominally managed.

AI changed the cost function. Not theoretically. Not eventually. Now. The cost of producing working software has collapsed by an order of magnitude for anyone willing to use the tools seriously. A single person with domain expertise and an AI pair can produce in a day what a cross-functional team of eight produced in a sprint. That is not a projection. That is Tuesday. I have watched it happen in my own teams. I have watched non-engineers -- people who had never opened a terminal -- ship working internal tools in an afternoon because somebody showed them how to describe what they needed.

When building gets that cheap, the coordination overhead becomes the dominant cost. Not compute. Not cloud bills. Not even salaries. The most expensive line item in your engineering budget is the organizational structure itself -- the meetings, the alignment rituals, the translation layers, the handoffs between people who could have just built the thing. AI did not create this problem. It made it impossible to ignore.

The compressed organization is a response to that visibility. Not a restructuring exercise. Not a headcount reduction memo dressed up in thought leadership. A fundamental rethinking of what an engineering organization exists to do and how few layers it takes to do it well.

The core unit is the fire team: one Expert Scaler paired with one Slop Cannon. The Expert Scaler holds architectural context, system-level taste, and the judgment to know what should not be built at all. The Slop Cannon builds -- fast, creative, unafraid to ship something rough if rough is what the problem needs right now. Together they form a pair that is more dangerous than either could be alone. Loosely coupled to the rest of the organization. Deeply stateful in their domain.

Leadership in this model does not disappear. It transforms. The job of a leader becomes problem curation and taste. You are not managing people. You are not translating status. You are identifying the highest-value problems, matching them to the right fire team, and staying out of the way while they execute. You are the person who knows which hill matters this week. That is a harder job than managing a Jira board. It requires judgment that cannot be automated.

This is not downsizing. This is resizing. Most organizations carry three to five times the coordination overhead the work actually requires. The compressed org strips that away and reinvests it into builder capacity. Domain experts become builders. Juniors become dangerous. The people who used to sit in status meetings now sit in front of a terminal, paired with AI, shipping real work. Not because they were forced to. Because the tools finally met them where they are.

The question is not whether this transition is coming. The question is whether you will lead it or be reorganized by someone who does.