An AI-supported team delivers a convincing demonstration with fewer people in the room. Has the work become smaller, or has some of it moved elsewhere?
That is the question behind many predictions about AI and team size.
Smaller teams and changed roles can coexist. Neither follows automatically from faster individual output. A useful team design must account for the work the team owns, the expertise it can obtain and the support required to deliver and maintain its results.
Counting the people assigned to a project is only one part of that assessment. The wider organisation may still provide infrastructure, review, specialist decisions and ongoing support.
Before treating a smaller team as a model to copy, establish what has actually changed.
Three sources answer different questions
Gartner's 7 July 2026 announcement predicts wider adoption of smaller software-engineering teams. It also describes their reliance on supporting platform teams. This is an analyst forecast for a particular field, not evidence that all businesses already operate better with fewer people.
Deloitte's February 2026 team-dynamics analysis reports stronger perceived AI outcomes among larger, varied and connected teams. Its methodology describes a July 2025 survey of 1,394 US professionals. These are self-reported associations, not proof that increasing team size causes better results.
Anthropic's 16 October 2026 study of its own employment describes changes in work, hiring and the attention needed around agent output. It combines internal data with employee interviews. The company is an AI provider undergoing rapid growth; its experience is not a representative forecast for other employers.
The apparent disagreement is informative. A forecast, a worker survey and a company case examine different populations and conditions. They cannot establish one universally correct team size.
Define the team before comparing its size
“Team” can mean a group assigned to one feature, a permanent department or everyone needed to provide a service.
Those boundaries matter.
A product group may have few permanent members while drawing on shared infrastructure, security, design research and operational support. Another group may contain those capabilities within its own membership.
Comparing their visible headcounts without describing the arrangement can make a transfer of work look like its disappearance.
The same problem arises over time. A project might begin with a small group because another team has already prepared the platform it uses. Once the project enters ordinary operation, it may need a different support arrangement.
Ask which work is inside the count, which sits outside and which has not yet been assigned.
A smaller core team may be a sensible design. It still needs an honest account of its dependencies.
Follow a fictional catalogue feature
Imagine a retailer building an internal tool that helps staff edit product-catalogue information.
The proposed feature has a straightforward demonstration: an employee changes a description, checks the draft and submits it through an agreed process.
AI assistance might help the software team prepare code, explore an implementation or draft documentation. A small group may be able to produce an early version.
The demonstration does not settle every part of the service.
Someone must understand which catalogue rules apply. Someone must examine whether the proposed changes are suitable. Access, release arrangements and support need attention. The team also needs a way to handle cases that do not fit the original design.
This is a fictional example, not a reported deployment or a claim that any particular AI system can deliver the feature. It illustrates the difference between producing an early version and organising the work around it.
The team-design question is where those responsibilities should sit.
Separate removed work from relocated work
Suppose the feature group no longer prepares some routine documentation manually. That may represent a change in how the work is done.
Suppose it also stops maintaining its own deployment process because a shared platform group now provides one. That is a different change.
Both can help the feature group operate differently, but only the first concerns the direct substitution of an activity. The second changes who supplies a service.
There may be additional work too: checking generated material, maintaining an integration or investigating a new class of failure. Whether that work is substantial requires observation.
For the fictional retailer, a useful review would follow an ordinary catalogue change from request to supported release. Identify where people contribute and what each contribution provides.
The aim is to understand the arrangement before drawing a staffing conclusion. A list of activities is not, by itself, a formula for the number of employees required.
Make shared support part of the design
A dependency is not necessarily a weakness. Shared services can provide expertise and consistency that a small feature team could not maintain alone.
The question is whether access to that support is real.
Who can request help? What information does the supporting group need? Which decisions remain with it? How does the feature team proceed when its request competes with other work?
In the catalogue example, the feature group might rely on a shared release service. If that service cannot support the proposed schedule, the feature team needs to know before making a commitment.
A smaller group with dependable support is a different arrangement from a smaller group whose members must quietly obtain favours from overloaded colleagues.
The organisation should examine the burden on the supporting teams as well as the output of the visible project group. Otherwise, a local improvement can conceal pressure elsewhere.
That is a proposed design consideration, not a claim that centralised support is always preferable.
Examine review capacity as output changes
Producing more material can change the work required to assess it.
For the fictional feature, an assistant might help generate several implementation options. A person still needs an appropriate basis for choosing between them and identifying what requires further examination.
The useful question is whether the arrangement provides enough relevant expertise and attention for that task.
More generated options are not automatically better. A team may need to narrow the question, improve its evaluation process or stop producing material that nobody can use.
Review can also be distributed. Some checks may be supported by tools, while others need domain knowledge or a decision about the intended behaviour. The right arrangement depends on the work.
A team design should describe who contributes that knowledge and how unresolved questions reach them. Merely adding “human review” to a diagram leaves important choices unanswered.
Different responsibilities do not always require new titles
AI can change what an existing role involves.
A developer might spend a different share of time examining proposed changes. A product colleague might need to make business rules more explicit. An experienced practitioner might contribute more to evaluating unusual cases.
Those are possible changes in responsibilities. They do not automatically establish three new occupations.
Before creating a title, describe the work that needs a home. Is it continuous or occasional? Does it require a dedicated capability? Could an existing role reasonably absorb it, with appropriate resources and preparation?
In the catalogue team, maintaining a set of evaluation examples might become a recurring responsibility. That could justify a clear assignment without requiring a new department.
Equally, adding the responsibility to an already full role would not make the work disappear. A changed title or job description needs to correspond to a workable contribution.
The important question is whether people can understand what they are now responsible for doing.
Preserve access to different kinds of expertise
A smaller group may communicate easily while lacking a perspective essential to the work.
In the fictional retailer, technical colleagues might understand the implementation but need help interpreting a catalogue exception. A business colleague might know the rule but need help assessing its consequences for the system.
The team needs a way to combine those contributions.
That does not mean every specialist must attend every meeting or become a permanent member. Some expertise can be consulted at defined points. Other work may require closer involvement.
Choose the arrangement according to the decisions being made, the frequency of the need and the cost of waiting.
The team should also know how to obtain a challenge to its preferred answer. Reducing handoffs can be useful, but eliminating every independent perspective would be a different choice.
Neither a small nor a large group is automatically good at hearing disagreement.
Consider continuity and learning
A design that works while one experienced colleague is present may be difficult to sustain during an absence or a change of staff.
Ask where important knowledge sits and how another person could understand the relevant decision. Documentation can help, but it needs to reflect the reasoning and conditions rather than merely preserve an instruction.
In the catalogue example, someone should be able to explain why an unusual case is handled differently and when that choice needs review.
Development matters too. If AI changes the work beginners previously encountered, the team needs to consider how they will gain relevant understanding. A smaller group still requires a credible way to develop future capability.
The human learning advantage provides a useful context: competent performance today and the ability to adapt later are related but distinct concerns.
This is not a promise about job security or a requirement to preserve every old assignment. It is a reason to include continuity and learning in the design.
Test a bounded arrangement before treating it as a model
The fictional retailer could examine one clearly scoped feature under an agreed team arrangement.
Before beginning, describe the work in scope, the shared support available and the decisions the team can make. Identify what evidence would be needed to assess the arrangement.
During the work, look beyond the speed of the first demonstration. Examine correction work, unresolved dependencies, demands on specialists and the ability to support the feature afterwards.
Ask team members and supporting colleagues what became easier and what became harder. A faster local step may be useful without establishing that the overall arrangement has improved.
A review could justify retaining the design, changing its boundary or providing different support. It could also show that the proposed scope was unsuitable.
These are editorial suggestions for a practical examination, not an experimentally validated team-design method or advice to reduce staffing.
Use an executive event to expose the boundary
A leadership discussion can make the hidden work visible.
Present the fictional catalogue feature and ask participants to draw the boundary around the team they propose. Then ask where the remaining work would go.
Who supplies the platform? Who answers an unfamiliar business question? Who can examine a consequential change? Who maintains the service after the project group moves on?
Different answers can reveal assumptions about resources and authority. The discussion becomes more useful when participants describe a concrete arrangement rather than debate whether teams should be “tiny.”
A keynote can introduce the question. A facilitated session can examine a particular organisation's choices. Our guide to designing a corporate AI learning summit explores how to connect an event with workplace follow-through.
An event does not determine an organisation's staffing needs or replace the relevant operational assessment.
Count the work around the team
Sources were checked on 28 October 2026. This article uses Gartner's public forecast announcement, Deloitte's survey analysis and Anthropic's internal company study. They are selected evidence with different scopes, not a systematic review or proof of an optimal team size.
The fictional retailer and proposed review are original illustrations.
AI may support smaller groups in some settings and different responsibilities in others. Both changes can occur together. The meaningful question is whether the complete arrangement can deliver, review, maintain and improve the work it owns.
Before accepting a smaller-team proposal, ask: What work has genuinely changed—and what work are we now expecting someone outside the team to carry?
Bring that discussion to your next leadership or workforce event. Explore Learning Coach's international keynotes and request a tailored proposal.
References
Gartner, Smaller software-engineering teams by 2029. Public forecast announcement, 7 July 2026; field-specific prediction, not an observed universal outcome.
Brodzik, C., Kulkarni, A., Mahto, M., and Kreit, B. Bridging the AI value gap: Are team dynamics the missing link?. Deloitte, 27 February 2026; July 2025 US self-report survey and association limits.
Wilmers, N., Catipon, R., Massenkoff, M., and McCrory, P. How employment is changing at Anthropic. 16 October 2026; company-internal data and interviews, with limited generalisability.
