The “Tiny Teams” Shift: Restructuring Engineering Orgs Around Agents

By 2029, 60 percent of organizations will adopt smaller software engineering teams at scale, up from just 15 percent in 2026, according to Gartner. That’s a fourfold jump in three years, and Gartner’s own framing of what’s driving it cuts directly against the assumption most leadership teams start with. “Tiny teams are not a cost optimization tactic,” said Gartner Principal Analyst Aliyah Camacho. “This is a restructuring of teams to best take advantage of both human and AI capabilities and strengths.”

That framing lands closer to what McKinsey’s separate research on the agentic organization describes: teams of two to five people already supervising an “agent factory” of 50 to 100 specialized agents running an entire end-to-end process. Two analyst firms, working independently, are converging on a similar-shaped conclusion. The interesting part isn’t the headline number. It’s what actually has to be true inside an organization for a team that small to work, and the specific mistake Gartner warns will undermine it.

Gartner’s research describes today’s tiny teams as typically running four to five members, with some organizations already operating with as few as two to three, a size Camacho expects to become more common as both employee skills and AI capabilities mature. The composition isn’t arbitrary: a product manager, a user experience or “agent experience” (AX) designer, and at least one AI-native software engineer. The AX designer role is new and worth naming specifically, since it isn’t UX with a different label. It’s the discipline of designing the environments and interfaces AI agents navigate, not just the ones humans see.

Inside a tiny team, the traditional boundaries between roles collapse. Each member ends up managing a wider mix of responsibilities than a comparable role would carry on a traditional team, from understanding business goals to product design to overseeing AI agents directly, closer to the M-shaped and T-shaped profiles McKinsey’s broader research on the agentic organization describes emerging across knowledge work generally.

Gartner is specific about the sizing principle, and it isn’t “as small as possible.” Teams should be small enough to stay nimble and effective, and big enough to preserve a genuine diversity of ideas and alternate viewpoints. A tiny team that’s actually just one person and a set of subscriptions isn’t the model being described here.

The distinction Gartner draws matters more than it might first appear. “AI is reshaping software engineering,” Camacho said. “It is redefining roles, reinventing teams, and fueling the demand for more software engineers, not fewer. The resources required to meet the growing demand for software and complex AI-enabled applications will outpace the efficiency gains from AI.” That’s a direct rebuttal to the version of this story leadership teams are often tempted to tell themselves, that smaller teams mean the organization needs less engineering talent overall. Gartner’s prediction says the opposite: demand for software keeps growing faster than AI’s efficiency gains can offset, which is why smaller teams shipping more, not a net reduction in engineering headcount, is the actual shape of the shift.

That nuance matters against McKinsey’s separate finding, referenced earlier in this series, that the business case for hiring large numbers of junior developers is weakening as agentic AI absorbs routine execution work. Those two findings aren’t in conflict, but the gap between them is exactly where organizations get this wrong. Fewer junior hires per team is consistent with both. Zero junior hires is not, and it’s the specific failure mode Gartner’s research calls out directly.

A tiny team doesn’t function on talent alone. Gartner’s research is explicit that tiny teams are supported by robust platform engineering functions providing standardized, automated workflows and self-service AI tools and capabilities, which is what lets a four-person team focus on high-value work instead of rebuilding infrastructure and tooling from scratch for every feature. This is the same reuse economics that shows up everywhere else in this series: once a governed platform layer exists, the marginal cost of the next team’s output drops. A tiny team without that foundation isn’t a leaner version of a normal team. It’s a normal-sized workload compressed onto too few people.

Gartner’s research doesn’t stop at describing the model. It issues a specific warning: organizations that rely on AI to cut junior roles will, by 2028, hollow out their own software engineering talent pipeline. The mechanism is concrete. Slowing junior-level hiring inhibits knowledge transfer from senior engineers, restricts the internal pipeline an organization needs to grow its own senior talent over time, and eventually limits recruitment to a smaller, more expensive, more competitive pool of senior hires, since there’s no longer an internal bench maturing into those roles.

This connects directly to the investment-ratio point raised earlier in this series: McKinsey’s research on the agentic organization points to a rule of thumb where roughly five dollars gets spent on people for every dollar spent on the technology itself. Cutting junior hiring to hit a tiny-team headcount number is the same mistake in a different shape, treating people investment as the cost to minimize rather than the investment that makes the smaller structure sustainable past the first year or two.

A few conclusions follow directly from where Gartner’s and McKinsey’s research point. Don’t treat “tiny team” as a headcount target to hit by a deadline. It’s the outcome of platform maturity and role redesign done well, not a mandate to shrink the team first and figure out the supporting platform later. Keep hiring and developing junior talent deliberately, sized down from historical volumes but never eliminated, with an explicit path for junior hires to grow into the T-shaped and M-shaped roles a tiny team actually needs. Invest in the platform engineering layer before or alongside any team-size restructuring, since a tiny team without standardized, self-service workflows just becomes an overloaded team with a smaller org chart. Define the AX function explicitly rather than assuming an existing UX designer will absorb it as a side responsibility. And size teams against the “nimble but diverse enough” principle rather than a single uniform number applied across the organization, since Gartner’s own research notes the right size varies by product and feature set.