AI and the rise of Product Engineering pods
For years, the two-pizza team has been one of the most recognizable ideas in Software Engineering organizations: keep teams small enough to communicate effectively, while still having enough skills to build and operate a product.
It made sense in a world where specialization was expensive. A Frontend Engineer focused on frontend. A Backend Engineer focused on backend. Product Managers shaped the product direction and priorities. Designers created experiences. QA validated them. Engineers depended on SRE and Data specialists.
As organizations grew, teams needed more people to cover these capabilities. Six, eight, sometimes ten people became a reasonable Product team size.
AI is changing this equation.
AI is making it cheaper for people to cross traditional disciplinary boundaries. Frontend Engineers, for example, can increasingly work across the stack. They can generate tests, migrations, documentation, and infrastructure code. Product Managers can prototype. Designers can create functional experiences rather than static mockups.
As a result, AI will probably change the shape of organizations in the years ahead.
The image below shows one possible evolution I’ve been thinking about: moving from relatively large, functionally complete Product Engineering teams toward smaller, more autonomous, AI-augmented pods.
From teams to pods
If this evolution happens, the interesting consequence of AI may be that the minimum size of a team capable of owning a meaningful outcome gets smaller.
Imagine a product area that previously required a Product Manager, Designer, Tech Lead, Engineering Manager, several Frontend and Backend Engineers, QA, and other specialists.
Now, with AI, a small group of Engineers can increasingly work across the entire stack. A Product Manager can prototype directly with AI. A Designer can participate much closer to implementation. Quality can increasingly become part of the engineering workflow rather than a separate phase at the end.
The result could be a much smaller unit of execution: perhaps two or three Engineers working closely with Product and Design around a specific outcome.
I’m talking about Product Engineering Pods. And, in my opinion, the important part isn’t the exact number of people. It’s the unit of ownership. A pod should be small enough to move quickly and autonomous enough to own an outcome without constantly waiting for another team to complete its part. A pod is therefore more than a smaller team. It is a small unit of ownership and execution.
This model also makes clear domain boundaries increasingly important. The smaller and more autonomous the pods become, the more carefully responsibilities need to be defined. A pod should be able to make most decisions within its domain without constantly coordinating with other pods. Otherwise, coordination overhead quickly comes back through cross-pod dependencies. Autonomous pods require strong boundaries around what they own and clear contracts for how they interact.
Some capabilities — such as Marketing, CX, or Category Strategy — may still need to support multiple pods. They can increasingly be distributed across a broader organizational structure rather than duplicated inside every team.
AI needs a platform to scale
Smaller, more autonomous pods create a new challenge: each pod still needs access to a broad set of capabilities. If every pod solves the same infrastructure, tooling, data, security, or engineering-process problems independently, organizational complexity gets duplicated.
This is where Platform Engineering becomes critical. Platform Engineering can provide the common capabilities that allow Product Engineering Pods to remain small: infrastructure, tooling, processes, standards, and DevEx.
The platform should centralize complexity where centralization creates leverage. A good platform makes the right thing easy, provides reusable capabilities and establishes sensible guardrails, while giving pods enough autonomy to make decisions within their domain.
In practice, the platform should absorb complexity so that the pods can absorb AI.
Get David Sorrentino’s stories in your inbox
Join Medium for free to get updates from this writer.
This becomes particularly important as AI accelerates development. If every pod adopts its own tools, processes, and patterns, AI can amplify organizational inconsistency. The speed of generating software increases alongside the speed at which technical debt and fragmentation can spread. Platform Engineering can turn individual AI productivity into an organizational capability.
Leadership and management around the pods
A smaller execution unit also changes how leadership and management are structured.
Today, an Engineering Manager or Tech Lead is often closely associated with a single team of Engineers.
In the future, if a pod contains two or three Engineers, leadership can span several pods. A Tech Lead might provide technical direction across multiple pods. An Engineering Manager might support multiple pods, focusing on people, organizational health, and execution systems rather than day-to-day coordination inside one team.
Leadership becomes less tightly coupled to the size of the execution unit.
Large teams may still have a place
Some problems benefit from specialization and scale. Infrastructure, security, tools, processes, standards, DevEx, and other areas can require deep expertise and substantial teams. Platform Engineering itself will probably remain a significant organization.
The future may therefore be asymmetric. Small where autonomy creates leverage. Specialized where expertise creates leverage. Shared where capabilities are scarce or expensive to duplicate. AI-assisted broadly.
The interesting question becomes where each organizational shape creates the most leverage.
The two-pizza team remains a useful model. Product Engineering Pods offer another organizational shape for areas where AI enables greater autonomy.
The questions I haven’t answered yet
This model creates some uncomfortable questions.
Take code review.
If a pod has two engineers and one is the primary expert in a particular area, who reviews the other person’s code? Another pod? A Staff Engineer? An AI reviewer? And if AI generates a significant portion of the implementation, is line-by-line human review still the right abstraction for quality?
Then there are shared functions such as QA and Design. Can they effectively contribute to multiple pods without becoming a bottleneck? Splitting their time across several pods can also create a different set of problems: losing focus on a specific product area, weakening the sense of belonging to a team, and having to participate in multiple rituals such as syncs, planning sessions, and retrospectives. The coordination cost can quickly show up in their calendars. How do we preserve the benefits of shared expertise without turning these roles into floating resources spread across multiple teams?
There is also a less obvious problem: resilience.
A two-person pod is wonderfully efficient until one person leaves. The smaller the pod, the cheaper it is to coordinate and potentially the more expensive it is to lose a person. That raises questions about knowledge sharing, documentation, redundancy, and technical leadership.
If organizational redundancy decreases, resilience needs to come from deliberate knowledge-sharing practices, strong documentation, platform capabilities, and broader technical communities.
The platform itself presents another challenge.
A platform can enable autonomy while also becoming a bottleneck. If every pod needs platform approval before adopting a technology, changing an architecture, or deploying something, the dependency has simply moved elsewhere. The platform should make the paved road easier to use and give teams the tools to make informed decisions beyond it.
And there is one more fundamental question: how do people grow in an organization built around very small pods?
Traditional teams create natural opportunities for apprenticeship. Junior engineers learn from seniors sitting next to them. People develop through collaboration with colleagues who have different levels of experience.
Smaller pods and AI change that learning environment.
Organizations will need new ways to create mentorship, technical communities, and opportunities for people to develop beyond the boundaries of their individual pod.
What happens next?
AI’s most interesting impact on Engineering organizations may be that the organizational unit itself becomes smaller. The Product Engineering Pod is one possible answer: a small, cross-functional unit that owns an outcome and uses AI to cross traditional boundaries.
Ultimately, this is about reducing the amount of organizational structure required to turn an idea into software. Perhaps that will be one of AI’s biggest effects on Engineering: changing how we organize the people who build it.
