The Product Development Team Is No Longer the Smallest Unit of Delivery

Team Topologies put the stable team at the heart of software delivery. AI is challenging whether the team must remain the smallest unit carrying every outcome.

In the previous article, I described one engineer and one designer rebuilding an application end to end, work I would once have expected to require two teams or remain undone. That article asked what this implied for management span. This one asks what it implies for the product development team.

The product bet is shared; one engineer is carrying the bounded engineering outcome. A senior product leader set the direction and constraints but left the solution open. Product and Design shaped the intervention and challenged it as it developed. The implementation crosses architecture, web, native, shared code, build, release, testing and operations.

At the time of writing, the application is moving towards production. This is not a toy, a weekend experiment or a narrow feature. It is consequential work crossing enough boundaries that the organisation might previously have staffed a team around it, or declined to begin.

AI supplied reach, not architecture. The engineer defined the invariants, tested the designs and documented the failures. What matters here is how far that judgement travelled.

He could probably have done this before AI. It might have taken so long that the organisation would never have chosen to begin. AI changed the work from theoretically possible to economically credible. It allowed his judgement to operate across a much larger surface: investigating native APIs, understanding unfamiliar build systems, constructing tests, diagnosing failures and crossing parts of the stack that would recently have required another person or another week.

Together has not disappeared. It has moved from permanent staffing to selective, proportionate collaboration. Reviewers, platform teams, security specialists and engineers with collective ownership will help take the application into production and operate it. Product, Design and Engineering must still learn whether the bet improved customer behaviour or commercial results. Construction alone proves neither delivery nor value.

Not every engineer could carry an outcome of this breadth. It is distinguished-engineer-scale work. A less experienced engineer should carry a smaller outcome, with closer challenge and more opportunities to pair and observe. Seniority changes the scope and support, not necessarily the size of the delivery unit.

Nor is this a model built on heroes. Heroics depend on exceptional effort, private knowledge and somebody refusing to sleep. Individual delivery should depend on understandable architecture, self-service platforms, fast tests, visible decisions and accessible help. The engineer's judgement determines the scope; the system determines whether carrying it alone is responsible.

This argument concerns product development, not every kind of engineering. Platforms, infrastructure, site reliability and complicated subsystems requiring scarce specialist knowledge involve continuous operational responsibility, parallel work and incident response. Stable teams remain sensible there. One unfinished example does not establish an operating model anywhere. It does expose a possibility worth taking seriously: a team may no longer be the smallest unit capable of carrying a bounded engineering outcome.

The Best Available Baseline

Team Topologies solved an important problem: how to arrange teams so that software could flow without drowning in handovers, dependencies and cognitive load. Matthew Skelton and Manuel Pais made a stable, autonomous team the fundamental means of delivery, aligned it to a stream of value and supported it with platforms, enabling teams and complicated-subsystem teams.

This was a considerable advance on arranging engineers by discipline and passing work between them like luggage through an unreliable airport. Fast flow remains the objective, cognitive load remains a design constraint and Conway's Law has not been repealed by a chatbot.

Nor has the model ignored AI. The second edition, published in 2025, treats Team Topologies as evolutionary and addresses humans working with AI agents. In a conversation with Thoughtworks, Skelton and Pais consider teams covering larger domains or becoming somewhat smaller as AI reduces cognitive load. They conclude that the principles remain sound and the team remains the unit.

They may be right about nearly all of it. Team Topologies is the best available baseline from which to ask the next question: must the team that owns a continuing stream of value also carry every bounded outcome within it?

The word *delivery* is doing considerable work here. If it means durable stewardship of a product, including discovery, operation and continued evolution, the team remains a persuasive unit. If it means carrying a bounded engineering outcome from intent into working software, the unit can already be one person. Team Topologies usually joins those responsibilities inside one end-to-end team. AI gives us a reason to examine them separately.

What Happens When the Pass Is No Longer Compulsory?

Conventional product organisations built squads like football teams. Product, Design, frontend, backend, testing and infrastructure occupied positions, and work moved among them like a ball. Security was too often left in goal, expected to save whatever the formation let through. No player could carry the ball through every part of the pitch, so success depended on passing cleanly and keeping the side together.

AI does not abolish the team. It turns some bounded engineering work from football into golf. One engineer can cross technical boundaries without passing the work at each one. Caddies, coaches, groundskeepers and officials still make play possible, but they do not take every shot. Execution becomes individual; product discovery, review, operation and value remain collective.

An engineer can acquire temporary fluency in an unfamiliar system, interrogate code and documentation, trace behaviour, create tests and discard a bad approach before the old process has located the appropriate specialist. Expertise still matters. What changes is the number of people who must travel through the entire delivery process together.

There is evidence for the mechanism, although not yet for the organisational conclusion. A Google study of 32 developers found that an in-editor language model helped people complete code-understanding tasks more effectively than web search. Three field experiments involving 4,867 developers found 26 per cent more completed tasks among developers given an AI coding assistant.

The effects are not universal. A 2025 randomised trial found that experienced open-source maintainers took 19 per cent longer using early-2025 AI tools in repositories they knew well. No study proves that the product team should disappear. This is a prediction grounded in an observation: an individual can now carry work further before another human must become involved.

AI does not abolish cognitive load. The product's purpose, dangerous assumptions and consequences of failure must remain durable knowledge. Context needed only to cross a boundary, such as what a build file does or why a test is failing, can increasingly be acquired at the moment of need. The constraint becomes how reliably an engineer can acquire, verify and apply that context before collaboration would be cheaper or safer.

Team Topologies anticipated part of this answer. Its interaction modes allow teams to collaborate temporarily, facilitate learning and provide capabilities as a service rather than permanently combining every specialist. Those patterns help one person carry more of an outcome. The question is whether their success should merely enlarge the stream-aligned team's reach or change the unit carrying each outcome.

The Pod Is the Squad on a Modest Diet

Most product organisations still allocate work to a squad. Six or eight people share a backlog, attend the same planning rituals and have their delivery represented as a group. Individuals may carry separate pieces of work, but the squad remains the unit to which outcomes, capacity and progress are assigned. It appears on the org chart, in Jira and in the management hierarchy, which gives it the satisfying appearance of something discovered in nature.

This machinery is not prescribed by Team Topologies. It is a familiar corporate operating model, with Scrum, line management and portfolio reporting contributing their own furniture. The distinction matters. Team Topologies offers a durable team boundary; organisations decide how much ceremony and hierarchy to build around it.

AI is already making some squads look overstaffed for the outcomes assigned to them. Some organisations are slimming squads into pods. This is a sensible improvement. It is also the old topology in a smaller box.

The pod acknowledges that AI changes how many people an outcome requires but stops short of asking whether stream alignment still requires a team. It contains fewer people while preserving the assumption that a permanent collection of humans must travel through delivery together.

The pod is not harmless. Once delivery is reported only as the work of a group, it becomes harder to see where judgement, dependency and support sit. One person may make the difficult decisions while the group reports the result. The problem is not the group but collective reporting without explicit decision ownership. Shared accountability can produce collective ownership; it can also diffuse responsibility until an important outcome has no clear owner.

This is not an argument for counting commits, tickets or lines of code. Knowledge work becomes absurd when reduced to individual output statistics. It is an argument for visible ownership. When one person explicitly carries an outcome and the work is public, everybody can see where judgement sits, where support is needed and whether the scope is appropriate. Responsibility has somewhere to land without turning contribution into a league table.

The pod also preserves machinery invented to coordinate a group: backlog refinement, planning, sprints, stand-ups, demos and status reports.

Fifteen Engineers Without a Shared Sprint

Now imagine fifteen product engineers, each capable of carrying a distinct outcome. Some work closely with Product and Design, some pair with another engineer and some briefly draw on security, data or architecture. They review one another's work, share product context and retain collective responsibility for the systems they change. They do not share a sprint merely because they share a manager.

Fifteen is an illustration, not a recommended ratio or a demand for fifteen simultaneous bets. Product leadership must still choose where to invest, limit work in progress, sequence outcomes and preserve a coherent customer experience. The model depends on capable engineers, comprehensible systems, strong platforms and outcomes small enough to receive fast feedback. Where those conditions do not exist, a renamed org chart will not create them.

Product and Design do not become visiting services. They retain customer knowledge and remain accountable with Engineering for whether a bet works. Product managers may define an outcome, engineers may identify one and often they will shape it together. Uncertain problems may require a sustained partnership; clearer interventions may leave one engineer considerable freedom. The configuration should follow the uncertainty, not a permanent pod. Public work lets Product redirect a weak bet earlier, but does not decide which problems deserve attention or which attractive changes should never begin.

This is also where delivery topology meets management structure. A manager supporting fifteen engineers who are jointly delivering one thing faces a formidable coordination problem. A manager supporting fifteen engineers, each carrying a bounded outcome inside a strong product system, has a different job. They attend to judgement, development, performance, fairness and exceptions rather than routing daily work among fifteen people.

This is the delivery model underneath the wider-span argument. A wider span is not achieved by giving an Engineering Manager three squads and asking them to attend every ceremony. It becomes possible when the squad ceases to be the route through which ordinary delivery must pass.

Individual Delivery Must Be Public Delivery

Several outcomes will occasionally collide. The answer is not to assemble every engineer each morning in case today is the day. Use rough product and code boundaries, expose intended outcomes, record consequential decisions and make work in progress easy to find. Product leaders should know which bets are moving; engineers should know who is changing adjacent systems. When outcomes meet, the people involved can coordinate directly. Technical leaders can challenge a direction while it is cheap to change without approving every step before it begins.

AI compresses many changes into hours or days, which makes little-and-often delivery more important. When a decision is reversible, take it, observe the result and reverse it if necessary. The cost of occasionally undoing a small mistake may be lower than the cost of preventing every mistake in advance.

Code review remains mandatory, but its purpose shifts upwards. Syntax, formatting and routine conventions should be enforced by tooling and automated checks. Human reviewers still require evidence of correctness and security, particularly when AI has helped an engineer cross unfamiliar territory. Their scarce attention should concentrate on architectural sanity, dangerous assumptions, operability and whether the change belongs in the system at all. That shift in expert attention is the subject of The Code Is No Longer the Scarce Part.

Routine, reversible changes can proceed with informed peer review. Cross-cutting architectural decisions should draw in a Principal. Changes affecting safety, security, regulation, customer funds or hard-to-recover data require deliberate design and independent specialist approval. Public work makes the risk visible; it does not waive the control.

I currently follow every merge request in our monorepo. This is not a sustainable executive hobby and it does not make me reliably correct, but it is remarkably effective. I see what people are changing, notice patterns and occasionally connect engineers solving adjacent problems. The purpose is to understand the system, not score individuals. Following is not approving: work does not wait for me and intervention remains occasional.

Keep the Community. Change the Delivery Unit.

The stable product team has usually answered four questions:

1. Who discovers and chooses the product bet?
2. Who carries the engineering change?
3. Who challenges and reviews it?
4. Who owns the product and system afterwards?

Putting all four inside one durable container was sensible when delivery required a standing collection of skills. It becomes less necessary when one person can carry more of the work.

After a bounded outcome ships, there is no handoff to strangers. The engineer remains part of a durable product, design and code community with named product and operational responsibility. Code ownership, review history and operational participation should reflect demonstrated knowledge without reducing ownership to commit count or allowing it to remain private in one person's head.

The work is not delivered merely because the code has merged. It must operate safely, produce evidence against the intended outcome and be changeable by another qualified engineer. Otherwise individual delivery has produced individual dependency.

Engineers can remain co-located and belong to a product area, code community, management group and professional discipline without pretending they share one piece of delivery.

In practice, the same organisation can be understood in four useful ways without creating four new departments:

• Outcome delivery: one engineer, or a small temporary pairing, carrying a bounded engineering outcome into production.
• Product and code ownership: durable communities responsible for customer context, product coherence and the systems beneath them.
• Management and disciplines: line-management groups, Centres of Excellence and professional communities providing coaching, standards and career development.
• Shared expertise: Principals, security specialists and other experts challenging and reviewing work wherever their judgement is needed.

Shared experts cannot become a hidden queue. Routine judgement must be encoded in platforms, standards and automated checks, leaving people to handle the decisions that genuinely require them. Otherwise fifteen individual outcomes will merely wait for the same exhausted Principal.

Platforms make the model possible by making delivery, observability, infrastructure and routine security self-service. Public work keeps individual outcomes connected. Independent review supplies challenge. Collective ownership prevents the result becoming a single point of failure with a laptop.

The topology becomes fluid at the point of delivery and stable at the point of accountability.

Team Topologies still gives us a strong model for stewardship, platforms and specialist interaction. What must change is the assumption that the team owning the stream must carry every outcome within it. People will still collaborate, pair, review and teach. The squad or pod may not remain the smallest box through which every change must pass.

Keep the team for work that needs a team. Stop requiring one for everything else.