I have been writing about two forces that increasingly meet in the same engineering team.
One expands what we can produce. Better models, agentic workflows, explicit context, and autonomous delivery make more work possible with less direct intervention.
The other exposes what we struggle to absorb. Decisions accumulate. Understanding takes time. Customers have to adopt changes. People need opportunities to learn, connect, and appreciate what they have accomplished.
Put those forces together, and a question emerges:
What is the maximum velocity of a team?
And a second question follows closely behind:
How would we know whether we were approaching it?
In “Path to the Dark Factory”, I explored how eligible work could move through delivery without routine human intervention. That raises the production ceiling. It leaves an important question open: how much useful change can the surrounding organization carry?
A factory can become faster while its output waits for decisions, integration, or adoption. Its capacity matters, but the team’s result depends on the entire journey.
A definition
I would define maximum team velocity as the highest sustainable rate of progress toward a specified outcome, within agreed limits on cost, risk, and human workload.
That definition deliberately requires context.
Maximum velocity toward what? Over a week or a year? With which responsibilities? At what acceptable failure rate? With how much investment in the team’s future?
Without those boundaries, “maximum” becomes an invitation to keep asking for more.
There are also three different things we should separate.
| Concept | What it describes |
|---|---|
| Observed velocity | The progress the team is making today |
| Sustainable capacity | The pace the current system can maintain under ordinary variation |
| Chosen operating pace | The pace we commit to, given priorities, uncertainty, and other uses of capacity |
A strong week demonstrates a strong week. It does not establish sustainable capacity.
And discovering more capacity does not automatically settle how we should use it.
That distinction matters because otherwise every improvement becomes a permanent increase in expectations.
In “The Pace”, I asked what happens when AI weakens our shared understanding of a reasonable working day. A maximum-velocity model should help restore explicit expectations. Used carelessly, it could make the problem worse by turning every exceptional result into a new minimum.
The purpose is to understand capacity well enough to make deliberate choices.
Where the constraint sits
Consider a hypothetical team:
| Stage | Changes a week |
|---|---|
| Its agents can prepare | Twenty |
| Its verification can confidently assess | Eight |
| Its release process can carry | Six |
Those numbers are illustrative, and they assume reasonably comparable changes. But the immediate problem is clear: increasing generation to forty does not make forty useful changes available.
It may create a larger queue.
Now suppose the team improves verification and release. Customers still struggle to adopt more than a few workflow changes at a time.
That resembles the argument in “From Execution Speed to Adoption Limits”. But I would qualify that argument here.
Human adoption is a possible constraint, not a universal final destination for every bottleneck.
| Work | Its path to value |
|---|---|
| A new workflow | May demand training |
| A latency improvement | May benefit users without requiring them to learn anything |
| A security fix, infrastructure saving, or removal of recurring operational work | A different path to value |
The work mix matters.
When feature adoption becomes constrained, the team may have useful capacity for simplifying the product, improving reliability, reducing cost, or retiring obsolete systems. It may also choose to preserve some of that capacity.
We need to identify the actual constraint before declaring that the team has reached a human speed limit.
People, scope, and team design
The same qualification applies to cognition.
In “The Cognitive Ceiling”, I explored the feeling of receiving more information than I could meaningfully absorb. That concern remains relevant. But an individual’s attention limit does not directly establish the team’s limit.
Team design determines how much information must pass through each person.
If every engineer needs to understand every change, the team creates one kind of ceiling. Clear boundaries, dependable interfaces, shared conventions, and well-defined decision authority create another.
We should ask both how much people can absorb and why the workflow requires them to absorb that much.
This is also where I would revisit “The Fantastic 4”.
Four engineers can be an attractive arrangement. It is not a universal optimum. These two groups of four face different problems:
| First group of four | Second group of four | |
|---|---|---|
| Scope | Owns a coherent domain | Maintains several services |
| Conditions | Mature tooling | Demanding operational coverage, and coordination across many teams |
A fifth person might introduce coordination cost. They might also remove a critical skill bottleneck or make the workload sustainable.
The useful unit of analysis is the team together with its scope, dependencies, and obligations.
Six capacities
To understand its ceiling, I would examine six capacities:
| Capacity | The question to investigate |
|---|---|
| Direction and decisions | Can we choose worthwhile work and resolve ambiguity quickly enough? |
| Execution | Can we produce the required changes within our time and cost constraints? |
| Verification | Can we establish that those changes satisfy the intended requirements? |
| Integration and operation | Can we introduce and support them safely in the real system? |
| Adoption and feedback | Can the intended beneficiaries use them, and can we observe the result? |
| Renewal | Can we maintain the skills, understanding, and energy this pace depends on? |
This is a diagnostic model, not a formula. These capacities interact, and different work takes different paths through them.
Renewal deserves particular attention.
A team can increase current delivery by postponing maintenance, concentrating decisions in its most experienced engineer, and eliminating time for teaching. The resulting output is real. So is the obligation it leaves behind.
That is why the time horizon belongs in the definition.
A pace that works for one release may weaken the team over two quarters. To claim a sustainable increase, we need evidence that the system continues to function when someone is away, an incident occurs, or unfamiliar work arrives.
We also need to avoid turning sustainability into a vague explanation for every delay. Some friction is removable. Some habits deserve to change. Some uncomfortable learning is worthwhile.
The practical challenge is to distinguish effort that builds capacity from pressure that consumes it.
What to measure
Measurement can help, provided we resist inventing a universal velocity score.
“Stop Measuring Motion” argues for connecting engineering activity to meaningful outcomes. The next step is to connect those outcomes to the constraints affecting their delivery.
For a particular workstream, I would track:
| Measure | What it helps establish |
|---|---|
| Progress toward the intended outcome | Whether the work is helping |
| Elapsed time, including slow cases | How quickly and predictably work reaches delivery |
| Queue age and blocked time | Where demand exceeds available capacity |
| Rework and failures, including severity | Whether acceleration is creating downstream damage |
| Human intervention effort and reasons | Which parts still require attention, and why |
| Total cost, including retries and recovery | Whether increased speed is economically useful |
| Workload and knowledge concentration | Whether the pace depends on recurring overload or particular people |
Outcome evidence may arrive later than delivery evidence. Some benefits are difficult to isolate. We should state those limitations rather than replace them with a convenient count of artifacts.
We should also keep different work classes visible. Closing many straightforward requests does not establish that the team can handle ambiguous, consequential changes at the same rate.
An experimental path
The path toward greater velocity is then an experimental one.
First, choose an outcome and a reasonably coherent class of work. Establish the boundaries: available resources, acceptable consequences, operational responsibilities, and normal working expectations.
Second, examine the current flow. Follow real examples through decisions, execution, verification, delivery, and feedback. Include abandoned attempts and rework.
Third, find the constraint that most limits progress. Be specific. “We need better judgment” is difficult to act on. “Every compatibility decision waits for the same engineer because the requirements are undocumented” suggests an intervention.
Fourth, change that constraint and define success before evaluating the result. Faster delivery should be assessed alongside quality, cost, and workload.
Finally, repeat the observation. A successful intervention may expose the next constraint.
- 01 · ChooseAn outcome and a coherent class of workSet the boundaries: resources, acceptable consequences, operational responsibilities, and normal working expectations.
- 02 · ExamineThe current flowFollow real examples through decisions, execution, verification, delivery, and feedback, including abandoned attempts and rework.
- 03 · FindThe constraint that most limits progressBe specific enough that it suggests an intervention.
- 04 · ChangeThat constraintDefine success before evaluating. Assess faster delivery alongside quality, cost, and workload.
05 · Repeat the observationA successful intervention may expose the next constraint.
ThroughoutImprove the system before treating greater personal effort as evidence of greater capacity.
An important discipline runs through this process: improve the system before treating greater personal effort as evidence of greater capacity.
| More personal effort | A change to the system | |
|---|---|---|
| Intervention | A senior engineer works every evening to reduce review delays | Capture recurring compatibility requirements, improve independent checks, and distribute review expertise |
| Result | Delivery time improves | The improvement persists within ordinary working hours |
| What it shows | The experiment has changed the working-hours assumption | A stronger case that capacity has increased |
What the capacity is for
This brings me back to “AI-Free Fridays”.
Protected time for learning and reflection may help preserve future capability. But it should not have to justify its existence entirely through a productivity return. Human connection, enjoyment, and the experience of accomplishment matter too.
There is a real choice here.
Even after establishing that the team could sustainably deliver more, we may decide to use some of that capacity for exploration, resilience, or a less pressured working life. Those choices should be explicit.
Equally, protecting a Friday afternoon will not resolve a workflow that remains overloaded for the rest of the week. The commitments and the available capacity must agree.
The leadership task is to understand what constrains progress, which constraints are worth changing, and what the organization wants to do with the capacity it gains.
That leaves me with a more useful question than “How much faster can this team go?”
What would have to change for this team to achieve more, reliably, without depending on increasing strain?
Sometimes the answer will be a better model or a more autonomous workflow. Sometimes it will be clearer authority, a smaller scope, stronger verification, or fewer simultaneous commitments.
And sometimes the team already has enough capacity for what matters. The next decision is whether we can allow that to be enough.