Can an engineering team audit find the real bottleneck?

Reducing headcount before measuring the flow of work is an expensive guess. A team can look underused while its engineers are waiting for reviews, clarifications, environments, or a founder's approval. It can also look overwhelmed while carrying more people than the product needs. Those conditions create similar calendar symptoms and require opposite decisions.

A fixed fee audit can separate them if it measures elapsed time, queue age, rework, and usable capacity at the level of individual work items. It cannot do that from payroll, story points, commit counts, or interviews alone. My Team & AI Audit costs $5,000, runs for five business days, and is free if it does not identify at least $50,000 a year in savings. The fee matters less than the method: the scope must force a decision, not produce a long presentation that postpones one.

The output should tell a founder which constraint to remove first, what evidence supports that choice, and when to reconsider staffing. If the audit cannot distinguish a person who lacks work from a person blocked behind a queue, it has measured the wrong thing.

Headcount and congestion leave different evidence

Excess staffing creates persistent spare capacity after dependencies and service duties are accounted for. Congestion creates work that is available but cannot advance because a scarce reviewer, decision maker, test environment, or release window controls the pace. Both can produce low visible output per engineer, so output per person does not settle the question.

Imagine six engineers with twelve pull requests open. Four engineers start new work because two senior reviewers have no time to clear the queue. A dashboard shows many active tasks and poor completion. A payroll view shows six salaries against a weak release rate. Cutting two of the four authors may shrink the queue temporarily, but it leaves the review constraint intact. When AI produces changes faster, the queue returns with fewer people available to diagnose failures.

Now change one fact. Reviews usually start within hours, production access is available, and the product backlog has only two economically justified items. Engineers invent internal cleanup projects because no customer problem is ready for delivery. That is unused capacity. Improving review speed would make idle time arrive sooner. The founder must reduce recurring demand, add worthwhile demand, or change team size.

The distinction depends on whether executable work exists at the point where a person waits. An engineer has unused capacity when that person could take approved, dependency free work but none exists. An engineer is blocked when approved work exists and an external condition prevents progress. An engineer who is handling incidents, customer questions, maintenance, or mentoring is neither idle nor necessarily contributing to feature flow. The audit has to classify that time rather than erase it.

This is where utilization reports mislead. A person can remain busy by opening another branch while the first waits. Local utilization rises, work in progress grows, and customer delivery slows. The Theory of Constraints has made this point for decades: maximizing every resource does not maximize the system. I agree with the diagnosis, but a software audit still needs item level timestamps to find the actual constraint. A workshop full of sticky notes cannot prove how long work waited last Tuesday.

Measure work as elapsed time, not activity

The audit should reconstruct the life of each completed and unfinished work item across a representative window. Four to six weeks is usually enough to expose a recurring queue in a stable team. Use a longer window when releases are monthly, demand is seasonal, or a migration has distorted normal work. The audit itself can take five days because it analyzes existing history; it does not need to observe the team for five new weeks.

DORA's lead time for changes follows a change from commit to production. That metric is useful because customers receive nothing while code sits between those points. It is too broad for this decision by itself. A twelve day lead time could contain ten days of review waiting, ten days of failed testing, or ten days when nobody considered the change urgent. Staffing choices differ in each case.

Build an event ledger with one row per state change. Pull request history, issue history, deployment records, incident schedules, and calendars usually contain enough evidence. If the tools are inconsistent, sample twenty to forty work items and reconcile them manually. Precision to the minute is unnecessary; consistent definitions matter more.

item_id,event_at,event_type,actor,source
PAY-184,2026-06-03T09:14:00Z,ready_for_review,engineer,git
PAY-184,2026-06-05T15:42:00Z,review_started,reviewer,git
PAY-184,2026-06-05T17:10:00Z,changes_requested,reviewer,git
PAY-184,2026-06-06T11:25:00Z,review_resubmitted,engineer,git
PAY-184,2026-06-07T16:03:00Z,deployed,release,ci

Derive the intervals instead of trusting labels such as "in progress." For each item, calculate active authoring time, wait for first review, review duration, time to respond, wait for retest, wait for deployment, and total elapsed time. For unfinished items, calculate current age in each state. Averages hide old work, so report the median, the 85th percentile, and the oldest few items. A small sample does not support impressive statistical claims, but it can still reveal that every urgent change waits for the same person.

Commit counts, lines changed, tickets closed, and story points are activity measures. They vary with task size, repository habits, and how teams split work. They are easy to increase without improving delivery. Use them only to locate records or understand mix, never to rank engineers. An audit tied to layoffs will corrupt any metric that employees think scores individuals.

Review queues expose the constraint

A review bottleneck exists when ready work arrives faster than qualified reviewers can clear it for a sustained period. The visible queue is not just the count of open pull requests. It includes work waiting for architecture decisions, security approval, product acceptance, test results, and release authority. Each queue needs its own entry condition and exit condition.

Measure four properties for every review stage: arrival rate, completion rate, queue length, and age. Arrival rate says how many items become ready per working day. Completion rate says how many leave the stage. Queue length shows accumulated inventory. Age shows whether the inventory is fresh or decaying. If arrivals average five items a day and reviewers finish four, the count will rise even when everyone works hard.

Little's Law relates average work in progress to throughput and average time in the system: WIP = throughput x flow time. It is a relationship, not a management target. If a review queue averages eight items and completes two per day, its implied average wait and service interval is about four working days. Adding another author increases arrivals. Increasing review capacity or reducing review demand changes the constraint.

Age distribution is more useful than a single queue count. Ten small pull requests opened this morning may be healthy. Three changes waiting nine days for one architect may stop a release. Record the oldest item, the median age, the share that exceeds the team's expected response time, and how often an item is bypassed by newer work. Frequent bypassing means priorities are unclear or reviewers prefer easy changes.

Reviewer occupancy also needs care. A reviewer with six hours of meetings and two hours of incident duty does not have an eight hour review budget. Estimate available review time after fixed obligations, then compare it with demand. Sample review minutes by change class rather than pretending every change costs the same. A dependency update, a generated data migration, and a new authorization path carry different risk.

Do not recommend universal same day review as a cure. The promise sounds disciplined, which makes it popular, but it can move interruption cost onto the scarcest engineers. Set response expectations by risk and urgency, reserve review blocks, and define who can approve each class. The aim is predictable flow, not instant attention to every request.

AI changes the arrival rate, not the review budget

AI coding tools often increase the volume and size of proposed changes before a team changes its review design. Authors can produce a plausible implementation, tests, and documentation in one session. Reviewers still need to understand behavior, trust boundaries, failure modes, and operational impact. Faster generation therefore raises arrival rate without automatically raising safe completion rate.

This creates a familiar failure. A founder sees engineers finish drafts quickly and assumes the team has spare capacity. The pull request list grows. Senior engineers spend their day switching among generated changes, correcting assumptions, and asking for smaller submissions. Authors wait, start new branches, and later resolve conflicts. Payroll appears high relative to releases even though the scarce resource is informed approval.

Count AI generated work by review burden, not by the tool that produced it. The important attributes are change size, novelty, test evidence, reversibility, and affected boundary. A handwritten change to payment authorization may demand more review than a generated internal report. A large generated refactor can be hard to verify even when every line looks reasonable.

Set a work in progress limit before adding more generation. When the review queue reaches that limit, authors should help reduce it: split changes, reproduce failures, add missing tests, improve rollback instructions, or pair with a reviewer. This is not an argument for keeping every employee. It is a way to test whether the team can convert existing author capacity into review relief.

AI also changes the skills map. Some engineers can supervise agents, frame tasks, and verify output across several components. Others generate code quickly but depend on one senior person to catch design errors. The audit should map who can author, who can approve, which domains require named expertise, and where one person's absence stops delivery. Headcount is a poor proxy for this distribution.

A short experiment can confirm the constraint. Freeze new low priority work for three days, assign qualified authors to queue reduction, and preserve urgent support coverage. If queue age falls sharply and blocked items reach production, review design was limiting flow. If reviewers run out of work while authors still lack worthwhile tasks, capacity exceeds current demand. Do not run this during an incident or a release freeze, because the result will describe the exception.

Rework must be traced to its source

Rework supports a staffing decision only when the audit identifies why work returned. Treating every revision as waste punishes normal review and hides avoidable failure. A reviewer asking for a clearer variable name is different from discovering that the change solves the wrong customer problem.

Classify each material return to the author by cause. Useful categories include misunderstood requirements, missing acceptance criteria, design conflict, implementation defect, missing test evidence, environment failure, generated output that nobody verified, and changed priority. Keep the list stable during the sample, and allow one primary cause plus one contributing cause. If every item receives three causes, the classification will explain nothing.

Rework rate should use items, not comment count. Review styles vary too much for comments to be comparable. Report the share of items that required a material change after they were declared ready, the elapsed time added, and the stage where the cause entered. A defect found in review may have entered during a vague product decision days earlier.

Trace two or three expensive items end to end. One typical pattern starts with a founder giving a broad request in chat. An engineer asks an agent to implement it, opens a large change, and waits two days for the only domain reviewer. The reviewer finds an unstated data retention constraint. The author rewrites the storage path, tests fail in a shared environment, and the release misses its window. Labeling this "slow engineering" would lead directly to the wrong cut. The first failure was an unmade product decision; the second was concentrated review authority.

Another pattern points toward excess staffing. Requirements are clear, reviews are prompt, failure rates are low, and engineers still spend much of the week polishing low impact internal tools because the company has not validated enough product demand. That work may be competent. It is still not a reason to keep a team sized for a larger roadmap.

Never turn rework categories into individual performance scores. People will stop declaring work ready, move disagreement into private messages, or split revisions to improve the number. Use the categories to change intake, ownership, review boundaries, and tests. Handle performance concerns with direct evidence and management, outside the flow dataset.

Unused capacity needs a precise definition

Unused capacity is time that could have advanced approved work but did not because the team had no such work available. It is not all time outside feature coding. Operations, incident response, customer support, security maintenance, planning, and mentoring consume capacity that the company has chosen to fund.

Start with paid capacity and subtract nonproject obligations that the business actually requires. On call recovery time, recurring support, scheduled leave, and mandatory meetings belong in the calculation. Then identify time spent blocked, time spent on approved delivery, avoidable rework, and discretionary work. The remainder may be unused, but interview the engineer and inspect nearby records before assigning the label.

A simple weekly model is enough:

usable capacity = paid time - leave - required service work - fixed obligations
flow demand = approved delivery + necessary rework
blocked capacity = time available for flow but stopped by a dependency
unused capacity = usable capacity - flow demand - blocked capacity

These are management estimates, not payroll accounting. Do not manufacture decimal precision from calendars. Use ranges and document assumptions. If support work varies from four to ten hours a week, test the staffing decision at both ends. A recommendation that changes when one estimate moves by an hour is too fragile.

Capacity also needs a skills constraint. Forty free hours from a mobile engineer cannot automatically replace forty overloaded hours in database review. Build a small matrix of domains against people: can author independently, can review, can respond in production, or needs supervision. The matrix will show whether apparent spare capacity is usable where the queue exists.

Founders often ask for a utilization target. I do not recommend one. Software teams need some slack for incidents, learning, and uneven arrivals. A target near full utilization guarantees queues whenever demand varies. Decide how much response capacity the business needs, then price that choice openly. Slack can be rational; invisible slack cannot.

A five day audit can produce a defensible decision

A five business day audit can reach a staffing recommendation when access, scope, and definitions are settled before the clock starts. It should analyze a bounded team, one delivery flow, and a representative history. It should not promise a company wide operating redesign in the same fee.

The sequence I use is deliberately compact:

1. On day one, define the decision, work item boundaries, economic priorities, and required service duties with the founder and engineering lead.
2. On day two, export issue, review, deployment, incident, and calendar events, then build the event ledger and flag missing records.
3. On day three, calculate elapsed intervals, queue ages, rework causes, and capacity ranges, then test findings in short engineer interviews.
4. On day four, run a constraint review with the people who do the work and model the smallest credible interventions.
5. On day five, deliver the evidence, recommendation, savings range, risks, owners, and a date for checking the result.

Interviews come after an initial data pass so the auditor can ask about specific gaps. "Why did PAY-184 wait from Tuesday to Thursday?" produces better evidence than "What slows the team down?" The answer may expose an off system approval or show that the timestamp has a harmless explanation.

The audit package should include the event definitions, source coverage, exclusions, item level evidence, queue and age distributions, rework classification, capacity ranges, skills constraints, and decision model. It should also state what the data cannot prove. If half the work happens in private chat and no deployment records exist, the recommendation needs a lower confidence label and a measurement repair.

Privacy matters because the audit touches employee activity. Collect the minimum fields required for flow, restrict raw access, and separate system findings from performance management. Do not capture message content when a timestamp and event type will answer the question. Tell the team what will be analyzed, how long raw exports will be retained, and who sees individual records.

Missing instrumentation does not make the audit useless, but it changes the claim it can support. Reconstruct a sample from repository events, deployment logs, calendar blocks, and short interviews, then mark every inferred timestamp. If a reviewer says approval happened in chat, ask for the date and outcome rather than the conversation. Compare two independent sources where possible. The result may support a reversible review experiment while falling short of a staffing cut. In that case, install a simple state convention for the next delivery cycle and postpone the irreversible choice. A founder who insists that weak records must still produce a precise headcount number is asking the auditor to disguise uncertainty. The honest output is a bounded finding, the missing evidence, and the cheapest way to obtain it.

A fixed fee helps when it buys a fixed decision scope. It hurts when the auditor cuts sampling, skips validation, or forces certainty to protect margin. The founder should ask what evidence will change the recommendation, what exclusions are planned, and what happens when source data conflicts. A credible auditor can answer those questions before access begins.

Choose the intervention from the constraint

The first intervention should address the measured constraint, then give the team enough time to show whether flow changes. Combining layoffs, process changes, a new AI tool, and a reorganization destroys the comparison. The company may save money, but it will not know which assumption was correct.

Connect each observed pattern to one action and one checkpoint. When review arrivals exceed completions and queue age rises, add qualified review time, reduce batch size, and clarify approval classes. Recheck age and throughput after two normal delivery cycles. Do not call the intervention successful because the open count fell on a quiet Friday.

When rework starts with unclear product decisions, tighten acceptance decisions before authoring. Recheck material returns and elapsed time. When work waits on one domain expert, transfer review authority and pair on that domain, then recheck bypasses and the expert's queue age.

When approved demand stays below usable capacity while review queues remain healthy, remove low value work, combine roles, or reduce headcount. Recheck service coverage and roadmap delivery after the change. When service duties consume the apparent spare time, fund that coverage explicitly or reduce the obligation, then compare incidents, support response, and planned delivery. The checkpoint must measure the cost that the first recommendation could move elsewhere.

When evidence supports excess staffing, say so plainly. Identify the roles or capacity bands the remaining demand does not require, preserve production and review coverage, and calculate savings with transition costs included. Do not name individuals from a weak activity ranking. Team design comes first; managers then make employment decisions with broader performance and legal context.

When evidence supports a review constraint, set a correction with an owner and an expiry date. Examples include delegated approval for low risk changes, protected review blocks, smaller change limits, clearer acceptance criteria, or cross training in one domain. Measure whether queue age, completed throughput, and rework improve. If they do not, the audit's causal claim was wrong or the intervention was not implemented.

Sometimes both findings are true. A team can have excess author capacity and a shortage of qualified review capacity. The answer may be fewer generalist author hours plus deliberate transfer of review knowledge, not an across the board percentage cut. Sequence the knowledge transfer before removing the people who hold it.

Savings should follow the intervention, not lead it. Calculate annual payroll removed, contractor or leadership cost added, transition time, expected delay, and operational coverage. A large gross saving can disappear when the company must hire an expensive specialist three months later. Show a range and the assumptions that move it.

Keep the decision honest after the audit

The audit ends with a testable recommendation, not a permanent verdict on the team. Demand changes, people learn, and AI tools alter arrival patterns. Keep the same event definitions for the checkpoint so the before and after comparison means something.

Choose a small set of measures tied to the diagnosis. For a review constraint, track queue age by class, completion rate, material rework, and blocked author time. For excess capacity, track approved demand, necessary service coverage, delivery throughput, and whether discretionary work returns. Do not turn the checkpoint into a broad executive dashboard.

Set guardrails before acting. A staffing reduction must preserve named production response and approval coverage. A review redesign must not lower the evidence required for risky changes. An AI expansion must include who verifies generated work and what happens when the verifier rejects it. Speed without an accountable approval path just moves risk closer to production.

Watch for metric gaming. If teams split pull requests merely to improve size, inspect total change scope. If they delay marking work ready, compare commits and state changes. If reviewers approve quickly and defects move to production, include rollback and incident evidence. A useful measure should become harder to fake when paired with its consequence.

The founder owns the economic choice. An auditor can show that demand supports four engineering roles, that two more roles cover an optional response promise, and that a review queue costs a week of delivery. The founder must decide what response promise and roadmap to buy. Pretending the dataset makes that value judgment only hides it.

Do not cut because people look quiet in a queue, and do not preserve every role because the queue looks busy. Measure where approved work waits, why it returns, and which capacity can actually remove the constraint. Then make one change, keep the definitions stable, and check whether the system behaves as predicted.