When AI Shrinks the Team, the CTO Job Expands

AI is making small engineering teams credible again.

A few experienced people can now investigate an unfamiliar codebase, draft an implementation, write tests, prepare infrastructure changes and document the result without passing the work through a department for each technical specialty. That is a meaningful change. It affects cost, pace and the kind of organization a CTO should be willing to build.

It is also easy to draw the wrong conclusion from it.

The fact that a small team can produce more software does not mean the surrounding work has disappeared. Someone still has to understand the product, choose the right problem, recognize a bad assumption, protect an interface, validate the result and operate what was released. AI compresses parts of execution. It does not compress consequence.

At its largest, the engineering organization I led included more than 80 internal and external engineers working through technical leads and distributed teams. The organization has since been downscaled. Today a much smaller group, supported by AI, carries wider slices of the work end to end. This is not a target-state diagram. We have implemented it, and we see it working very well.

The contrast has changed how I think about scale. Headcount is no longer a good proxy for delivery capacity, but neither is generated output. The useful unit is a team that can own a meaningful outcome from decision to operation.

That kind of team needs fewer hand-offs. It also needs a more demanding operating model around it.

The team became smaller; the product did not

A connected product does not become less cross-disciplinary because fewer people are building it. Hardware, firmware, mobile, cloud, security, manufacturing, certification and support still meet at the same interfaces. The product retains its installed base, operational history and obligations. A customer does not experience a smaller org chart. They experience whether the whole system works.

The same is true in a software-only business. A compact team may be able to change many parts of the stack, but the business rules, data contracts, security boundaries and operating commitments remain. Broader tooling gives the team a larger surface to influence. It does not give the team automatic understanding of that surface.

In our current work, that broader surface includes agentic customer support for connected products, product development, refactoring software for better performance and security, and end-to-end testing of web interfaces. We also do much more software testing than before. The same tools that increase the pace of change allow us to test considerably more of what we change.

This is why I am cautious when the small senior AI pod is presented as the conclusion. It is a useful team shape, not a complete organization design. The difficult question is what must be true around that pod for its speed to remain trustworthy after the first demonstration.

AI can reduce the number of people needed in an execution team. It does not reduce the number of consequences that team must understand and own.

The bottleneck moves from production to judgment

For much of software development, producing a plausible first implementation was expensive. A team divided the work because each part required time and specialist skill. AI lowers that cost unevenly. Code, configuration, tests, documentation and analysis can all be produced faster, at least under the right conditions.

The scarce work then moves.

It moves into deciding which change is worth making. It moves into supplying the context the system cannot infer. It moves into recognizing when a locally sensible change violates an external contract. It moves into checking whether a proposed result is merely convincing or actually correct. It moves into understanding what happened after release.

This is not a semantic distinction. It changes where a CTO should invest capacity. If generation is accelerated while review, product evidence and operational feedback remain unchanged, the organization creates a queue of plausible work waiting to be trusted. If review is compressed to keep pace, it creates a larger queue of work that has been accepted without enough evidence.

Research on AI-assisted development is a useful warning against treating output as productivity. In one controlled study, experienced open-source developers expected AI tools to make them faster on familiar repository work, while the measured result in that particular setting was slower. The study was deliberately narrow and should not be generalized to all engineering. Its durable lesson is simpler: perceived acceleration and measured improvement are not the same thing.

The operating model therefore needs to make judgment and verification visible work. They are not the tax paid after the AI has done the valuable part. They are the valuable part when the cost of producing another candidate answer approaches zero.

Organize around an outcome, not a technology lane

Traditional engineering organizations often divide ownership by technical layer. The mobile team owns the application, the cloud team owns the service, the firmware team owns the device, and a project or product function coordinates the result. This creates depth, but it also creates queues at every interface.

A small AI-enabled team can work differently. In the model we now use, the team owns a coherent operating outcome across several layers: completing an installation, restoring a failed product, shipping a bounded capability or reducing uncertainty in a support case. AI helps experienced engineers cross the routine parts of a technical boundary without waiting for a separate team.

The boundary still matters. The team should know where it may decide independently, where a specialist must join and where a wider authority is required. The objective is not to make every engineer interchangeable. It is to keep ownership of the outcome intact while bringing specialist depth to the point where it changes the decision.

The design test is whether the team can carry a decision to observed outcome without losing the context that made the decision sound. A team that can generate across the stack but cannot see what happened in production is not end-to-end. It is only broad at implementation time.

Give the team the whole feedback loop

Small teams become effective when they own the work after deployment as well as before it. Operation exposes assumptions that architecture review cannot. Support reveals where the product fails to explain itself. Incidents show which interfaces are poorly observed and which recovery paths exist only on paper.

This feedback should reach the people and agents doing the next round of work. Otherwise the organization gains implementation speed while continuing to learn at the old rate.

For a focused team, full-cycle ownership means being able to answer:

1. What operating outcome are we responsible for?
2. Which evidence describes the current state?
3. Which interfaces and constraints may this change affect?
4. How will we decide that the result is correct?
5. What will we observe after release?
6. Who responds when reality disagrees with the plan?

The last question cannot be delegated to a model. An agent can assemble evidence, identify a pattern and propose a response. Accountability for the operating consequence remains with a named person and team.

This is also where platform work earns its place. A shared platform should remove repeated mechanics, provide safe paths and improve observability. It should not remove the product team’s ability to see or own the outcome. When every important change requires a platform queue, the organization has rebuilt the old hand-off structure under a newer name.

Rent specialist depth; retain decision ownership

The phrase “expert generalist” is useful if it is not mistaken for a person who needs no one else. Strong generalists know enough across disciplines to frame a problem, use AI to traverse routine work and recognize where the decision exceeds their depth. Part of their expertise is knowing when not to generalize.

A smaller permanent team can be surrounded by specialist capacity that joins for a defined boundary: radio performance, functional safety, certification, data protection, a difficult production failure or a consequential architectural choice. The specialist should change the quality of the decision without becoming a new hand-off owner for the outcome.

That distinction matters. If the focused team throws a question over a wall and waits, it has not escaped the functional organization. If it uses specialist input but cannot explain the resulting decision or carry its operational consequences, it has borrowed an answer rather than developed ownership.

The permanent team should retain:

• the product and operating context;
• the decision record and its assumptions;
• responsibility for integrating specialist advice;
• the interface contract affected by the choice;
• the evidence used to validate the result;
• the trigger for reviewing the decision again.

Specialist access can be elastic. Decision ownership should not be.

Separate generation from verification

When the same person uses the same context and the same model family to generate, review and explain a change, apparent independence can be misleading. The review may simply reproduce the assumptions that produced the result.

Verification needs a different basis. Depending on the consequence, that might be a deterministic test, an independent observation, a second implementation, a specialist review, historical cases, a staged release or direct evidence from the physical system. The important point is not that a human must inspect every generated line. It is that acceptance must rest on evidence suited to the failure being controlled.

Our increase in testing is a practical example. End-to-end web-interface tests can exercise complete user paths while lower-level tests cover the contracts and failure conditions below them. AI makes it economical to create more of this evidence, but the generated test is not automatically proof. It still has to exercise the right behavior, fail for the right reason and remain useful when the product changes.

This changes planning. A team should reserve capacity for verification before generation begins. For a high-consequence change, the validation approach is part of the design, not a final task added when the implementation looks finished.

It also changes what leaders ask in review. “How much did the agent complete?” is less useful than:

• Which decisions did the team delegate?
• Which assumptions came from supplied context rather than observation?
• What evidence would prove this wrong?
• Which boundary carries the highest consequence?
• What did operation teach us that the implementation process did not?

These questions make AI use inspectable without turning it into a compliance performance.

A senior pod still needs a succession system

A team of experienced people using capable agents can be remarkably productive. It can also consume its own future.

We have not yet made apprenticeship a deliberate practice inside our smaller-team model. I see it as important for the future. The current delivery model may work well while the longer-term talent pipeline remains unresolved; those are separate questions, and success in the first does not answer the second.

Senior judgment is built from exposure to real decisions, review and consequence. If all meaningful work is concentrated in senior pods while less experienced engineers receive only low-risk cleanup, the organization protects today’s throughput by weakening tomorrow’s capability. AI makes this easier to miss because it can fill the visible gap between instruction and output.

A future apprenticeship model should not preserve inefficient work for training. It should develop judgment rather than typing. Less experienced engineers can own bounded changes, reconstruct incidents, prepare verification plans, challenge assumptions, review agent trajectories and explain why an interface behaves as it does. The scope can be controlled without making the work artificial.

Senior engineers remain accountable for the boundary and the review. The developing engineer gets access to the reasoning, evidence and consequence that create expertise. An organization that does not make room for this will eventually discover that its small senior pods are a fixed inventory, not a renewable capability.

Measure the operating system, not the org chart

Reducing team size can lower cost. It can also produce an attractive chart that says nothing about whether the organization is learning faster or carrying more risk.

I would rather inspect a small set of operating signals:

• time from an important question to a decision supported by evidence;
• time from release to trustworthy observation of the outcome;
• number and age of unresolved cross-team dependencies;
• changes reopened because a material assumption was missing;
• work returned after verification or operation exposed a defect;
• concentration of decisions in one senior person;
• incidents or difficult reviews that produced a reusable improvement.

These are not universal performance metrics, and they should not be collapsed into one score. They are ways to see whether the small team is genuinely removing coordination cost or merely hiding it inside senior attention, delayed verification and operational debt.

DORA’s research describes AI as an amplifier of the system in which it is introduced. That matches the practical pattern. Clear ownership, small batches, good feedback and a healthy delivery system become more valuable when production accelerates. Weak interfaces, fragile systems and unclear responsibility are amplified too.

The CTO’s work becomes more technical, not less

If small teams can produce across a wider surface, the CTO does not need to coordinate as many specialist queues. That does not make the role lighter. It moves the work into the architecture of the organization itself.

The CTO has to define where a focused team may act, make product evidence available, preserve independent verification, connect specialist depth without recreating hand-offs and ensure that operating feedback changes the next decision. The CTO also has to protect the development of people who do not yet possess the judgment on which the model depends.

AI allows a smaller group to carry more execution. The responsible response is not to pretend that every part of the old organization vanished. It is to decide which responsibilities can be compressed, which must remain independent and which become more important when the cost of producing work falls.

The small team is real. So is the larger system it needs in order to remain good.

Sources and further reading

1. Steven Brovich’s AWS talk, “Leading Through the Agentic AI Transition”, presents the small senior pod, expert-generalist and learning-organization models that this article examines from an operating CTO perspective.
2. Anthropic, “Labor market impacts of AI: A new measure and early evidence”, distinguishes theoretical exposure from observed AI use and reports early, suggestive evidence about hiring without claiming a systematic rise in unemployment.
3. Becker et al., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, reports a controlled study in which experienced developers took longer with the tested AI tools on the sampled repository tasks, despite expecting a substantial speed-up.
4. Martin Fowler, “Expert Generalists”, discusses how broad technical fluency and the ability to work with specialists become more valuable as LLMs make it easier to cross traditional discipline boundaries.
5. Google Cloud’s DORA team, State of AI-assisted Software Development, frames AI as an amplifier of the organization’s existing strengths and weaknesses rather than an independent cure for its delivery system.