AI leadership when pull requests outpace releases

More pull requests with the same release rate are evidence of congestion, not productivity. Coding tools have increased the rate at which engineers can propose changes, but they have not made product decisions, reviews, test environments, migrations, approvals, or releases equally fast. An SMB that counts generated code or opened pull requests can congratulate itself while customers receive nothing sooner.

That gap does not automatically mean the company needs an outside leader. It means the company needs to trace delivery as a system, find where changes wait, and decide whether its current leaders can remove the constraint. Outside AI leadership is justified when the evidence shows a cross-team delivery problem, internal ownership is missing, or repeated local fixes have shifted the queue without improving releases.

Pull request growth can hide falling delivery

A pull request is inventory entering a review and release system. A release is value that reached a customer or an internal user. Treating those events as interchangeable creates the same mistake a factory would make if it counted parts arriving at an assembly station as finished products leaving the building.

AI coding tools change the arrival rate first. An engineer can explore an unfamiliar repository, draft tests, refactor repetitive code, or produce a first implementation faster. That is useful. It also means the review queue receives more changes, sometimes with broader diffs and weaker author understanding. The next person must still decide whether the change belongs, whether it handles the awkward cases, and whether the team can operate it in production.

The 2025 DORA report on generative AI in software development found this split in its own data. Greater AI adoption was associated with better reported productivity, flow, code quality, documentation quality, review speed, and approval speed. Yet the report estimated a small negative effect on delivery throughput and a larger negative effect on delivery stability. DORA's explanation focused on a basic delivery discipline that fast code generation can violate: keep batch sizes small. That qualification matters more than another claim that a coding assistant saves typing time.

For an SMB, the operational symptom is usually plain. Open pull requests rise. Median time to first review rises. Engineers spend more of the day reading changes they did not write. Work merges in bursts just before a planned release, and the release itself still waits for one person who understands the deployment, a customer migration, or a risky subsystem. The coding tool did not create every bottleneck. It increased pressure until the old bottlenecks became visible.

Do not respond by setting a pull request target. A target rewards authors for feeding the queue and punishes the people doing the scarce review and release work. If the number becomes a performance measure, engineers will split work in ways that look active without reducing customer lead time, or they will open drafts before the change is coherent. Measure how work exits the system.

One change must be traced from decision to production

You can locate the constraint by following a small sample of shipped and unshipped changes across the full path, with timestamps and named wait reasons. Repository data alone starts too late because work may sit in product clarification or design before an engineer writes code. It also ends too early when a merge requires a separate release decision.

Use these events for each change:

1. Product decision ready: acceptance conditions and owner are clear.
2. Engineering starts: someone begins active implementation.
3. Pull request opens: the first reviewable version exists.
4. Review starts and approves: a reviewer gives meaningful attention, then accepts it.
5. Change merges: required checks and branch rules pass.

Add deployment started, production verified, and customer enabled if releases have separate stages. Record both the timestamp and the reason for every wait longer than one normal working day. "Waiting" is not a reason. Write "security reviewer unavailable," "staging data broken," "founder approval," "release train," or "customer migration not rehearsed."

A small event payload gives the team a shared format without forcing a new analytics purchase:

{"change_id":"BILL-184","event":"review_started","at":"2026-07-22T14:10:00Z","owner":"platform","wait_reason":"security_reviewer_unavailable"}

Emit the events from the issue tracker, repository, deployment workflow, or a short weekly review. Imperfect manual data from 20 changes is more useful than a polished dashboard that counts only commits. The expected output is a row per change with active time, wait time, current stage, and the longest wait reason. A basic table might show that implementation took six hours while review waited three days and production enablement waited another four.

Trace failures as well as successful releases. A change that reached production and rolled back tells you where the flow was fast but unsafe. A change closed without merging may expose unclear product decisions, duplicated work, or generated code that no reviewer trusted enough to own. Excluding abandoned changes makes the delivery system look healthier than it is.

Run this trace for two to four weeks before making an organizational claim. One difficult release can be an outlier; a repeated queue at the same stage is evidence. You are not building a permanent measurement bureaucracy. You are collecting enough observations to decide where leadership attention belongs.

Each queue points to a different leadership failure

The location of the wait tells you which decision is missing. "We need faster reviews" is too vague to act on, because review delay can come from overloaded experts, oversized changes, unclear ownership, weak automated checks, or work that should never have reached implementation.

When changes wait before coding, product leadership has not made the work ready. AI can generate alternatives quickly, so ambiguous requests produce more plausible implementations of the wrong idea. Look for rewritten acceptance conditions, reopened tickets, competing pull requests, and questions that arrive after a reviewer sees the behavior. The fix is a named product decision owner and smaller slices with observable outcomes.

When changes wait for a first review, the team has a capacity or ownership problem. Count reviewers, not only authors. If six engineers can open changes but one senior engineer must approve database, security, and architecture decisions, the team has built a single server with an unbounded queue. Give domains explicit owners, reserve review capacity, and move routine policy into automated checks. Hiring another author or buying more coding seats makes this queue worse.

When review cycles repeat, inspect change size and author comprehension. AI-generated code often looks complete before the author has tested the assumptions around it. Review comments then discover product behavior, not small implementation defects. Require the author to explain the risk, test evidence, rollback path, and any generated portions they changed. If the explanation is vague, the pull request is not ready.

When merged work waits for release, repository settings are not the main issue. The business may batch changes into a weekly train, lack safe migration patterns, require a founder to approve every production event, or depend on a manual QA pass that grows with every change. Measure merge-to-production time separately. A clean review dashboard can coexist with a seven-day release delay.

When releases fail or roll back, speed is exposing a verification and operability gap. Check whether tests cover behavior rather than lines, whether staging resembles production where it matters, whether deployments can stop safely, and whether engineers can see the effect after release. Slowing all coding is a crude response. Reduce change size and make the release path capable of rejecting or reversing a bad change quickly.

Consider a billing change that adds annual-plan credits. A coding agent drafts the database column, API field, account screen, and tests in an afternoon. The author opens four pull requests across three repositories because the company measures small changes and wants parallel review. Each change looks modest on its own.

The database reviewer approves the schema but does not know that existing customers need a backfill. The API reviewer sees the new field but assumes the user interface will handle an empty value. The interface reviewer uses generated fixture data where the value always exists. All checks pass because every repository tests its own assumption. Two changes merge on Tuesday, the remaining changes wait for the only billing owner, and operations holds the Thursday release because nobody can state whether partially deployed behavior is safe.

On Friday, the team merges everything and starts the backfill manually. The job locks rows long enough to slow invoice creation, so operations stops it and rolls back the application. The dashboard records four opened pull requests, four merges, fast review on three of them, and one deployment. It does not record that the product decision lacked a migration rule, the changes could not ship independently, or the release consumed two senior engineers for most of a day.

The correct diagnosis is not "review is slow" or "AI code is risky." The team sliced the work by repository instead of by deployable behavior, and nobody owned the boundary between product state, data migration, and production verification. A useful correction defines one release owner, rehearses the backfill on representative data, adds an explicit absent-credit test across the API boundary, and ships the behavior behind a controlled enablement. The next measurement should show whether similar changes spend less time waiting and require less repair, not whether the agent produces the code again in fewer minutes.

Delivery metrics need stage boundaries and business context

Use a small set of metrics that describe movement, waiting, and failure. DORA's deployment frequency, change lead time, failed deployment recovery time, change fail rate, and deployment rework rate are a better foundation than lines of code or pull request totals because they connect engineering activity to production. An SMB still needs stage-level measures to find the constraint inside that lead time.

Track these measures weekly:

• Decision-ready to production lead time, reported as a median and an older-tail percentile.
• Time spent waiting at product, review, CI, release approval, and deployment stages.
• Work in progress at each stage, including drafts and merged but unreleased changes.
• Release frequency and the share of releases that need rollback, hotfix, or immediate repair.
• Pull request size distribution and review rounds, used as diagnostic measures rather than targets.

Do not combine them into one developer score. A person can improve one number by damaging another, and team delivery depends on shared infrastructure and decisions. A reviewer who prevents an unsafe release may appear slow in a naive dashboard. A developer who opens many generated changes may appear productive while increasing everyone else's wait time.

Segment enough to avoid blaming the wrong system. Separate routine application changes from database migrations, regulated workflows, urgent fixes, and large product bets. Compare the same service over time before comparing engineers. Note planned freezes and incidents. Context prevents a normal approval path for a high-risk migration from distorting every ordinary change.

The measurement must reach a release identifier. GitHub's documentation describes status checks as evidence that a commit meets repository conditions, and required checks can block a merge. That is useful, but a green check proves only what the check actually ran. GitHub also notes that a skipped job can report success. A green merge box cannot prove that the right tests existed, that the production deployment happened, or that customers received the feature.

A weekly delivery review should take 30 minutes, not become another ceremony. Put the oldest five changes on screen, name their current stage and owner, then examine the largest recurring wait category. Finish with one policy or capacity change and a date to inspect its effect. If the meeting turns into status recitation for every ticket, stop and return to the queue.

Fix ownership before adding more AI tools

The first intervention should reduce load on the constrained stage, not increase code generation. Many teams do the reverse because coding seats are easy to buy and an organizational decision feels uncomfortable. The result is a larger backlog of apparently finished work.

Set explicit operating limits for two weeks. Cap active changes per engineer, require a reviewer before implementation begins for risky domains, and keep pull requests small enough that a reviewer can understand them in one sitting. A limit is not a permanent law. It is a way to stop feeding the queue while the team tests whether flow improves.

Assign one owner for each boundary that currently has no owner: product-ready, review-ready, release-ready, and production-verified. The owner makes the decision or obtains it; the owner does not perform every task personally. This distinction removes the familiar failure where everyone watches a merged change wait because nobody owns the next transition.

Automate repeated judgment only after the team agrees on the rule. Required tests, formatting checks, dependency policies, migration validation, and deployment health checks can remove routine review work. GitHub's merge queue documentation says the queue tests changes against the latest target branch and changes already ahead of them. That can reduce branch update churn on a busy repository, but it cannot decide whether your test suite covers the business risk. Tool configuration should encode a policy, not substitute for one.

Change how engineers use coding agents at the source. Ask for a plan and affected boundaries before code, constrain the task to one observable behavior, and make the author review the entire diff before opening the pull request. Generated tests need the same scrutiny as generated implementation. A test that repeats the code's mistaken assumption creates confidence without protection.

I have moved an operating team from 25 people to two AI-augmented engineers while keeping output and uptime. The coding tools mattered, but the larger gains came from removing handoffs, making production ownership explicit, and building a delivery path that a small team could operate. Copying the tool list without changing those responsibilities would copy the cost and miss the result.

A capable internal leader should get the first attempt

An SMB does not need outside AI leadership when a current engineering or product leader owns the full release path, can change team policy, and has enough time to run a focused correction. Give that person a clear outcome and a short window, then judge the release system rather than the presentation.

The internal attempt should produce four things. First, a baseline from decision-ready through production, including failed and abandoned work. Second, a ranked constraint backed by timestamped examples. Third, one or two changes aimed at that constraint. Fourth, evidence after two to four weeks showing whether lead time, queue age, release frequency, or failure demand moved.

Keep the work internal when the leader can make tradeoffs across product, engineering, and operations without waiting for a founder to arbitrate every disagreement. It also makes sense to stay internal when the bottleneck is narrow and obvious, such as a broken CI job, an absent code owner during leave, or a release calendar nobody updated. These problems need ownership and execution, not a new executive role.

Do not hire an outsider merely because the team disagrees about which coding assistant to standardize. Tool selection is reversible and should follow the constraints of the delivery system. A two-week trial with real work can answer whether a tool fits the repository, security rules, and review habits. Leadership becomes the issue when nobody can define the operating model around the tool.

The internal leader must have authority, not ceremonial responsibility. If the CEO asks for faster releases but still inserts urgent work daily, if sales can promise dates without product review, or if only the founder may deploy, engineering cannot repair the system alone. Either move those decision rights or acknowledge that the bottleneck sits above the engineering manager.

Outside AI leadership is justified by repeated evidence

Bring in outside leadership when the constraint crosses functions, persists after a credible internal attempt, and costs more than the intervention. The evidence should make the decision legible to a founder who never opens the repository.

Strong evidence includes:

• Pull requests or merged changes age in the same stage across several weeks, with a repeated wait reason.
• AI tool spending and proposed changes rise while production release frequency stays flat or falls.
• One person holds several approval paths and attempts to delegate have failed because domain ownership is undocumented.
• Release failures consume capacity through hotfixes, rollbacks, and support work, while teams still optimize for code output.
• Product, engineering, and operations report different definitions of "done" and no leader owns the full path.

Cost the delay conservatively. Count engineering time spent waiting, reworking, reviewing abandoned changes, repairing releases, and coordinating manual handoffs. Add delayed revenue only when the company can connect it to a specific release or commitment. Do not invent a large opportunity-cost number to make the engagement look cheap.

Convert those costs into an annual range with visible assumptions. For example, if a repeated release handoff consumes eight hours from two engineers twice a month, show the hours and the loaded hourly cost separately. If support and sales join the repair, add their observed time rather than a blanket multiplier. Use a low and high case when the record is incomplete. A founder can challenge an assumption without rejecting the entire diagnosis.

Evidence also needs a counterfactual. State what the company expects an internal owner to change, when the team will inspect the result, and what result would make outside help unnecessary. If the team removes an approval queue in two weeks and releases begin moving, hire nobody. If the queue simply appears at production verification, the trace has found a broader operating problem rather than disproved the need.

Outside help also makes sense when the current leader is capable but trapped inside the system. A fractional CTO can inspect incentives, decision rights, architecture boundaries, release controls, and staffing without defending the process that created them. That independence has value only if the outsider can change the operating model with the team. A report that lists tools and leaves every approval untouched will add another document to the queue.

There are warning signs against hiring. Avoid candidates who lead with an AI vendor before measuring delivery, promise headcount cuts without identifying responsibilities, or present pull request volume as proof of output. Ask what evidence would cause them to recommend no ongoing engagement. A serious outside leader should be able to define an exit condition.

A Team & AI Audit on oleg.is is structured as a five-business-day, $5,000 assessment, with a guarantee of at least $50,000 per year in identified savings or the fee is waived. That offer fits when a founder wants a bounded diagnosis before committing to fractional leadership, but the same evidence standard applies: the work should identify specific constraints, owners, economics, and a change plan.

An outside engagement must leave an operating system

The deliverable is a changed way of shipping, with measures the internal team can continue after the outsider leaves. Advice without implementation creates temporary clarity and permanent dependency.

Define the engagement around a small set of outputs:

1. A delivery map with stage definitions, data sources, queue ages, and failure demand.
2. A decision-rights map naming who can declare work ready, approve risk, release, and verify production.
3. A revised AI workflow that sets task boundaries, author obligations, review policy, and approved tool access.
4. A 30-day constraint plan with owners, capacity changes, automation work, and expected metric movement.
5. A handoff that teaches an internal owner to run the review and alter the policy.

Demand implementation evidence during the engagement. One service should ship through the revised path. One recurring manual gate should either gain an owner, become an automated rule, or be removed with an explicit risk decision. One dashboard or weekly table should connect product readiness to production. The team should be able to explain why the next constraint will become visible when the current one moves.

Set the economic boundary before work starts. A short audit may be enough if the diagnosis is uncertain. Fractional leadership makes sense when the company needs someone to carry decisions across several months, change staffing or architecture, and coach an internal successor. A full-time hire makes sense when the scope and authority will remain after the transformation. Do not turn a temporary delivery correction into an indefinite advisory subscription by habit.

Protect the team from a tool migration disguised as leadership. Replacing one assistant with another, adding agents, or installing a new dashboard can be part of the work, but each change needs a direct link to the measured constraint. If review comprehension is the queue, a faster generator has a negative expected effect. If deployment verification is manual and slow, better observability and safe automation may help.

The exit condition should be measurable: the internal owner runs the delivery review, stage ownership is clear, the release path works without the outsider, and the agreed delivery measures show a sustained direction. The exact target depends on the starting point. The obligation to define and test it does not.

Release evidence should govern the next investment

The next AI investment should follow evidence from production, not enthusiasm at the pull request screen. Keep the coding tools that reduce active work without increasing downstream wait, rework, or failure. Change the workflow around tools that generate more inventory than the team can safely release.

At the next leadership meeting, compare four lines over the same period: pull requests opened, changes merged, production releases, and changes repaired or rolled back. Then place the oldest unreleased changes beside them with their wait reasons. If the first line rises while the release line stays flat, stop discussing developer speed. Name the stage where the work is accumulating and the person who can change it.

Give an internal leader the first correction when that person owns the path and can act across its boundaries. Bring in outside AI leadership when repeated traces show a cross-functional constraint, the company cannot assign effective ownership, or the internal correction does not move delivery. That is a business decision supported by queue age, release behavior, failure cost, and decision rights. Pull request volume is only the signal that told you where to look.