Why software teams are shrinking to three people

This isn’t a new idea. In Beyond Agile by Andrew Walker, the three-person team was described as the ‘fundamental delivery unit’ – a wrangler and two developers. What’s changed is that this structure, which struggled to gain traction inside organisations built around larger squads, now has a forcing function. Agents make the three-person team not just viable but, in many circumstances, more optimal.

Why three?

This number has history. The Beyond Agile model paired a wrangler – acting as a pseudo product owner, tester, unblocker and designer – with a senior developer and a junior developer. That combination was deliberate. Three gives you enough cognitive diversity to challenge assumptions, while staying small enough that everyone knows what everyone else is doing at all times.

The senior-junior pairing maintains a development pathway: juniors grow into seniors, seniors grow into wranglers and so the cycle continues. It also means no single departure destroys the team’s capability. If someone wins the lotto, the team is temporarily damaged but not decimated.

What held this model back was the volume and complexity of work, as well as the technical debt in many organisations’ heritage systems. A three-person team without agents still needed to write all the code, scaffold all the tests and maintain the infrastructure, making it impractical in many organisations.

Agents change that equation. They support code generation, test scaffolding, data pipeline assembly and routine infrastructure work. Three humans can now cover territory that previously demanded a larger cross-functional team (or team of teams) – not by working harder, but by orchestrating agents across to assist in activities from ideation to release and measurement.

The agents don’t replace the humans. They replace the scaling mechanism that humans previously provided. Instead of adding another backend developer when work exceeds capacity, you add another agent stream and have a human supervise it or provide a deterministic check to ensure completion. A new supervisory feedback loop is forming between the developer’s inner coding loop and the outer delivery loop. The practitioners excelling at this work think in terms of delegation and orchestration rather than direct implementation. They assess output quality rapidly without reading every line. These are the skills that define the humans on a three-person team.

Provided you have solid foundational patterns in place to build on, AI agents can handle code generation, test scaffolding, data pipeline feedback and routine infrastructure work. Three humans can cover the territory that used to demand a cross-functional squad. The agents don’t replace the humans. They replace the ‘scaling mechanism’ that humans previously provided. Instead of adding another backend developer when the work exceeds capacity, you add another agent stream to focus on that task and a human supervises it or provides a deterministic check to assure completion.

From E-shaped engineer to E-shaped supervisor

For two decades, the industry optimised for generalising specialists – T-shaped people or the even rarer E-shaped person. Individuals who went deep in one area but could contribute across many. The logic was sound when every capability required a human to execute it. If your team only has five people and you need frontend, backend, infrastructure and data work done, those five people had better overlap.

Agents collapse this requirement. Agents can bring consistent expertise to every team simultaneously without the eventual bottleneck of a single human specialist. One handles APIs, another handles HTML and CSS, another writes migration scripts, another checks the architectural patterns have been adhered to. The breadth that humans had to cultivate across technical domains is now covered by agents that are functionally, infinitely duplicable.

This frees humans to go deep on what agents cannot do – understanding the problem space with the customer, specifying what needs to exist and validating that what was built actually solves the problem with high quality and without incurring technical debt. The human skill profile shifts from technical breadth to judgment depth.

Forward-deployed by default

The ‘Forward Deployed Engineer model’, now spreading across the industry, is a clear signal of where three-person teams are heading. An FDE embeds directly with the target customer to understand their environment, their problems and what’s actually required to deliver outcomes. This is not a sales role but a product creation role that happens to require proximity to the people with the problem.

Marty Cagan has argued that the FDE concept applies far more broadly than just for new product development. The core of the model is sending empowered engineers directly to spend intense time with customers, learning the problem and solution space so they can discover solutions that achieve the best outcomes.

We are even seeing our clients now iterating on the design of interfaces in HTML/CSS with agents leading to designs that we can directly apply. This approach leads to greater engagement and often superior outcomes. When you combine this with AI agents helping to handle the implementation, you get a team structure where more of the human energy goes into discovery and validation rather than construction.

On a three-person team, this looks like one person embedded with customers defining the problem and specifying what the solution must do. One person orchestrating agents to build and test that solution. One person validating outcomes against real-world constraints and feeding findings back into the next cycle. These roles blur and rotate – three people is small enough for that – but the emphasis is fundamentally different from a traditional development team where 70% of the effort went into writing and reviewing code.

From writing code to specifying and validating it

Specification by Example, Acceptance Test Driven Development and Behaviour Driven Development have been around for many years, all techniques we have used with great success.

But now these forms of test-driven development are producing dramatically better results from AI coding agents because it prevents agents from writing tests that verify broken behaviour. When the tests exist before the code, agents find it harder to cheat. When the tests operate at different layers (micro, integration, component, system), then they support new features and safeguard breaking changes when refactoring existing functionality. TDD becomes a form of prompt engineering. The tests are deterministic validation for non-deterministic generation.

This is the template for what humans do on agent-augmented teams. They specify what correct looks like before agents build anything, then they verify the output against those specifications. Moving review efforts entirely to the test suite and treating generated code as expendable is an emerging pattern. This raises interesting questions – if the tests are correct and the code passes, is the code acceptable regardless of its aesthetics? In reality, this will be a movement along a continuum for most organisations – as we continue to improve deterministic specification and verification, the aesthetics of code become less important to humans and more optimised for agents.

The specification itself is becoming more rigorous out of necessity. Traditional user stories are too vague for agents. Teams are experimenting with more structured approaches including state machines and decision tables – not because these are new, but because they give agents enough precision to produce correct implementations. Bad specs produce bad code. The specification is now a high-leverage artifact. Yay!

The separation of specifications from constraints matters here too. Specifications describe what should change. Constraints define what must not be touched. These constraints limit blast radius and let agents work safely across domain boundaries. Humans set both. Agents operate within them.

Everyone is an engineer

Let’s talk database management. In the 1970s and early 1980s, developers wrote custom file I/O routines – manually managing disk blocks, indexing structures and data retrieval logic in C or assembly. Then relational databases and SQL absorbed that work and the job shifted to schema design, query optimisation and data modelling.

By the 2010s, ORMs and managed cloud databases (DynamoDB, Firebase, Aurora Serverless) pushed the abstraction up again. The job became choosing the right data paradigm, defining access patterns and designing event-driven architectures. The developer who said “I was hired to write B-tree implementations” was obsolete by 1990. The one who said “I was hired to write SQL” is under pressure now as natural-language-to-query tools and auto-scaling managed services erode that layer.

At each step, the people who survived were those who moved with the rising abstraction – from disk blocks to relational logic to system-level data architecture. The ones who anchored identity to a specific layer of manual work lost relevance.

When the level of abstraction rises, the skills change. In this case, more powerful tools allow a broader base of humans to become ‘engineers’. For example, someone without any programming experience but with a good aesthetic eye can create HTML-based UI designs or a product manager/owner may prototype a user experience.

This shift is already visible. Large technology companies are actively researching whether roles need to be renamed and training product managers to work in Markdown inside developer tools.

If developers are now thinking more about ‘what’ to build and ‘why’, they are doing work that used to belong to product managers. If product managers are working in technical environments to specify agent behaviour, they are doing work that used to belong to developers. The resulting role – whatever it ends up being called – is the human on a three-person team.

Organisational readiness

The three-person, stream-aligned team doesn’t have ‘software engineers’ in the traditional sense. It has product engineers who understand the customer problem deeply enough to specify solutions and validate outcomes. They own the full delivery loop – problem discovery, solution specification, agent-directed construction and result verification – through to release and measurement.

But three-person teams don’t materialise by simply shrinking existing squads. Certain conditions need to be in place.

Leaders and practitioners need to stop equating productivity with hands-on-keyboard coding and start valuing specification, orchestration and validation as primary engineering activities. Without this shift, organisations will staff three-person teams and then measure them by the old metrics which guarantees failure.

Three-person teams need working practices designed for their structure – lean and agile practices designed for a different era need to be adapted, although the underlying principles still apply such as small batch size and quality. Small teams need autonomy, short feedback cycles and embedded customer (internal or external) collaboration.

Don’t go all in without training. Supervising agents, writing rigorous specifications, validating generated output, orchestrating multiple agent streams – these are new skills even for experienced engineers. Organisations that redraw the org chart without investing in capability building will struggle.

Stream-aligned teams are not the only team type. They need to be supported in a team of teams to maintain coherence and to help scale. Alongside them sits platform teams whose job is to make three-person teams viable. The platform team designs and maintains the agent infrastructure – the toolchains, constraints, guardrails, feedback loop mechanisms and deployment pipeline templates that allow stream-aligned teams to reliably construct software through AI agents.

They reduce cognitive load of managing more complex infrastructure, networking, evaluation harnesses, pipelines and libraries, helping abstract away operational complexity. The interaction mode is pure self-service.

The stream-aligned team consumes the platform’s capabilities without filing tickets or waiting on enablement. If the platform is doing its job, the three-person team does not need to think about all the underlying agent mechanics – the same way a modern web team never thinks about TCP packet assembly. Platform teams in larger organisations must be federated – distributed enough that different domains can extend and adapt it to their context rather than waiting on a central team to prioritise their needs.

Platform teams must enable others to contribute. Three-person teams will encounter problems that the platform doesn’t yet solve. If the only path is to raise a ticket with a central platform team and wait, the model stalls. A federated insourcing approach means stream-aligned teams can contribute capabilities back into the platform – new agent patterns, reusable specifications, domain-specific guardrails – which are then generalised and made available to all teams. The platform grows through use rather than through central planning alone.

In the Team Topologies model, the platform team’s success metric is the autonomy and velocity of stream-aligned teams. The stream-aligned team’s success metric is customer outcomes. Nobody’s success metric is lines of code produced.

Policy compliance, governance and quality assurance must be encoded into the platform and the agent workflows, not bolted on as manual gates after the fact. When agents generate code at speed, human review cannot keep pace. The answer is not to slow down the agents, but to express compliance requirements, security policies and architectural constraints as executable checks that run automatically. Governance becomes part of the delivery pipeline rather than a stage that interrupts it.

Early examples of Forward Deployed Engineers (FDEs) used the platform engineering side of this equation successfully. FDEs built prototypes using platform services and platform teams constantly worked to generalise and incorporate new capabilities into the evolving platform. On a three-person team, it is still important to think about how the work being done for one customer becomes a reusable capability for the next one. Agents handle the construction, humans handle the abstraction.

What this demands from organisations

Three-person teams don’t work inside organisational structures designed for ten-person teams. Agents will burn through backlogs so fast they collide with slow organisational dependencies – cross-team, ticket-based dependencies, architecture approvals, compliance gates. The bottleneck shifts from engineering capacity to decision-making capacity. Middle managers who previously served as coordination points become approval bottlenecks.

Organisations deploying three-person teams need to push decision authority down to those teams. Speed necessitates autonomy. If the team discovers the problem, specifies the solution, orchestrates the agents and validates the outcome but then waits three weeks to release due to internal approvals, the model collapses.

Risk tiering helps here. Not all code carries the same risk. Tiering by business blast radius – internal tools versus external-facing services versus safety-critical systems – determines where human review is essential and where automated verification is sufficient. This moves engineering from a craft model where every line is hand-reviewed to a risk management model where verification investment matches exposure.

The skills that matter now

The humans on a three-person team need to be exceptional at things agents are bad at, such as building trust with customers, recognising when a technically correct solution solves the wrong problem, holding the full context of a business domain in their head, knowing when to push back on what the customer says they want versus what they actually need, decomposing ambiguous problems into agent-sized work packages and calibrating trust in agent output.

These are not new skills. They are the skills that the best engineers and product people have always had. What’s new is that they are no longer diluted by the requirement to also write code eight hours a day. The three-person team concentrates human effort on the work that is irreducibly human – understanding the problem, defining the solution and verifying the outcome. Everything in between is orchestration.

Product creators who work this way – embedded with customers, specifying rigorously, validating outcomes – can now build more complex and valuable products faster than ever before. The three-person team is not a cost-cutting exercise but a structural recognition that the highest-value work in software has always been understanding the problem and we finally have tools that let us spend most of our time doing it.