Pipeline is green but lead time grows. Three areas to investigate?

WHAT THIS TESTS: This question probes whether you conflate pipeline health with delivery speed. A green CI/CD signal means builds pass, but lead time for changes is a DORA metric measuring the full commit-to-production interval. Seniors should think in value stream terms: work spends most of its time waiting, not processing. The interviewer wants to see you decompose lead time into queue time, active pipeline time, and post-pipeline release time rather than treating the pipeline as a black box.

A GOOD ANSWER COVERS: First, investigate pre-merge wait states. Code review latency, approval backlogs, and PR queue time often dominate lead time even when the pipeline itself is instant. Metrics to validate: average PR pickup time, time from open to merge, and commit-to-merge duration. Second, investigate in-pipeline duration. A green pipeline can still be slow due to oversized test suites, lack of parallelization, long artifact builds, or sequential environment promotions. Metrics to validate: total pipeline run time, stage-level duration breakdown, test parallelization ratio, and queue time before job execution. Third, investigate post-pipeline deployment friction. Changes may pass CI but sit in staging, wait for release trains, require manual sign-off, or endure lengthy canary analysis. Metrics to validate: merge-to-deploy interval, deployment frequency, batch size per release, and time spent in each pre-production environment.

COMMON WRONG ANSWERS: Blaming test flakiness is a red flag because the prompt states the pipeline is green. Suggesting the team add more tests or gates would further increase lead time. Confusing lead time with change failure rate or MTTR shows shallow DORA knowledge. Proposing to simply hire more engineers without identifying the actual constraint is also weak. Another trap is focusing only on post-deploy production metrics like CPU or error rates, which do not explain why changes take longer to ship.

LIKELY FOLLOW-UPS: How would you distinguish between a process bottleneck and a pure capacity bottleneck? If code review time is flat, what else in the pre-merge phase could explain the increase? How would you reduce integration test duration without cutting coverage? What is the relationship between deployment frequency and lead time, and why might improving one automatically improve the other? How do you know if a manual gate is adding value or just adding wait time?

ONE CONCRETE EXAMPLE: A platform team notices their pipeline stays green but lead time grew from four hours to three days. Value stream mapping reveals: average code review pickup time increased from two hours to twenty hours after a reorganization left one senior reviewer responsible for three teams; the integration test stage is green but takes fifty-five minutes because tests run sequentially on a single runner; and releases moved from on-demand deploys to a weekly batch process for a new staging audit gate. By adding a second reviewer rotation, parallelizing test shards across four workers, and replacing the weekly batch with automated canary thresholds, lead time drops back to under five hours.