Org Design Debate — by an AI council
Decide how to structure a team or company as it grows. Four rival AIs debate it and hand back: A recommended structure with the trade-offs and the first reorganising step.
A recommended structure with the trade-offs and the first reorganising step.
Signed off by an independent Final QA audit — with a “verify before you rely on this” list, never a black box.
Why this team
Reorgs optimise for the diagram and forget the humans inside it, so this council splits the two: the COO and Operations Lead argue how work actually flows versus how the chart claims it does, the Systems Thinker traces the second-order effects — who stops talking to whom — and the People Lead prices the trust cost of moving people. The Strategy Consultant brings the pattern library of structures that worked elsewhere, and the Pragmatist keeps asking whether a smaller change fixes the actual pain.
Each seat runs on a different frontier model — GPT, Claude, Gemini, Grok — so it’s a genuine cross-model review, not one AI in costumes. How a run works →
What the debate sounds like
An illustrative excerpt — A 40-person startup organised by function (engineering, design, sales) finds every feature now needs four managers to agree, and is debating a move to cross-functional pods.
Name the real bottleneck before drawing pods: four managers agreeing is a decision-rights problem, not necessarily a structure problem. If ownership of each feature had one named decider today, would the pain persist? If not, you are about to run a company-wide reorg to fix a RACI chart.
Partially disagree — the functional structure is also creating queues: design waits on engineering estimates, sales commitments wait on both. Pods collapse those queues for product work. But pods duplicate skills, and at 40 people some functions have three specialists total; split them across four pods and each pod gets three-quarters of a person.
Whatever is decided, the sequencing is the risk: announce a full reorg and every one of the 40 spends a month wondering who their manager is. The alternative — pilot one pod around the most painful product area, leave the rest functional — gets the evidence without the anxiety. Reorgs are trust withdrawals; make the smallest one that works.
Questions
What should I describe about my current organisation?
Current size and structure, where work queues or decisions stall (with an example), what is driving the change, and the options you are considering. The example matters most — the council reasons from the specific pain, and “features need four approvals” leads somewhere different from “nobody owns quality”.
Will it recommend a textbook structure — pods, matrix, functional?
It recommends a structure, but the more valuable output is usually the trade-off named honestly: every structure buys speed somewhere by paying duplication or alignment cost somewhere else. The synthesis states what you are choosing to be worse at, which is the part reorg announcements always omit.
How do I handle the people side of announcing the change?
The final synthesis includes the first reorganising move and how to communicate it — sequencing, who hears it first, and what stays stable. In most debates the People Lead successfully argues for the smallest viable change, because trust spends faster than org charts redraw.
Your material is used only to run your review — never to train public models. Encrypted in transit and at rest. Security & privacy →
Want full control — pick your own minds, set the depth? Open the full council →