The Hybrid Team

AI Native Operating Model · Part 2 of 7

Most engineering organisations are still built around a familiar team structure: a product owner, five engineers and a tester, supported by platform and security teams. Work arrives through a backlog, the amount the team can take on is largely determined by the number of people in it, and stand-ups help everyone stay coordinated.

Giving each person an AI assistant makes that team faster, but it does not fundamentally change how the team works. The same people still pick up the same kinds of tasks and move them through the same process. This is why the early stage of AI adoption often feels relatively straightforward: individual productivity improves, while the organisation around it remains mostly untouched.

That starts to change when agents can take on complete pieces of work. If they can research a problem, propose a plan, implement it and run tests—sometimes across several tasks at once—the team is no longer limited only by how quickly people can produce. It starts running into different limits: who can review all that work, who can grant access, whether the agents have enough context, and who steps in when something goes off course late in the day. Output may rise quickly while the team's ability to understand and control that output struggles to keep up.

Once that happens, adopting the technology is only part of the job. The team itself needs to be designed for a different way of working.

The idea in one line

Our working definition is that a hybrid team has a consistent human core, while the amount and type of machine capacity available to it changes with the work.

The people remain responsible for what the team does. They know the domain and the customer, make the important calls, carry the risk and own the outcome. That responsibility does not disappear when agents perform more of the work. What can change from one mission to another is the machine capacity around them. A team may use a few agents for one piece of work and many more for another, depending on what needs to be researched, built, tested or monitored.

This changes staffing decisions as well. More work does not automatically mean more people. The human capacity a team needs depends on how familiar the problem is, how much uncertainty it contains, how serious the consequences of a mistake would be, and how often human judgment is likely to be required. A repetitive, well-understood and low-risk area may be handled by a smaller human team than before. A new product in a high-risk environment may need just as many people, or even more.

What a hybrid team solves

The benefits go well beyond helping engineers write code more quickly.

• Deeper research. An agent can search a codebase, review a year of support history and read the relevant regulations before implementation begins. Decisions that once depended on what somebody happened to remember can be supported by much broader evidence.
• More options explored. A team does not always have to choose one idea based on a discussion or a slide deck. If prototypes are cheap enough to produce, it can build several, compare what actually happens and make a more informed choice.
• Faster execution. Clear, well-bounded work can move from days to hours. Migrations, routine changes and other repetitive tasks no longer have to compete so heavily with product work for the same engineering time.
• More validation. Additional tests, security checks, edge cases and regression scenarios become much cheaper to run. Work that teams previously skipped under time pressure can become part of the normal delivery process.
• Progress outside working hours. Agents can continue across time zones or overnight. Used well, this means people return to work that is ready to inspect, together with the evidence and decisions needed for the next step.

For engineering teams that have spent years with more work than people, this opens up options that were previously unrealistic.

What it creates by shifting the load

The important catch is that faster production does not remove the rest of the work. It redistributes it, often towards the people responsible for understanding, reviewing and approving what has been produced. Traditional teams were not designed for that volume.

• Machine mistakes, at volume. Agents can produce convincing work that is still wrong. Agents using the same model, tools and context may also repeat the same mistake across several tasks. Even if the error rate improves, a large increase in output can leave the team with more errors to find. The post on the delegation boundary looks at how that work should be checked.
• Comprehension debt. A team can end up responsible for code, documents and decisions that nobody on the team has properly read. When engineers no longer create the work themselves, they also lose some of the understanding they would normally build while doing it. We explore that problem further in the Comprehension Engineering series.
• A growing review queue. Every completed agent task eventually reaches a point where somebody needs to judge it. If only a few people have the experience or authority to approve the work, the queue in front of them can grow much faster than they can clear it.
• Too much functionality. When building becomes cheap, teams naturally build more. But every feature still has to be maintained, secured, supported and explained, and customers can absorb only so much change. Software that was easy to create but never genuinely needed is not free; it becomes another liability the organisation has to carry.
• Higher cognitive load. An engineer supervising several agent tasks has to move constantly between different problems. Each task has its own assumptions, current state and unanswered questions, all of which the engineer may need to reconstruct when the agent asks for help.
• Burnout. Agents can continue producing long after people have reached their limit. That pressure is easy to miss because it arrives as a steady stream of branches, reports and decisions rather than one obvious crisis. If experienced engineers feel they must keep pace with the machines, they lose the time to think carefully and eventually exhaust themselves. That is especially dangerous because their judgment is what makes the whole system safe.
• Blurred accountability. If many agents contributed to a change, it can become unclear who genuinely owned the decisions behind it. Responsibility may fall to the person closest to a failure even when that person had limited control over how the system behaved. Madeleine Elish describes this as a moral crumple zone.¹
• Fewer opportunities to learn. Much of the work delegated first will be the work junior engineers traditionally used to build experience. If that work disappears from their day-to-day role, organisations will need another way to help them develop the judgment expected of senior engineers. We return to this in the management post.

A hybrid team therefore cannot be judged by output alone. If it produces far more work but creates an unmanageable review queue, leaves nobody with a clear understanding of the system or burns out the people overseeing it, the bottleneck has moved rather than disappeared. The goal is to benefit from the extra capacity while deliberately controlling the pressure it creates elsewhere.

What Team Topologies still gets right

Team Topologies, by Matthew Skelton and Manuel Pais, gave cloud native organisations a useful way to talk about team design.² It describes four team types—stream-aligned, platform, enabling and complicated-subsystem—and three ways for those teams to interact: collaboration, X-as-a-service and facilitating. Most importantly, it treats cognitive load as something an organisation has to design around rather than something individuals should simply endure.

Those ideas remain highly relevant to hybrid teams.

• Align teams to the flow of value. The stream-aligned team is a natural starting point for what we call a mission team.
• Treat cognitive load as a limit. This becomes more important, not less, when machines can generate work continuously.
• Offer platforms as a service. A shared agent and factory platform is a logical evolution of the platform team.
• Use enabling teams to build capability. Teams will need help learning what they can safely delegate and what must remain under closer human control.
• Create clear interfaces between teams. The Team Topologies concept of a "team API" points towards the handoff contracts needed when work moves between people and machines.

Where it strains

The model becomes less complete when some of the participants doing the work are machines rather than people.

• Team size no longer reflects total capacity. Team Topologies keeps teams small enough to maintain trust and manageable communication, then adds teams as demand grows. A hybrid team can increase its production capacity without increasing headcount, so the number of people no longer tells you how much work the team can generate.
• Cognitive load comes from a different place. Traditionally, much of the load came from building and operating a domain. Now it also comes from reviewing and understanding a much larger volume of machine-generated work. Three people supported by many agents may produce more than those same three people can responsibly understand. The meaningful limit becomes not just what they can build, but what they can explain and stand behind.
• Not every participant is permanent. Long-lived teams still make sense for people because shared context and trust take time to develop. Machine participants can be brought in for a particular task and removed when it is finished.
• The existing interaction modes do not describe human-machine work. Collaboration, X-as-a-service and facilitating explain how groups of people work with one another. They do not cover a person handing work to an agent, an agent returning a decision to a person, or a team calling on a specialist for one specific judgment.
• Specialists cannot be embedded everywhere. Complicated-subsystem teams concentrate deep expertise, but hybrid delivery may create many simultaneous requests for a small number of specialists. What teams often need is not a specialist sitting with them for months, but access to that person's judgment at a particular moment.

A possible structure

The structure below is one we believe is worth testing alongside Team Topologies. We do not see it as a finished organisational model. It needs to be applied in real companies, and parts of it will almost certainly change as we learn more.

Team Topologies' four team types next to a possible hybrid structure. Not finalised: a structure to test in the field.

The stream-aligned team becomes a mission team: a small group of people with product and technical depth, led by someone who is accountable for the outcome and supported by machine capacity that changes with the mission. The platform team develops into an agent and factory platform, operated as a product for the teams using it. The enabling team becomes an autonomy enabling team, focused on removing the technical and organisational obstacles that make delegation unsafe. The complicated-subsystem team becomes a specialist judgment service that missions can call on for specific decisions using a prepared brief. We would also add an element that has no direct equivalent in Team Topologies: enterprise steering, which sets decision rights across missions and uses the Control Room to decide where scarce human attention should go.

This model also needs three additional interaction modes:

• Delegation: a person or team gives work to machines with clear permissions, limits and conditions that require the machines to stop. This is what we call the delegation boundary.
• Escalation: a machine returns a decision to a person and provides the evidence and context that person needs to make it. We cover this in the post on human-machine handoffs.
• Judgment as a service: a mission asks a specialist to make or support a particular decision without permanently adding that specialist to the team.

The human core of a mission team should remain small and relatively stable. People who work together over time develop context, trust and a shared memory of previous decisions, including the shortcuts that looked attractive but failed. Peter Naur called this the theory of the program.³ Machines can help record and retrieve that knowledge, but they do not create the same shared understanding on behalf of the team. The people therefore stay together while the machine participants change with the work.

The mission is the unit

For this structure to work, a mission team needs a clear description of what it owns. The table below shows how that might look for the customer onboarding example used throughout this series.

Field	Onboarding mission
Outcome	New customers reach their first useful result with less avoidable effort, without extra load on support
Accountable owner	One named person
Human participants	Product lead, a staff engineer, a support lead for the operational impact, a security specialist at one decision
Machine participants	Analysis of permitted support records, option generation, implementation in a test environment, test and evidence collection
Authority	Agents may change the onboarding flow in test. They may not change eligibility rules, customer commitments or production data
Decisions kept by people	Eligibility changes, anything that shifts work to support, the production release
Done when	Representative customer cases pass, support impact estimated, rollback shown to work
Outcome check	The signal (time to first useful result), how far it should move, for which customers, how long we watch, and what must not get worse (support contacts)
Budget	Compute, and a stated ceiling on senior and specialist hours
Escalation	A named owner, a named alternate, and what happens when neither is available

"Done when" confirms that the team built what it intended to build. The outcome check asks whether it chose the right thing to build and whether the change genuinely helped. The budget includes human attention because senior and specialist time may be more limited than compute. Defining an escalation path in advance also prevents an agent from making an important decision by default simply because nobody was available when it needed an answer.

Farm or construction site?

Modern farming shows how far mechanisation can go when work is repeatable and conditions are reasonably well understood. A small number of people can operate a very large farm. Construction is also heavily mechanised, yet building sites still require many people because every site presents different conditions, unexpected problems and decisions that are difficult to standardise or verify automatically.

Software is likely to contain both kinds of work. The product may be different each time, but the delivery path often repeats: specify, build, test, release and measure. That process can become increasingly automated. The product itself becomes more farm-like when variation is low and the organisation has a strong specification to work from. We have seen an insurer generate the service, front end, partner adapters, schema, tests and deployment pipeline for a new market from a single market specification. A new product with little precedent and many unanswered questions remains much closer to the construction site.

Organisations can influence where their work sits on that spectrum. Better validation, standard platforms, clearer specifications and inexpensive rollback all make work safer to automate, which is one of the responsibilities of the autonomy enabling team. The level of supervision should then match the work. Predictable tasks can be delegated more broadly and reviewed through sampling, while uncertain or high-consequence tasks need narrower permissions and closer involvement from people who understand the context. Applying one policy to both wastes attention on routine work and takes too much risk with unfamiliar work.

The scarce thing is attention

People often ask how many agents one engineer can supervise, but there is no useful number that applies across different kinds of work. Five agents handling small, familiar tasks may require less attention than one agent working in an unfamiliar system with unclear requirements.

A better way to think about this comes from research into human-robot interaction.⁴ "Fan-out"—the number of systems one person can realistically supervise—depends partly on two measures. Neglect time is how long work can continue safely and usefully without human involvement. Interaction time is how long the person needs to understand the situation and contribute once they return. This suggests two practical ways to improve capacity:

• Increase neglect time by giving agents better context, validation, guardrails and reliable rollback. Much of the current investment in agentic systems is focused here.
• Reduce interaction time by making it easier for a person to see what changed, understand why it changed and make the next decision. This receives far less attention, even though it determines how manageable parallel agent work feels in practice.

Capacity planning should therefore include the human attention required for each outcome, including the time needed to reconstruct context when somebody returns to a task. It should also leave room for interruptions and difficult decisions. If five missions all depend on the same architect, every request may be reasonable in isolation while the combined demand is impossible. Counting agents or compute will not reveal that constraint; planning how much of the architect's time those missions require will.

The ripple across the organisation

A major increase in engineering speed will eventually affect every team involved in deciding, validating, releasing or supporting what engineering produces.

We saw an early version of this at Odevo. As development teams became much faster, product backlogs that once contained years of work began to run down. Product managers could no longer spend most of their time organising a long queue of requests. The main constraint had moved from building ideas to finding, validating and prioritising good ideas quickly enough for engineering to act on them.

The same effect is likely to spread beyond product:

• Product shifts from managing a backlog towards discovery, validation and ownership of outcomes.
• Design and research need to assess ideas at closer to the speed at which those ideas can be implemented.
• Support and operations have to absorb more frequent changes and understand their operational impact.
• Sales and marketing receive more things to launch and explain, while customers still have a limited appetite for change.
• Finance can no longer use headcount alone as a reliable picture of where engineering capacity comes from.
• HR has to reconsider roles, career paths and hiring profiles as the work inside those roles changes.
• Legal, risk and compliance face a larger number of decisions arriving more quickly and requiring their input.

These functions and the processes connecting them were designed around the previous speed of software delivery. If that speed changes materially, the surrounding operating model has to change with it. The Control Room post explores how to make these shifting constraints visible across the organisation, while the management post examines who should be responsible for redesigning the system around them.

Roles become kinds of judgment

As machines take on more of the work between an idea and a finished result, the value people contribute begins to shift. Producing a particular artefact remains useful, but more of the role is about applying judgment: turning an unclear problem into something workable, making architectural choices, simplifying an overcomplicated solution, understanding the domain, looking after a system over time and deciding which risks are acceptable. People will spend less time completing every step themselves and more time directing, inspecting and improving the systems that complete those steps with them.

That does not make deep expertise less valuable. Expertise is what helps someone identify what matters, set sensible constraints and recognise when a polished result is based on the wrong assumption. It does, however, create a difficult question for engineering organisations. If less experienced people no longer do much of the work through which previous generations learned, how will they gain the experience needed to exercise good judgment later? The management post returns to that problem.

Where to start

Begin with one mission rather than redesigning the whole organisation. Write down the outcome, name the people who remain accountable, define what agents are permitted to do and decide how much senior or specialist attention the mission can consume. Include a clear rule for what happens when an agent needs help and neither the owner nor the alternate is available. Then list both the advantages you expect and the new pressure the mission may create, and decide what level of each is acceptable. Comparing the proposed structure with your current teams will expose the places where the model does not fit, which is likely to be more useful than the places where it does.

Next, look beyond the mission team. If it becomes significantly faster, identify which neighbouring team will receive the additional decisions, validation work or change first, and whether that team has the capacity to respond.

Once people and machines are working together inside the same team, the next design question is what each may decide independently, who sets those limits and when those limits should change. That is the subject of the delegation boundary.

---

---

Previously in the series: Towards an AI Native Operating Model.

Next in the series: The Delegation Boundary.

Where did your constraint actually move? We run value-stream assessments to identify the real bottleneck in hybrid delivery and help organisations design an operating model around it. info@re-cinq.com