In short: Focus capacity is how many bets an organisation can fund and steer with a declared value. Agents make starting work cheaper, so more bets end up in flight, while steering each one costs the same as before. Capacity plans count people and sprints, yet focus is usually limited by coupling. In the move to agents, CTOs who size bets by coupling and fund the bets that raise capacity are likely to get far more from AI.

What happens to Direction when starting work gets cheap?

An agent can now produce a working prototype in an afternoon. Saying yes to an idea has never been cheaper.

Steering that idea costs the same as before. Someone still has to decide it is worth funding, agree on the outcome, coordinate the teams it touches, check whether it worked and stop it if it did not.

DORA's 2025 research points at the same tension. Its central finding is that AI amplifies what is already there. Its AI Capabilities Model, drawn from nearly 5,000 technology professionals, lists user centric focus among seven capabilities that amplify the effect of AI. Without that focus, adopting AI tools can harm a team's performance. Organisations with mature value stream management also see much larger benefits from AI. Speed, it seems, amplifies whatever direction it is given.

That direction is set at the first stage of the AI Engineering Production System. The capacity that limits it is focus capacity: how many bets an organisation can fund and steer with a declared value.

On the capacity map, focus capacity is usually lowered by organisational coupling. A sign that it binds is decisions queuing at Direction while many initiatives are in flight with few declared values. This article looks at how to raise focus capacity instead of spending it.

Why do capacity plans count people?

Most portfolios are sized the same way. Finance funds headcount, so the plan starts from FTEs. Those FTEs become teams, and the teams offer sprints, often converted into story points or a velocity. The next quarter's bets are then fitted into the total.

Scaled frameworks formalise the arithmetic. SAFe, for example, suggests a starting baseline of eight points per full time developer per iteration, until a team has its own history.

There are good reasons to plan this way. Headcount is what an organisation can budget, hire and audit, and team sprints are easy to compare from one quarter to the next. SAFe itself treats the eight points as a starting point, to be replaced by measured velocity. When most bets stay inside one team, counting team capacity works well enough.

The approximation breaks when bets cross team boundaries. A team sprint counts the same whether the work stays in one team or needs five teams to change their services together. Coordination, sequencing, shared decisions and joint releases appear nowhere in the plan. They land at Direction, as dependencies to negotiate and decisions waiting for several owners.

Agents widen this blind spot. When build capacity per team rises, the plan shows more room and invites more bets. The coupling each bet must cross stays the same, so the extra bets mostly add coordination load.

How does technical coupling become a Direction problem?

Coupling usually starts as a technical property: how services, data and domains depend on each other. It ends up as an organisational one.

Research has tested this link. MacCormack, Baldwin and Rusnak compared matched pairs of software products, and in every pair, the product built by the more loosely coupled organisation was significantly more modular. Organisations and their systems tend to mirror each other.

For Direction, the consequence is practical. When a domain is spread across services owned by several teams, every bet in that domain needs those teams to move together. Whatever the architecture splits, the portfolio has to put back together through meetings, dependency boards and coordinated releases.

A case observation. In an engineering organisation of around 700 people, Shape and Direction were sized from FTEs and the existing capacity plan. The plan did not look at where the coupling sat, or at the state of the architecture underneath it.

Two patterns stood out. In some areas, functionality was spread across distributed islands of services where a modular monolith would have done the job. In others, an event driven architecture had no transactional store as its source of truth, so teams had built extra mechanisms just to work out the current state of their data.

Neither pattern is wrong in itself. Distributed services make sense when teams need to deploy and scale independently, and event driven designs work well with a clear source of truth. The issue was fit, a question of the scale that justifies the complexity. The architecture had grown without regard to team scale, and the capacity plan inherited its cost without seeing it.

In a setup like this, headcount says little about how many bets can move. The coupling footprint of each bet says much more.

Public cases point the same way. Segment consolidated more than 140 destination services into one after its operational overhead grew with every destination it added. Its engineers later wrote that one engineer could then make a shared library change in minutes that had previously meant deploying over 140 services. Segment kept microservices for other parts of its platform, which supports the reading that the question is one of fit.

Figure 1. The same portfolio counted two ways. In team sprints it fits; counted by the teams each bet has to cross, it may not.

Figure 1. The same portfolio counted two ways. In team sprints it fits; counted by the teams each bet has to cross, it may not.

How many bets is the right number?

If coupling limits focus capacity, headcount cannot tell you how many bets to run. Four practices can help.

Size each bet by its coupling footprint. Before funding a bet, count the teams it touches, the services it changes and whether it needs a coordinated release. Two bets of similar effort can load Direction very differently. A quarter planned as twelve bets might turn out to be closer to six.

Declare the value before funding. A bet without a value hypothesis, a measure and an owner can still be started and staffed. Nobody can steer it, though, because nobody can say whether it works. The declared outcome is also where intent capacity begins.

Cap bets in flight at the binding capacity downstream. Direction decides how much work every other stage receives. If verification capacity binds, extra bets only lengthen the review queue. Little's law makes this plain: with throughput unchanged, more work in flight means longer lead times for everything. The limit should come from whichever capacity binds today, and move as the constraint moves, as Constraint Migration predicts it will.

Keep a stop loop. Outcome reads from Observe & Improve should come back to Direction every month or quarter, and each bet is then scaled, continued or stopped. Without stopping, work in flight only grows.

One objection deserves an answer. If agents make prototypes almost free, why not run far more experiments? That can make sense, as long as experiments stay separate from bets. A probe that one team runs with a stop date, and that makes no claim on verification, release or operations, costs little focus. Once it needs other teams and downstream capacity, it becomes a bet and should be counted as one.

Figure 2. The steering loop. The limit on bets in flight comes from the binding capacity downstream, and every bet returns to Direction to be scaled or stopped.

Figure 2. The steering loop. The limit on bets in flight comes from the binding capacity downstream, and every bet returns to Direction to be scaled or stopped.

Which bets does the transition to agents need?

Most bets consume focus capacity. A few raise it, and the move to agents depends on them.

For most organisations, getting from assisted coding to agents that work autonomously and safely is still a lot of work. Agents need platforms, support and enablement. They need context capacity, so they know the systems they change. They need control capacity, so the organisation can authorise, trace and reverse what they do. None of this ships as a customer feature, and all of it competes with feature bets for the same focus.

Architecture simplification belongs on the same list. Consolidating services that never needed to be distributed, or restoring a transactional source of truth, reduces the teams and seams future bets must cross. Its value can be stated in focus terms: fewer teams per bet, fewer coordinated releases, faster decisions in the domains it touches.

These are portfolio decisions. The choice is often between one transition bet this quarter or another round of feature bets in the same coupled domain, knowing the transition bet could let more bets move in the quarters that follow. A capacity plan counted in FTEs rarely shows it that way, because it sees these bets only as cost.

AI may also make simplification cheaper. In a twelve month case at Google, three developers ran 39 migrations, and a language model generated about three quarters of the 595 code changes. Each change was validated by building and testing it, then reviewed by developers before it landed. The setting is specific to Google, and these were well defined migrations, such as widening identifiers from 32 to 64 bits.

Redrawing service boundaries is harder, so the claim has to stay conditional. AI can lower the cost of simplification where verification capacity can show that behaviour is preserved, people own the target boundaries, and work moves in small batches through the delivery pipeline. Without those conditions, agents may add code faster than they consolidate it. GitClear's analysis of 211 million changed lines found that during 2024, moved lines, its sign of refactoring, fell by about 40%, and copied and pasted lines outnumbered them for the first time.

Who owns what between Shape and Direction?

Direction works with the coupling that Shape gives it. Shape is the frame: team boundaries, decision rights and the funding model, reviewed yearly. Direction runs monthly or quarterly, so much of focus capacity is won or lost before any bet is discussed.

Three Shape decisions matter most.

Team boundaries. Teams cut along the flow of value reduce the number of teams a typical bet needs. This is the idea behind stream aligned teams in Team Topologies, and the mirroring evidence suggests the architecture tends to follow the organisation over time.

The funding model. Funding persistent teams around products or domains keeps the coupling map stable enough to plan against. Project funding counted in FTEs still suits work that is genuinely temporary.

Decision rights. When most bets can be approved within one product line, the queue at Direction stays short, and only the truly cross domain bets need escalating.

What role does the CTO play?

This is where the CTO's role is changing. A CTO who only delivers the bets others choose will find it hard to protect focus capacity. The CTOs with real business impact, sometimes holding product as well as technology as a CPTO, take part in setting direction.

They make sure the portfolio matches what the system can absorb. They bring the capacity map, which shows which capacity binds and how many bets fit. They bring the coupling map, which shows what each bet will cost to steer. And they use their judgement and their knowledge of the systems to influence where the organisation goes, including which transition bets to fund first.

That is the transformation most organisations are now in. Agents are raising build capacity today, while context capacity, control capacity and the architecture are still catching up. Managing that transition, deciding what to start, what to stop and what to fix first, may well be the CTO's most important job for the next few years.

How can you tell whether focus capacity is binding?

Three probes help. Flow is decision latency, the time from a bet being proposed to being funded. Quality is the share of bets in flight with a declared value, a measure and an owner, and the share whose outcome was actually read. Coupling is the average number of teams per bet and the share of releases that had to be coordinated.

Most of this data already sits in work item, linking and release tools. A short manual list for the ten to twenty largest initiatives usually fills the gaps, since value hypotheses are rarely recorded in a tool. The absorption dashboard shows how these probes roll up to the signature metric.

If something cannot be measured, that is a finding too. A portfolio where nobody knows which bets have a declared value is unlikely to be steering them.

Where should a CTO start?

Take this quarter's bets and count them twice: once in team sprints, and once by the teams each bet touches and the releases it must coordinate. If the two counts disagree, focus capacity is probably binding.

Then require a declared value before funding, and set the limit on bets in flight from the binding capacity downstream. Finally, put at least one transition bet on the portfolio, such as simplifying the most coupled domain, with its value stated in focus terms.

The question for your portfolio

Agents will keep making it cheaper to start work. The organisations that benefit are likely to be those that steer fewer bets better, and that fund the bets raising their capacity to absorb more.

If you counted next quarter's bets by the teams each one has to cross, rather than by the people available, how many would still fit?

Read further

FAQ

What is focus capacity?

Focus capacity is how many bets an organisation can fund and steer with a declared value. It is the capacity of the Direction stage in the AI Engineering Production System. It is usually lowered by organisational coupling, where most initiatives need several teams to move. A sign that it binds is decisions queuing at Direction while many initiatives are in flight with few declared values.

How does focus capacity differ from portfolio management or WIP limits?

Portfolio management and limits on work in progress are practices, and focus capacity is the measure they serve. It adds two things to the usual portfolio view. Bets are weighed by the teams and seams they cross. And the limit on bets in flight is set from the capacity that binds downstream, so Direction never funds more work than the rest of the system can absorb.

Why are FTE based capacity plans misleading?

They are accurate about people and silent about coupling. A team sprint counts the same whether a bet stays inside one team or needs five teams to release together, so the coordination cost lands at Direction without appearing in the plan. When agents raise build capacity per team, the plan shows more room and invites more bets, while the coupling each bet must cross stays the same.

Which bets raise focus capacity?

Bets that reduce the cost of future bets. During the move to agents, these include the platforms and support agents need, context capacity so agents know the systems they change, control capacity so their actions can be authorised and reversed, and architecture simplification that cuts the teams each bet must cross. Their value can be stated in focus terms and compared with feature bets on the same portfolio.

Can AI simplify an architecture?

The evidence supports a conditional answer. Google reports a model generating about three quarters of the code changes in a year of well defined migrations, each validated by builds and tests and reviewed by developers. Redrawing service boundaries is harder. AI is most likely to help where verification capacity can show that behaviour is preserved, people own the target boundaries and changes move in small batches.

Sources