# Your Next Team Is Three People and a Pile of Agents. **Author:** Ivan Misic **Published:** 2026-06-17 **URL:** https://ivanmisic.net/blog/ways-of-working/next-team-three-people-pile-of-agents > The reflex when a team speeds up is to add specialists. AI flips it. The team that ships next is smaller, owns the whole workflow, and runs what it builds. When a team starts shipping faster, the reflex is to feed it more people. More lanes, more specialists, another layer to keep the lanes from colliding. If you have spent any time inside a growing org, you have seen this, maybe run it yourself. And for a few decades it was the correct instinct. Add capacity, get throughput. That instinct is now quietly wrong, and most org charts haven't caught up. I watched a talk recently that sharpened something I'd been circling for months: the shape of a high-output team is inverting. Not shrinking at the edges. Inverting. The teams that do the most interesting work next year won't be bigger versions of today's teams. They'll be smaller, a little strange, and organized around something other than a column of job titles. ## The team you have was built for handoffs Picture the standard delivery squad. Six to eight distinct skill sets, and often ten, fifteen, twenty people once you count everyone, each holding a lane. A product manager. A backend engineer. A frontend engineer. A data engineer. Someone on QA. Someone on security review. Someone running the deploys. Each person is excellent inside their lane and dependent on everyone else wherever those lanes meet. That structure exists for one reason: no single person could hold the whole thing in their head. The work was too deep in too many directions, so we cut it into specialties and accepted the cost. And the cost is the handoffs. Every boundary between two specialists is a place where context leaks, a ticket sails over a wall, and a day disappears while two people who each understand half the problem try to reassemble it into one. We told ourselves the handoffs were the price of expertise. They were really the price of nobody being able to cover enough ground alone. ## The team that's coming owns a workflow, not a lane Agents change the math. When a capable person has a set of agents at their disposal, the ground one person can cover gets much wider. The backend specialist still isn't a frontend expert, but the first draft, the glue code, and the tests no longer wait in someone else's queue. [Building the thing got cheap](/blog/ways-of-working/ai-made-building-easy-knowing-what-to-build); what stayed scarce is the judgment about what to build and whether the output is any good. So the squad collapses. Instead of a lineup of specialists each guarding a lane, you get three to five generalists, each owning a whole workflow end to end, with agents filling the depth wherever depth is needed. Agents are at their best on the repetitive work that used to eat a specialist's afternoon, the work I've [argued they should be taking off your team](/blog/ways-of-working/ai-isnt-coming-for-your-team) all along. > The new unit of work isn't a task assigned to a specialist. It's a workflow owned by a generalist who can steer agents through the parts they used to hand off. There's a catch that kills most attempts at this. The pod only works if the people in it actually own the workflow. Pull a few people out of their functional silos, sit them in a room together, but leave them reporting up into separate horizontals that each carry their own targets, and you have changed nothing. You have a team on the slide and a handful of people still optimizing for different bosses. Ownership that stops at the org chart isn't ownership. The pod owns the outcome and answers for it together, or it's a standing meeting with a new name. Then there's the part nobody puts on a slide. When the pod owns the workflow end to end, a whole stratum of the org loses its reason to exist. The layers whose real job was to collect status from below, repackage it into a deck, and walk it upward were never doing the work. They were summarizing it. Small, empowered pods and their agents don't need that relay. If your first reaction to all of this is to wonder who will roll it up into a steering-committee update, sit with the possibility that you are the overhead the model removes. Martin Fowler's people at ThoughtWorks have a name for whoever thrives here: the expert generalist. The traits they list aren't framework knowledge or a wall of certifications. They're curiosity, customer focus, a preference for fundamentals over tools, and comfort working one level outside their home turf. Plus the bias the piece keeps returning to: they pick the thing up and drive it themselves instead of waiting to be assigned it. Those are exactly the traits an agent multiplies. An agent makes a curious generalist far more capable. It does almost nothing for someone who knows one stack and waits to be handed a spec or a user story. Fowler's [full piece on the expert generalist](https://martinfowler.com/articles/expert-generalist.html) is worth the read. Picture one of them in the flesh. Deep, properly deep, in maybe two areas: say product and data. Then agent-extended across the engineering, security, and commercial work they used to hand to five other people. Not a master of all of it. A person who can hold the whole workflow because the depth they lack no longer means a handoff. That is more ground, more roles, more of the map than any single specialist used to carry, and it is the unit the next decade hires for. The shift is this: hire for range and judgment over the framework of the season. ![Specialist squad of seven roles tangled in handoffs, beside three generalist pods that each own a full PLAN-to-DEPLOY workflow with AI agents filling the gaps](/images/blog/next-team-squad-vs-pod.png) ## Shape is the easy part. Running it is where teams break. Drawing the smaller pod is the fun part of a reorg. The hard part comes after the pod ships, when something it built starts misbehaving at two in the morning. That's where most AI ambitions stall, and there are really only three ways to set it up. **The first is the one most companies already run, and it's the one to kill.** Engineering builds, then throws the result over a wall to a separate operations team that runs it. Two teams, two sets of objectives, a handoff in the middle. This was already creaky in the cloud era. With autonomous systems it comes apart, for a blunt reason: the operations team can't reason about what they can't see, and they were never trained to reason about a system that doesn't do the same thing twice. A runbook assumes the system is predictable. The entire point of an agent is that it isn't. You can't operate a non-deterministic system with a playbook written for a deterministic one. **The second works far better: you build it, you run it.** The same three to five senior people who built the pod also operate it. No handoff, no context gap, because the person debugging the thing at 2am is the person who wrote how it behaves in the first place. This is the [DORA logic](https://dora.dev/guides/dora-metrics/) on delivery performance: shorter feedback loops, clearer ownership, faster recovery. The pod deploys often, recovers fast, and breaks rarely. It's the cleanest model there is, right up until you have ten of these pods. Then every pod is busy reinventing its own logging, its own guardrails, its own way of watching what the agents actually do, and the inconsistency starts costing you more than the duplication ever saved. **The third model fixes that without re-centralizing control.** You keep the build-it-run-it pods, and you give them a shared platform underneath: common runtime, identity, observability, the guardrails your security people actually care about. The trap is treating that platform as a gate. It isn't a gate. It's a road. The pods still choose what to build, which models to use, how to structure their agents. The platform only means they aren't each paving their own road to get there. | Model | What it is | Where it fits | |-|-|-| | Split build/run | Builders hand off to a separate ops team | Nowhere now. It's the anti-pattern. | | Build it, run it | The pod operates what it ships | Small scale, a handful of pods | | Pods on a platform | Same pods, shared infrastructure underneath | Once you pass roughly ten pods | If you take one thing from this section: the split between who builds and who runs was already the weak joint. Autonomous systems just make it fatal. ![Three operating models: split build and run shown as the dead anti-pattern, build-it-run-it pods, and pods on a shared platform](/images/blog/next-team-operating-models.png) ## Stop managing the steps. Start managing the outcome. There's a deeper shift under all of this, and it's the hardest one for anyone who came up through traditional operations. The whole discipline grew up around one goal: tighten execution. Same input, same output, every time. Runbooks, change boards, the entire apparatus exists to remove variance. An agent is the opposite of that. You're asking it to handle the cases you didn't anticipate, to adapt instead of marching through a fixed sequence. Force it to be predictable and you've just built a slower runbook, and you already had runbooks. So the job inverts. You stop policing the steps and start measuring the outcome. Process has a dirty secret. A rigid, step-by-step workflow is a wonderful place to hide. When the work is fully prescribed, you can do exactly what the ticket says, produce nothing that matters, and stay technically blameless: the steps were followed, the ball got parked at the next desk. Judging outcomes instead of steps takes that hiding place away. That is the real reason it gets resisted, usually dressed up as a concern about rigor. > You don't tell a thermostat how often to fire the furnace. You set the temperature you want and let it work out the rest. Managing agents is the same move: define the result, hand over the means, and resist the urge to script the path. Loosen your grip on how the work gets done. Tighten it, hard, on whether the result is what you actually asked for. It's an uncomfortable trade for a certain kind of leader, because their whole career has been about controlling the how. ## What the pod can't do One honest caveat, because the pod model has a real hole in it. A team of three to five senior generalists with agents is a machine for execution, provided you actually let it run. Throttle it with access tickets, locked-down hardware, and tools that need six approvals, and you've bought the headcount without the output. But even at full speed, the pod can't do one thing: it is not a machine for growing the next generation of senior generalists. The seniors in that pod are good because somewhere they spent years doing the grunt work and learning from the wreckage. If your whole org becomes pods and nothing else, you've optimized away the exact place juniors used to learn the craft. The execution layer that agents now absorb is the layer people used to climb, and the early data already points this way: [Anthropic's research on AI and the labor market](https://www.anthropic.com/research/labor-market-impacts) finds suggestive evidence that hiring of younger workers has slowed in the most AI-exposed occupations. Cut that rung everywhere and your talent problem doesn't show up next quarter. It shows up in a decade, when you reach for seniors and find out you stopped making them. Matt Garman, who runs AWS, [called replacing juniors with AI one of the dumbest things he'd heard](https://www.theregister.com/2025/08/21/aws_ceo_entry_level_jobs_opinion/): keep hiring people out of college, or ten years from now nobody on your team will have learned anything. The pod is the right shape for the work. It's the wrong shape for an entire company. You need pods for output, and you need a deliberate place for people to come up. Both, at the same time, on purpose. ## So what do you actually do Pick one workflow. Not a company-wide AI strategy, one real workflow. Ask who'd be on the pod if you rebuilt it today, and be honest about whether you can staff it with three to five people who really own the whole thing, instead of ten who each own a slice and answer to someone else. Then ask how that pod runs what it builds. If the answer is "engineering builds it and ops runs it," you already know the work in front of you. The org chart you'd draw on instinct is the answer to a question from a different era. The companies that win the next decade won't be the ones with the best models. They'll be the ones who rebuilt the team around the models instead of bolting the models onto the team they already had.