What If a Two-Pizza Team Supported Several Domains?

 The two-pizza team is a useful unit of ownership, bold statement, I don't think this changes with agents, HOWEVER!, with a small group you can make decisions, ship, and respond when something breaks, and you don't step on each others toes, especially since each engineer had 3-5 agents running in parallel. The familiar version of that model often binds one team to one product or project, and that is the change I see emerging. As organizations take on more work at once with our AI agents, that can leave every new project rebuilding the same operational muscle: deployment paths, alerts, incident response, and the knowledge needed to keep a service healthy. I think a two-pizza team to help support a broader scope is inevitable and should be encouraged.

This means there is another way to organize some of that work. A two pizza team (8-10) could support several projects in parallel by owning the shared operating system around them. Its output would be reliable paths to production and faster recovery, rather than a feature backlog for any one project.

That is a different kind of two-pizza team. Its capacity is measured in how many teams it can enable without becoming their bottleneck. Where I see similarities is deployment model.

A team with a clear support boundary
The support role for a team needs an explicit contract. It can own common deployment tooling, observability, incident coordination, and the first response to alerts across a portfolio. This is the main reason why you still need a bigger team. Each project team still owns its product decisions, application code, and fixes that require product context allowing them to move fast, but when an incident points to a project-specific defect, the support team helps diagnose and routes the fix to the people who can make it. The key here is that everyone needs at least enough knowledge to stop the bleeding across the whole broader pizza team.

That boundary matters because “support many projects” can quickly turn into “absorb every unfinished task, sorry about your goals.” A shared on-call rotation only works if alerts are actionable, escalation paths are current, and project teams remain available for the problems only they can solve. Otherwise, the new team becomes a queue with a pager.

Teams should set up weekly education/learning sessions to share changes, support plans, and things coming up that will hit production, among other things. Here are my suggestions I've seen work:
Build the model around five practices
Cover on-call deliberately. Start with a documented service inventory: who owns each service, which alerts page, who is first responder, and when to escalate. Use Grafana Service to do this the best. Give the team authority to silence noisy alerts, improve dashboards, and change operational tooling. Review pages and interruptions as capacity costs, not as invisible background work. Even better, have an agent monitor effective alerts, provide a report, iterate and have an agent loop provide suggestions via PRs to your alert rules as code.

Hold a weekly enablement session. A recurring session gives project teams a place to bring deployment problems, production questions, and upcoming changes. The support team can teach a new practice once instead of solving the same problem in several private chats. Record the questions and turn recurring ones into documentation or tooling. Have your agent digest this, provide insights and recommended runbooks. Also, this is the time to celebrate as humans all the cool shit we are building, celebrate!

Automate runbooks: A runbook should be more than a page of prose that someone must interpret at 2 a.m. For common, well-understood incidents, encode safe diagnostic steps and routine recovery actions in versioned scripts or workflows. Keep the preconditions, owner, rollback path, and escalation point visible. Automate the repeatable parts first; retain human judgment where the blast radius is unclear. Use your agent looping system to do some monitoring, this is the future.

Use LLM-supported DevOps with guardrails. An LLM can help summarize an incident timeline, find a relevant runbook, explain a deployment failure, or draft a query for an engineer to check. It should cite the logs or documents behind its answer, respect access controls, and make uncertainty obvious. Production changes still need a human to verify the evidence and approve the action. The goal is less time spent searching and reconstructing context, not an unsupervised operator. I personally recommend Grafana Assistant for this (shameless plug, I work there, but it really has cut down a lot of our Ops overhead).

Be honest about investments. When you decide to take on a new project, put a clear goal on the hypothesis. This should include clear outcomes that you're expecting with the changes that you wanna make or the project that you're willing to build, and the end state expected. At the end of the period, we should have a review to see how it went. If the project was successful, then it goes into the maintenance mode while we gather feedback from our customers, which would then feed into the hopper of things. When we're looking at investing time in allocating people towards that time, then we should look at what is burning, do we need to invest in are things we already built or do we need to build new things.

These practices reinforce one another. On-call exposes the painful gaps. The weekly session reveals which gaps affect several teams. Runbooks make a solution repeatable. LLM assistance makes the knowledge easier to find when pressure is high.

Protect the team’s capacity
A two-pizza team cannot support an unlimited number of projects just because the tooling is shared. Set an intake bar before adding a project: basic observability, a named application owner, an escalation contact, a tested deployment path, and a runbook for likely failures. Reserve time for improving the system, or the on-call queue will consume every week.

Track a few signals: pages per engineer, pages per project, repeat incidents, time spent waiting for the right owner, adoption of automated runbooks, and whether project teams can deploy and recover without direct support. If those measures worsen as the portfolio grows, narrow the support scope or add capacity. Do not hide the load behind a successful ticket count. Problematic projects that are too painful should either be reinvested or removed.

The point is not to replace product ownership with a central operations team. It is to give multiple projects a strong shared foundation while keeping responsibility for each product close to the people building it. Done well, one small team can help many teams move at once and still have enough breathing room to make the next incident easier than the last.