← Recaps

Buildrs Notes · 8 min

Designing a Team of Teams

The rule: split where context doesn't want to mix. The right axis is whichever boundary costs the most to cross.

Everything else — names, counts, org charts — is downstream of that one call.

The three axes

AxisWorkflow (stage)Axis 1Domain (industry)Axis 2Goal (outcome)Axis 3
Use whenOne artifact moves through steps, and each step needs different tools or standards.Knowledge genuinely doesn't transfer — different vocabulary, sources, regulations, buyers.Two efforts would make opposite calls on the same decision, and you want that tension explicit.
Each team ownsA stage: research → draft → review → publishA body of context: insurance, healthcare, fintechA metric: acquire, retain, expand
Fails byLost handoffs. Context evaporates between stages; team 3 doesn't know why team 1 chose what it did.Duplication. Five teams each rebuild the same drafting and review capability.Collision. Two teams unknowingly do the same work, or fight over the same surface.

Same business, split three ways

An agency doing client work, content, and one product:

Workflow
IntakeResearchBuildQAShip
One pipeline. Everything flows through it.
Domain
Financial servicesHealthcareRetail
Each holds its own client context, end to end.
Goal
New businessDelivery qualityProduct revenue
Each optimizes one number.

Pick the one where crossing the line hurts most. If your healthcare and retail work share nothing but a logo, split by domain. If every project runs the identical five steps, split by workflow and stop there — that's a pipeline, and pipelines are cheaper and more reliable than agent teams.

Depth: three machine layers, max

You (escalations only) → orchestrator → team leads → workers

Allie Miller runs exactly this: her → Simon (AI chief of staff) → six directors → 34 agents. Every layer past that multiplies failure points without adding capability — orchestrators-of-orchestrators is where these systems start eating themselves.

Model routing follows depth. Her subagents run on Haiku and Sonnet; Opus is reserved for heavy work. Keep the orchestration on your strongest model — deciding what goes where is the hard part — and push the cheap models down to the workers.

Naming: start borrowed, then evolve

Her warning: 2015 job titles produce a 2015 org. Name everything CMO / CPO / frontend engineer and you've rebuilt a company from a decade ago.

But her advice is also to start there, because it's legible. The move is to start with borrowed titles and then earn your way off them — because agents cost roughly nothing at the margin, so you can hire roles no human budget would approve:

Phoebe
Chief dreaming officer
Sits at the end of the chain, asks one thing of every output: how do we 10x this?
Toby
Friction-watcher
Only job is watching the workforce work, logging where things snag, and flagging "you keep correcting this — has this agent got access to that folder?"

Worth noting honestly: her own six directors are split by business function (education, client work, ops, marketing, product) — which is the goal axis in 2015 clothing. She'd say that's fine as a starting shape. It's also why one of her watchdogs specifically hunts duplicate work — that's the goal split's known failure mode, patched.

The design prompt

I run [business]. Team is [N humans]. We do [what].
Our goals this quarter: [goals].

Before proposing anything, interview me one question at a
time on: where my work already splits naturally, which
boundaries are expensive to cross, and what I keep
re-explaining.

Then propose an agent org with:
- the split axis you chose (workflow / domain / goal) and why
- 3 machine layers max
- what each team owns and what it must NOT touch
- one friction-watcher whose only job is logging where I
  keep correcting output
- which layers run cheap models vs. the strongest one

Do not use job titles from a 2015 org chart unless you can
defend each one.

Before you build any of it

Two checks, in order:

  1. The necessity test. For every team: what does this one know or reach that the last one didn't? No answer, no team.
  2. The invariant. Write two columns before you expand anything — may now touch (grows freely) and may act unsupervised (moves only on purpose). Breadth is the knob you turn. Risk is the one you weld.
Grows freely
May now touch
Breadth. The knob you turn. New folders, new drafts, new research — the surface can widen as the work asks.
Moves only on purpose
May act unsupervised
Risk. The one you weld. Send, spend, delete, publish — these don't grow because the org got bigger.

Standing it up takes about three hours. Getting it to 90% took her months, because the fixes are specific to how you actually work. Both halves of that are true.