From Two Pizza Teams to Triads?

You might want to short Dominos . . .

The past

In many companies, the core engines of software delivery are two pizza teams - groups of ~5-10 engineers - often led by a full time engineering manager, tasked with turning tickets into deployed code.

The present

But we’re starting to see that much smaller teams are a better fit for agentic software engineering. For early experiments, a team size of 1 is often perfect as it removes the human inter-communication costs, allowing you to try lots of things very quickly indeed.

Once you’re looking to scale agentic engineering across an engineering org, I’m seeing a lot of companies experimenting with teams of three.

• Solo coders are great for experimenting, but if you leave them alone for too long, alignment is a risk, and once they see what they can deliver on their own it might be hard to keep them working for your company.

• Teams of two work well, but they’re unstable. If one leaves or is out sick, you’re back down to a single person team.

• Triads are a little more interesting. Three people with a range of skills covering product, engineering and (depending on the use case) design, data and/or infrastructure can be incredibly effective, with one acting as a hands on team lead to handle 1:1’s, alignment and career/personal development for their team.

• Once your team gets much larger than that, the amount of backlog it can ship agentically just becomes very difficult to manage and reason about.

The question

If you needed to break your org down into fairly independent teams of three or four covering product, engineering and any additional skills required to ship, what would that do to your org structure? Do you thin down the ranks? Double the number of teams?

It’s time to start experimenting with some smaller agentic teams to see how they might work within your company. And it’s worth thinking through how this would impact your org if you scaled it out across your org in the future?