The fastest way to look serious about AI is to redraw the org chart.
It is also the easiest way to avoid redesigning the work.
Something predictable happens when an AI mandate lands on an executive's desk. Within a meeting or two, someone produces a new org chart. Boxes move, boxes vanish, a headcount number gets smaller, and the slide looks decisive. It feels like leadership. It photographs well in a board deck.
I want to argue that it is almost always the wrong first move, and that the order of operations here matters more than the courage of the cut.
A few days ago I wrote about the economics of this moment in The Subsidy and the Severance. The short version is that the salary-for-subscription swap is usually fake math, because the real cost of AI includes inference, supervision, rework, and the institutional knowledge you only notice once it walks out the door. Jack Dorsey's plan to cut Block by nearly half was the loudest version of the bet. Klarna is the early warning sign: automate the visible work too aggressively, and the invisible work comes back as quality problems, support load, and human rework.
That essay was about why the math is fake. This one is about what to do instead, and specifically about what to do first.
Here is the thesis. Your first AI reorg should redesign the work, not the people. Before you touch the org chart, redesign four things: the workflows, the decision rights, the ownership, and the evaluation loops. The org chart is the last artifact in that sequence, not the first. It should describe a system you have already designed, not a system you are hoping to discover on the far side of a layoff.
The org chart is a downstream artifact
There is a reason the org chart is such a tempting place to start, and it is not strategy. It is legibility. Headcount is the most legible lever an executive owns. It is a single number, it moves in one direction, and it fits on one line of a board update. Workflows, decision rights, ownership, and evaluation loops are none of those things. They are messy, they resist a clean headline, and they take real work to change. So leaders reach for the legible lever, and legibility quietly gets mistaken for correctness.
In 1968, Melvin Conway observed that organizations build systems whose structure mirrors their own communication patterns. We usually quote Conway's Law to explain why our software ends up shaped like our org chart. The same logic runs in reverse, and right now the reverse is the useful direction. If your structure ends up mirroring your system, then you should design the system first and shape the structure to fit it. Redrawing the org chart before you have redesigned the work is rewiring the building before you know where the rooms go. You can do it. You will just be guessing.
So before the boxes move, here is the actual work.
Workflows: redesign the path before you remove the people on it
Most teams have never mapped how their work actually flows. They have a Jira board, which is not the same thing. Before you decide who is redundant, trace the real path of a unit of work from request to production, and mark every place where it waits, where it gets handed off, and where it queues behind a scarce human reviewer.
AI changes which steps on that path are expensive, and that is the whole reason a reorg is on the table in the first place. For twenty years we optimized workflows around the assumption that writing the code was the slow part, so we protected senior engineers and routed everything through them. When an agent can produce a credible first draft of the implementation in minutes, the slow part is no longer production. It is specification on the way in and review on the way out. A workflow tuned for scarce production is the wrong shape for abundant production, and no amount of headcount math fixes a path that is pointed in the wrong direction.
Consider the failure mode I described in the last essay. A team hands an agent a vague ticket, "clean up the auth flow," and the agent reads half the repo, edits the wrong abstraction, writes tests around its own misunderstanding, and opens a confident pull request that a senior engineer has to unwind. That is not a headcount problem you can solve by removing the senior engineer. It is a workflow problem. The path had no clear specification at the front and no real acceptance gate at the back. Redesign the path, and that same agent becomes genuinely useful. Cut the person and keep the broken path, and all you have done is automate the confusion.
Decision rights: write down who decides, including the machines
Every workflow contains decisions, and most organizations have never written down who actually gets to make them. The decisions happen anyway, quietly, in the heads of experienced people who know that this kind of change needs a second set of eyes and that kind of change can ship on a Friday. That tacit authority is invisible right up until you remove the person holding it.
An AI reorg forces the question into the open, because now some of the actors are not people. You have to decide, explicitly, what an agent is allowed to decide versus what it is only allowed to recommend. An agent can open a pull request. Can it merge to main? An agent can draft a customer reply. Can it send one? An agent can propose a schema change. Can it apply one to production? These are not philosophical questions. They are policy, and the policy needs to exist before you change who is in the room, not after.
Map the decision rights across the redesigned workflow first. Decide which calls a human must own, which an agent may make inside guardrails, and which require a human to confirm a machine's recommendation. Do that honestly, and you will often discover that the reorg you actually needed was a clarification of authority, not a reduction in people.
Ownership: an agent without an owner is a production system with no on-call
Decision rights tell you who makes a call. Ownership tells you who is accountable when the call goes wrong and who maintains the thing over time. The two are easy to blur and expensive to confuse.
This is where agent ownership becomes the quiet center of the whole exercise. When you deploy an agent into a workflow, you are deploying a production system. It has prompts that drift, guardrails that need tuning, dependencies that shift underneath it, and failure modes that surface at the worst possible moment. Someone has to own all of that. An agent without a named owner is a production system with no on-call rotation, which is to say it is an incident with a delay timer.
The trap in a headcount-first reorg is mechanical. You remove the person who implicitly owned a workflow, you hand the workflow to an agent, and you never assign the agent an owner. Now the work has no human accountable for it at all. You did not save a role. You orphaned one. The honest version of an AI reorg often adds ownership work even as it changes the shape of the team, because every agent in production should have a named human owner, a written spec, defined guardrails, and a rollback path. That is not overhead. That is the line between an operating model and a liability.
Evaluation loops: instrument the work before you bet the org on it
The fourth redesign is the one most often skipped, and it is the one that protects you from your own optimism. Before you make a structural bet on AI-augmented work, you need a way to tell whether the work is actually getting better or just getting cheaper to produce while quietly getting worse.
This is the Klarna lesson restated as an instrument. Klarna did not wake up one morning to a broken support function. Quality eroded gradually, under a story everyone wanted to believe, until the gap grew large enough to force a reversal. An evaluation loop is what catches that erosion in week three instead of quarter three. It means setting a baseline before the change, then watching the measures that actually correlate with value: accepted output rather than generated output, escaped defects, cycle time, rework, operational load, and customer outcomes. In the new economics, value per token replaces tokens consumed as the number worth organizing a team around.
Here is the sequencing point that matters most. If you reorganize first and instrument later, you have no baseline, so you cannot tell the difference between a workflow that is working and one that is failing slowly. You will be reading the boomerang's flight path from memory. Put the evaluation loop in place first, let it run against the redesigned workflow, and your eventual structural decisions get to rest on evidence instead of on a narrative that happened to test well in a meeting.
Redesign, run, then reshape
Put those four together and the order of operations almost writes itself.
First, redesign the work. Map the workflows, assign the decision rights, name the owners including the owner of every agent, and stand up the evaluation loops. Second, run it. Let the redesigned workflows operate long enough, and the instruments collect enough, to show you where the work actually concentrates and where it genuinely thins out. Third, reshape the org to match the work that emerged. Now the org chart is doing its real job. It is describing a validated system rather than gambling on a hypothetical one.
If I were putting this into an operating review, the table would be simple.
| Layer | Question to answer before the reorg |
|---|---|
| Workflow | Where does work actually wait, loop, hand off, and require judgment? |
| Decision rights | Which decisions can an agent make, recommend, or never touch? |
| Ownership | Who owns every workflow, agent, guardrail, rollback path, and failure mode? |
| Evaluation loops | What baseline tells us whether the work is improving or only getting cheaper to produce? |
| Org shape | What structure reflects the validated work instead of the hoped-for savings? |
This is the inverse of the headcount-first reflex, and it produces a very different kind of decision. When the structural change finally comes, and some of it will, it is legible for the right reason. You can point to the workflow it reflects, the decision rights it encodes, the ownership it assigns, and the evaluation data that justified it. That is a reorg you can defend to your board, to your team, and to yourself at two in the morning when the first big incident lands.
What I am not saying
Let me be precise about what this is not. It is not an argument that headcount never changes. Some roles will genuinely disappear, some teams will get smaller, and some work is going to move permanently to machines. It is also not an argument for studying the problem forever while your competitors move. The redesign I am describing is measured in weeks, not years, and most of it is work you should have done regardless of AI, because unclear workflows, undocumented decision rights, orphaned ownership, and missing evaluation loops were quietly taxing you long before anyone said the word agent.
The argument is only about order. Do the work before the people. Design the system before you draw the boxes that are supposed to describe it.
The bottleneck is never the org chart either
I keep coming back to the same line because the economics keep proving it. The bottleneck is never the stack. It was never the language or the framework or the cloud, and it is not the headcount either. The constraint has always been whether the work is designed well enough for someone, or something, to do it well. AI did not change that. It just raised the price of getting it wrong and moved the bill to the front of the room.
The leaders who win the next few years will not be the ones who cut first. They will be the ones who redesigned the work first, measured it honestly, and let the org chart follow. That is slower than a dramatic announcement and a 24 percent stock pop. It is also a great deal harder to boomerang.
I intend to take the slower path on purpose. I suspect the best people you know are quietly doing the same.
Sources and further reading
- Vinny Carpenter, "The Subsidy and the Severance": https://vinny.dev/blog/2026-06-02-the-subsidy-and-the-severance/
- Vinny Carpenter, "The Frame Is the Bottleneck": https://vinny.dev/blog/2026-05-24-the-frame-is-the-bottleneck/
- Vinny Carpenter, "The Spec Is the Product": https://vinny.dev/blog/2026-05-12-the-spec-is-the-product/
- Vinny Carpenter, "The Bottleneck Is Never the Stack": https://vinny.dev/blog/2026-05-13-the-bottleneck-is-never-the-stack/
- Melvin Conway, "How Do Committees Invent?", Datamation, 1968, the origin of Conway's Law
- Matthew Skelton and Manuel Pais, Team Topologies, IT Revolution Press, 2019, on designing teams around the flow of work
