The manager-of-managers pattern, with agents

I run three product engineering teams through three EMs and two senior leads. The org chart isn't an accident — at a certain scale, you stop managing work and start managing the people who manage work. You set direction, remove blockers, and trust your managers to translate strategy into shipped features.

The same shape is emerging in agentic systems. A top-level orchestrator agent takes a high-level goal, decomposes it into sub-tasks, and delegates each sub-task to a specialist agent. The specialist does the deep work — reading code, writing patches, running tests — and reports back. The orchestrator reviews, re-plans if needed, and moves on. Manager-of-managers, except the managers don't take lunch breaks.

What I've learned running human teams transfers almost directly. Give every sub-agent a bounded charter. Don't have the same agent both plan and execute the same task — the ones who wrote the plan always rate their own plan as brilliant. Make the reporter different from the doer. For high-stakes work, have a second agent code-review the first. This isn't paranoia; it's the same reason I have two EMs on the release call.

The hard part — still — is context. My best EMs carry months of tacit knowledge about a system, a codebase, a team's quirks. Agents start each conversation at zero. So the real engineering investment in agentic orgs isn't in prompts; it's in persistent context: the CLAUDE.md files, the architecture decision records, the playbooks that used to live in someone's head. The org's memory becomes its operating system.

I think a lot of companies are going to discover this the hard way. They'll spin up a dozen agents, watch them do spectacular demos in week one, and wonder why nothing ships in week six. The answer is that they were running a dozen brand-new hires with amnesia. No human org works that way; no agent org will either. The companies that win here are going to be the ones that already know how to onboard.