In The Maximum Velocity of a Team, I explored sustainable progress within explicit limits on cost, risk, and workload. I also separated the capacity a team has from the pace it chooses to commit to.
Now suppose several teams make those improvements. They understand their scope, verify their work reliably, and operate at a sustainable pace.
Does the company become faster?
It might. But something changes when we move up a level: teams pursue different outcomes, compete for shared resources, and make decisions whose consequences extend beyond their authority.
A company can have excellent people, productive teams, ambitious goals, and increasingly powerful AI tools, and still take months to move something important forward.
Engineering is shipping. Product is planning. Sales is selling. Every function has evidence that it is working hard.
Yet the customer is still waiting.
The feature is finished, but the commercial model is unresolved. The contract is ready, but implementation depends on a platform migration. The launch is approved, but nobody has prepared support. The strategy is clear to the executive team, but three departments have interpreted it differently.
Each part is moving. The company is struggling to make progress.
That raises a different question from how fast an individual or a team can work:
What determines the maximum velocity of the organization itself?
What are we trying to maximize?
At company scale, I would extend the definition: the highest sustainable rate of progress toward a chosen set of strategic outcomes, within explicit limits on investment, risk, and workload, over a stated time horizon.
That definition carries several conditions.
| Condition | Why it matters |
|---|---|
| The work needs a direction | Shipping more things does not help if they pull the business toward incompatible goals. |
| The result needs to matter | An internal milestone is useful evidence of progress, but it is not automatically a customer or business outcome. |
| The company needs feedback | A launch without learning leaves us uncertain whether we advanced or simply became busier. |
| The pace needs to hold | A quarter of exceptional output funded by exhaustion, unresolved defects, and deferred maintenance tells us little about sustainable capacity. |
There is no universal unit that makes a security improvement, a market expansion, and a better onboarding experience directly comparable. I would not try to manufacture one by adding up team velocity scores.
The useful question is whether the organization is becoming better at selecting important outcomes, achieving them, and learning what to do next.
The limit can live between functions
Consider a hypothetical enterprise product launch.
Engineering completes its work in ten working days. Commercial approval takes another fifteen. Operational preparation and customer onboarding take five more. Assume those stages happen sequentially.
The customer receives value after thirty working days.
Now AI helps engineering finish in five days. That is a substantial improvement for the team. The customer’s wait falls to twenty-five days: a five-day reduction, or about 17%.
| Sequential stage | Working days | With AI in engineering |
|---|---|---|
| Engineering | 10 | 5 |
| Commercial approval | 15 | 15 |
| Operational preparation and customer onboarding | 5 | 5 |
| Customer receives value after | 30 | 25 (about 17% less) |
The gain is real. It is also smaller than the engineering improvement suggests.
If the company can resolve commercial questions during development, give an accountable owner authority within agreed limits, and prepare onboarding earlier, it may remove more elapsed time than another round of coding optimization.
Those changes require judgment. Some reviews need completed evidence. Some decisions should remain independent. The point is to examine the sequence rather than assume every existing wait is necessary.
Companies often ask each function to improve its own performance before understanding the path the customer actually experiences.
That can produce impressive local results while leaving the main constraint untouched.
A company has several paths to value
That launch example follows one sequential path. A company usually has many paths operating at once.
One product may be constrained by demand, another by implementation capacity, and a third by a difficult migration. A shared identity service may affect all three, while an unrelated cost-reduction project can proceed independently.
Calling the company only as fast as its slowest team would obscure this structure. A slow step matters according to which outcomes depend on it, how strongly they depend on it, and what alternatives exist.
This makes organizational velocity a portfolio problem. Leaders must decide which outcomes deserve scarce capacity and which dependencies are worth changing.
Consider two proposals: accelerate an already independent team, or fund an unglamorous platform change that allows four teams to deliver without coordinating every release. The second may create more organizational capacity even if it produces fewer immediately visible features.
Equally, a shared platform can become a new queue if every small change requires its owners’ involvement. Reuse has a coordination cost. The investment should be evaluated against the dependencies it removes and the obligations it creates.
The useful map connects important outcomes to the teams, decisions, and shared capabilities required to achieve them. An organization chart alone cannot show those relationships.
Strategy sets the amount of competition inside the company
An organization can agree on its priorities and still have too many of them.
Five strategic initiatives may all need the same platform team, security reviewers, senior architects, or executive attention. Each initiative has a reasonable plan. Together, those plans demand capacity that does not exist.
The resulting delays can look like execution problems. Teams escalate. Leaders ask for tighter accountability. People spend more time explaining why the dates moved.
But the conflict began when the company committed the same capacity several times.
Strategy becomes operational when leaders decide what gets access to scarce resources, and what must wait.
A new priority should come with an explicit consequence for existing commitments. Otherwise, reprioritization simply adds another demand to the queue.
Finishing fewer initiatives at a time can improve company velocity when it reduces contention and gets useful outcomes into customers’ hands earlier. That is a hypothesis to test against actual completion and impact, not a reason to reject every parallel effort.
There is also a distinction between an engineering organization and the company around it.
| An engineering leader may change | They may need a broader decision to change |
|---|---|
| Service ownership | A customer promise |
| Release dependencies | Commercial policy |
| Technical investment | Product portfolio |
Improving velocity requires locating the level that can authorize the change. Escalation should carry a concrete tradeoff to that level.
Autonomy depends on what teams can do independently
Delegating decisions will not create much autonomy if every meaningful change still requires five teams to act together.
The technical and organizational boundaries need to support the authority people receive. That can mean stable interfaces, compatibility guarantees, independently deployable components, or a complete product slice owned across functions.
It can also mean accepting limited duplication when the cost of sharing exceeds the benefit. Standardization is valuable where it reduces repeated effort or material risk. Applied indiscriminately, it can make unrelated work compete for the same approval path.
I would ask where coordination is repeatedly necessary and whether the reason can be removed. A recurring meeting may be useful while a dependency exists. Changing the dependency may create a larger gain than making the meeting more efficient.
Some coupling is inherent. Financial reporting, security boundaries, and customer commitments can require company-wide consistency. Those shared constraints need clear interfaces and owners so that teams can work independently everywhere else.
Decision architecture is part of operating capacity
Every company has a practical decision architecture, whether it has designed one deliberately or not.
Who can commit resources? Who can accept a tradeoff? Which decisions need consultation? Who resolves a disagreement between functions? When does a decision become final enough for people to proceed?
If those answers are unclear, even capable teams can spend days seeking permission or reconstructing an agreement.
For each important cross-functional initiative, I want an accountable outcome owner, clear decision boundaries, and a way to resolve conflicts promptly. That owner needs a route to real authority; a name beside a milestone is insufficient.
Reversible decisions can often be made close to the work within explicit limits. Decisions involving substantial exposure, lasting commitments, or difficult recovery deserve more scrutiny.
The company should make that distinction in advance. Requiring every decision to find its own approval path consumes attention repeatedly.
The same applies to context. Delegation works better when people understand the objective, the constraints, and the reasoning behind them. Without that shared understanding, autonomy can generate conflicting choices; with excessive approval, it can disappear entirely.
Incentives decide whether teams help the whole
A shared objective does little if each function is rewarded for behavior that makes it harder to achieve.
| Function | What it can do |
|---|---|
| Sales | Make commitments that delivery cannot support |
| Engineering | Declare success at release while adoption remains unresolved |
| A platform team | Protect its own roadmap while several customer outcomes wait for a small enabling change |
These are possible consequences of reasonable local incentives.
Leaders need to make contributions to the wider outcome visible: preventing an unserviceable commitment, helping another team finish, simplifying a dependency, or stopping work after evidence invalidates its premise.
That does not mean giving everyone an identical scorecard. Functions have distinct responsibilities, and some checks need independence. It means evaluating local performance alongside its effect on the company’s ability to deliver.
Sometimes the highest-value contribution is helping another part of the organization move.
The speed of changing direction
A company also needs to respond when its original plan stops making sense.
Suppose an experiment shows that a planned feature will not solve the customer’s problem. The team learns this in a week. Funding, staffing, and annual objectives still assume the original project will continue for six months.
The learning loop is fast. The resource-allocation loop is slow.
Company velocity includes the ability to act on evidence: stop an investment, narrow a commitment, redirect funding, or give a promising experiment enough capacity to become a real offering.
This deserves care. Constantly moving people between projects destroys continuity and incurs real learning costs. A weak signal should not overturn every commitment. Leaders need criteria for reconsidering an investment, an owner who can make that decision, and an explicit account of transition costs.
But preserving a plan merely because its resources were already assigned has a cost too. The company can continue executing efficiently after the reason for the work has disappeared.
I would track the time between accepting consequential evidence and changing the relevant commitment. That interval can reveal a limit that delivery metrics never capture.
AI makes the company-level question more urgent
AI can reduce the effort needed to produce code, analysis, proposals, and prototypes. Each improvement creates an opportunity to change how the organization operates.
It can also increase the amount of work arriving at steps whose capacity has barely changed.
More proposals still need choices. More code needs appropriate verification. More launches require customer attention, support, and adoption. Faster production can expose a constraint that was previously hidden by slower upstream work.
In Path to the Dark Factory, I explore the progression toward more autonomous software delivery. The company-level implication is broader: improving the software factory creates pressure to improve the decisions and business processes around it.
I would evaluate an AI investment with two questions: which activity becomes easier, and what customer outcome becomes achievable sooner as a result?
Sometimes the immediate gain is lower effort rather than shorter elapsed time. That still has value. We should describe it accurately and decide deliberately how to use the capacity it creates.
Measure the journey
I would use a small set of measures around a few important outcomes rather than invent a single organizational velocity score.
| Measure | What it helps reveal |
|---|---|
| Elapsed time from commitment to customer use | Whether the complete delivery path is improving |
| Time waiting, grouped by cause | Where decisions, dependencies, and capacity hold up progress |
| Active initiatives using the same scarce resources | Whether commitments exceed practical capacity |
| Dependencies requiring coordinated delivery | Where team independence is limited and enabling investment may help |
| Time to resolve consequential decisions | Whether authority and escalation paths work |
| Time from accepted evidence to a changed investment decision | Whether learning can actually redirect the company |
| Customer adoption and time to useful feedback | Whether delivery becomes value and learning |
| Rework, reliability, support burden, and sustained overtime | Whether apparent speed creates costs elsewhere or later |
Keep the starting and finishing points explicit. Group comparable work. Look at unusually long waits as well as typical ones.
Also inspect the time before formal commitment. A metric can improve cosmetically if work waits longer before entering the measured process.
The purpose is to locate an intervention and understand its effect. Once a measure becomes a target detached from the outcome, people can improve the number while the customer continues to wait.
Raising the ceiling
I would begin with one important outcome that recently took longer than expected.
Reconstruct its actual journey across functions. Include the abandoned approaches, approval waits, conflicting commitments, and work that had to be repeated. Ask the people doing the work where time went. Then inspect the other initiatives drawing on the same scarce capacity; the explanation may sit outside the project being reviewed.
Then choose the constraint that most plausibly limited progress. Change something concrete: sequence fewer initiatives, delegate a bounded decision, prepare downstream work earlier, clarify ownership, or invest in the missing capability.
Observe whether the next comparable outcome reaches customers sooner without worsening quality, risk, or workload. Check the other affected initiatives too. One program finishing sooner because it took everyone else’s reviewers may be a justified priority decision, but it does not establish an increase in overall capacity.
Look for evidence of a structural improvement: fewer synchronized releases, less waiting across several initiatives, decisions that no longer need repeated escalation, or resources redirected sooner after new evidence. If the improvement holds, investigate the next limit. If it does not, revise the explanation.
- Abandoned approaches
- Approval waits
- Conflicting commitments
- Work that had to be repeated
- Sequence fewer initiatives
- Delegate a bounded decision
- Prepare downstream work earlier
- Clarify ownership
- Invest in the missing capability
- If the improvement holdsInvestigate the next limit.
- If it does notRevise the explanation.
Some improvements require deeper changes to architecture, staffing, or organization design. Evidence from real delivery paths makes those investments easier to justify than a general instruction to move faster.
The ceiling is changeable. Raising it requires changes to the conditions under which people work.
Maximum is a capability, not a permanent demand
Even after raising that ceiling, leadership still has a choice about the operating pace.
A company needs room for incidents, unexpected opportunities, learning, and recovery. Committing all available capacity in advance makes every surprise compete with a promise already made.
There is a human dimension too. In AI-Free Fridays, I argued for protecting thinking, connection, and time to appreciate an accomplishment. Those choices belong in the operating model. They cannot depend on everyone finishing an endless backlog first.
People deserve space to develop judgment, build relationships, and enjoy what they have achieved. Their worth does not depend on turning every saved hour into another deliverable.
Greater capability gives a company options: deliver sooner, improve quality, explore a new direction, reduce pressure, or combine those benefits. Choosing among them is part of leadership.
The team-level question asks what would let a group make more sustainable progress. The company-level question adds responsibility for choosing among those groups’ goals, designing their dependencies, and changing the commitments that individual teams cannot change for themselves.
That is work the leadership system has to do. Asking every team to become faster cannot substitute for it.
The question I would bring to the next leadership meeting is simple:
If our teams became twice as productive tomorrow, what would still keep our customers waiting?
Start there.