Redesign the Work Before You Reduce the Team

Imagine AI coding assistants rolling out and an individual output measure rising—more PRs, faster first drafts, shorter time-to-first-implementation. In the next budget cycle, someone asks: if people are this much faster, why do we still need this many of them?

That question skips a step. Individual output and team throughput are different measures, connected by a workflow whose other stages may or may not have improved. A staffing decision based on the first measure alone could remove capacity needed for review, coordination, operations, or redesign. The practical question is whether the gain survives the full path from idea to a useful, reliable product.

AI Is an Amplifier, Not a Fix

DORA's 2025 State of AI-assisted Software Development report describes AI as an amplifier, "magnifying an organization's existing strengths and weaknesses." DORA also found that AI adoption had a positive relationship with software delivery throughput and product performance, while continuing to have a negative relationship with delivery stability. These are associations across surveyed technology professionals, not estimates of how many people a particular team needs. Read against a headcount decision, the findings suggest checking whether faster drafting improves the full workflow without weakening its safety nets. A slow approval chain might remain the constraint even when the work entering it arrives faster.

This isn't an argument that AI-era teams can never be smaller. It's narrower: a local productivity number cannot, by itself, establish the capacity of the whole system. The measurement problem is related to the one described here at the individual level: output volume can become a less reliable proxy for value. At the organizational level, the question is whether faster work also reaches users, performs well, and remains safe to operate.

One Approval Chain, Cut Two Ways

Take a concrete, illustrative case: a company adding a new regional payment processor. Suppose AI assistance reduces the engineering integration—API client, webhook handling, reconciliation logic—from two weeks to three days. Shipping may still require legal sign-off on data residency terms, a security review of the PCI scope, and finance sign-off on reconciliation impact. Those steps could remain the constraint even after drafting gets faster. The time saving here is hypothetical, not an estimate from DORA.

If the team cuts engineering capacity based only on the faster integration draft, it risks leaving less time to prepare legal's compliance mapping, answer security's scoping questions, and coordinate finance's sign-off alongside other projects. Whether the launch actually slows depends on workload and spare capacity in each step; the faster draft alone cannot settle that question.

Map the full path first, including time spent waiting at each handoff. If routine approval is a measured constraint, an accountable owner can work with legal, security, and finance to define which previously approved cases may pass documented, automated checks. The responsible reviewers must approve those rules and retain a clear route for novel risk—such as a new jurisdiction or untested processor—to receive full review. This is one possible redesign, not a finding that DORA tested for payment processors. DORA's value stream guidance starts with finding the actual constraint and testing an improvement against a chosen outcome.

What "Redesign the Work" Actually Requires

"Redesign the workflow" is vague unless the team can identify a constraint and show that a change improved it. Start with the full value stream, then choose an intervention:

• Map the work. Follow a representative change from idea to customer outcome. Record active time, waiting time, rework, and who owns each handoff. Check where work actually accumulates before choosing what to automate.
• Explicit ownership. Name a person accountable for the outcome and for resolving cross-team handoffs. Make the work and its queue visible so coordination load can be measured.
• Automated checks where approved. If routine checks are a real constraint, let the responsible legal, security, or finance owners define cases that a policy gate, registry, or contract test can safely clear. Retain the evidence and oversight those owners require.
• Explicit exception criteria. Define the conditions that still require human review, such as a new jurisdiction, data category, or spending threshold. Measure whether the new route improves flow and preserves quality.

Individual engineer output can help identify where AI changed the work, but it cannot substitute for these workflow measures. A team can test a redesign before changing headcount and then assess how much capacity the observed process requires.

Three Paths From the Same Productivity Number

Once an individual productivity number shows up on a dashboard, leadership could respond in several ways. These three paths illustrate the decision; DORA did not compare them as staffing strategies:

1. Cut immediately, assuming AI will absorb the work. An individual output chart does not establish that assumption. DORA's findings make it reasonable to check the full delivery system, including stability, before treating local productivity as staffing capacity. They do not directly measure the effects of a headcount cut.
2. Measure and improve the workflow, then size the team against observed demand. Map the value stream, address its constraint, and compare delivery, quality, and workload measures before making a staffing forecast. Automation may be useful if the measured constraint calls for it.
3. Hold staffing steady while investing in the enabling system. DORA found an association between high-quality internal platforms and an organization's ability to realize AI's value; it also reported that 90% of surveyed organizations had adopted at least one platform. Adoption alone says nothing about a platform's quality, and a productivity gain is not automatically a budget saving. Fund the work from demonstrated capacity or budget savings where they exist.

Paths two and three can reinforce each other. An immediate cut may leave less capacity to investigate bottlenecks and build improvements, especially if the remaining team already carries a full workload. That is a risk to assess locally, not an outcome established by DORA's survey.

Where This Breaks

The redesign-first path has a real cost: it delays a decision leadership may be under pressure to make quickly. Set a timebox and success criteria appropriate to the workflow before starting. For example, a team might spend one quarter assigning ownership and testing a targeted change, then compare end-to-end time, queue length, rework, product outcomes, and workload against its baseline. One quarter is an illustrative management choice, not a DORA threshold.

A Decision Rule Before Any Cut

Three questions, asked before a staffing number is finalized rather than after:

1. Does the productivity number describe individual activity, software delivery throughput, or value delivered to users? Which stages and outcomes does it miss?
2. Where is the measured constraint in the path from idea to delivery? Have changes to ownership, review, testing, or automation improved that constraint without raising instability or rework?
3. What workload and skills will the team need after the proposed change? Set thresholds in advance for delivery time, review queues, product quality, incidents, and sustainable on-call load, and specify what action each threshold will trigger.

The staffing recommendation here is a hypothesis to test locally, not a result DORA established. Compare the workflow before and after an improvement using measures that fit the decision: end-to-end time and waiting, delivery throughput and instability, rework, user outcomes, and team well-being. A comparable workflow with the same AI tooling may provide useful context, though differences in demand and work mix must be considered. DORA's measurement guidance recommends choosing a framework for the goal, establishing a baseline, making a change, and checking its effects. Only then can an individual productivity gain contribute meaningfully to a staffing decision.