Designing teams for an agentic world

Subscribe<br>Sign in

Anup Jadhav

For thirty years, software organisations were built around the same logic: hire specialists, group them into functions, put managers above them, and build a pyramid on a wide junior base. That made sense when the ability to build software was scarce. Coding agents are changing what’s scarce, so the way we’ve built things around that scarcity no longer makes sense.<br>What stands out to me is that most leaders are not moving slowly on AI. They are quick to adopt the tools, but much slower to change how the organisation itself works. Bolting an engine onto a horse-drawn carriage does not make it a car. After spending the past two years working through this shift, I have come to frame it through four connected questions.<br>Economics: buy before you build<br>The first question I would ask is: what is genuinely worth building yourself? The seductive story is that you train a model, or fine-tune someone else’s, on your own data and create a moat nobody else can cross. I understand the instinct because I held a version of it myself. But the economics keep pushing the other way.<br>Training a frontier model gets more expensive with each step up in capability. Each step demands more compute, more data, and more capital. The bill now runs into billions, beyond what all but a handful of firms can approve.<br>At the same time, running inference on an existing model keeps getting cheaper as providers compete and hardware becomes more efficient.<br>So you end up pouring capital into the option that keeps getting more expensive while the cheaper alternative keeps improving. By the time your bespoke model ships, the frontier may already have moved on.<br>So the question is not whether you can build your own model. It is where owning one creates enough advantage to justify the cost.<br>That leads to a practical rule of thumb:<br>Commodity capability → buy or consume. Building your own is an expensive way to recreate what you could rent.<br>Differentiating and high-volume capability → consider building. But only once you understand the workflow well enough to know what you are actually building.<br>This decides the team directly: a consuming team needs orchestration and integration, whereas a building team needs research and infrastructure.<br>Talent: generalists with agents<br>I think the most valuable engineer over the next five years will not be the one who writes code fastest, but the one who orchestrates most effectively : someone who can point an agent at a problem, judge what comes back, steer the next attempt, and know when to stop and do the work by hand. Few senior engineers have been trained to work this way, so organisations need to hire for it and develop it deliberately.<br>That changes the shape of the specialist team:<br>The old default: eight people, each owning a narrow lane, with a handoff at every boundary.<br>The emerging shape: a small group of expert generalists, each working with a fleet of agents.<br>A generalist owns an end-to-end workflow rather than a narrow lane. Agents provide much of the specialist depth, while reducing the handoffs and coordination that consume so much of the week.<br>This does not mean every team of eight should disband next quarter. But if every new initiative still resolves into last year’s org chart, you are quietly rebuilding last year’s company.<br>Structure: four forces, three shapes<br>Of the four, structure is the hardest in my experience, because the forces pull in different directions and no design satisfies all of them at once:<br>Expert multiplier: A small senior team working with agents can now produce far more, which argues for keeping teams small and senior.<br>Junior squeeze: Agents absorb much of the execution work through which juniors used to learn, which tempts organisations to stop hiring them.<br>Manager creep: As AI use grows, organisations feel a steady pull to add middle managers to oversee it.<br>Expertise pipeline: At the same time, you still need a path through which the next generation of experts can learn.<br>When I hold those forces together, I see three shapes:<br>The diamond, which is the trap: thin at the top and bottom, swollen with managers in the middle. It looks efficient on a spreadsheet but starves the future.<br>The pod: three to five senior engineers working with agents. It is excellent at shipping, but offers no path up.<br>The hourglass: strong senior and junior cohorts, with a lean middle.<br>It took me a while to see that these shapes operate at different levels . The pod is the right shape for a delivery team; the hourglass is the right shape for the organisation that contains the pods. Left alone, most companies drift towards the diamond. Short-term incentives reward cutting the base and padding the middle; the cost arrives later.<br>Agents can take on much of the execution, but judgement is what remains. That judgement exists because someone spent years doing the work by hand and learning from what went wrong. If you stop training juniors, you...