Engineering Productivity Case Study: 2.5x in 30 Days

Nick Morgan, Co-founder22 June 2026 · 9 min read

Ask AI

We just closed an amazing pilot, and the numbers are worth sharing. In a 30-day window, a 10-person engineering team increased delivery throughput by 2.5x while cutting median cycle time by almost two thirds. This engineering productivity case study breaks down what moved, by how much, and why.

The team was not rebuilt and no one was replaced. The same people, working on the same product, shipped substantially more by tightening a handful of measurable habits.

The team was 10 engineers working on a single product with an existing CI pipeline and a regular review process. Nothing about the setup was unusual, which is the point: these are conditions most teams will recognise.

We measured a 30-day baseline first, then ran a 30-day pilot. Across both windows we tracked the same four numbers: delivery throughput, median cycle time, average pull request size, and deployment frequency.

We chose these four deliberately. They are observable from version control and CI without any subjective input, and together they describe both speed and stability. A team can game any one of them in isolation, but it is very hard to move all four in the same direction without genuinely improving how work flows.

No new headcount was added and no overtime was encouraged. The only thing that changed was how visible these metrics were and how deliberately the team acted on them.

Delivery throughput, measured as merged changes that reached production, increased by 2.5x over the baseline. The team now merges 3.86 pull requests a day, up from around 1.5 at the start. This is the headline result, but on its own it is easy to misread.

Throughput can be inflated by splitting work into more pieces without delivering more value. That is not what happened here. The team shipped more complete units of work, not more fragments, which is why the other metrics moved in step.

The increase was steady rather than a single spike. By the second week the trend was already clear, and it held through the end of the pilot.

That stability matters more than the peak. A throughput number that swings wildly week to week usually reflects luck or batching, not a healthier system. A sustained 2.5x tells us the underlying workflow changed, which is exactly what we want a pilot to prove.

Median cycle time, the elapsed time from first commit to merge, dropped from 72 hours to 23 hours 38 minutes, just under a day. This was the change that unlocked the rest.

As we have written before in why cycle time is the metric that matters most, cycle time is the clearest leading indicator of delivery health. When it falls, feedback loops tighten and most other metrics tend to follow.

The biggest lever was pull request size. Smaller changes got reviewed faster, merged sooner, and created fewer conflicts. Our guide to reducing PR cycle time covers the same levers the team leaned on.

A shorter cycle time is only useful if you know which stage shrank. Breaking the 23 hours 38 minutes down shows where the time still sits: coding takes 8 hours 48 minutes, pickup 2 hours 22 minutes, and review 12 hours 25 minutes, with deploy adding a further 4 hours 1 minute.

Review is still the largest single stage at 12 hours 25 minutes, which is exactly why pull request size was the lever that mattered most. Smaller changes are quicker to pick up and quicker to review, so shrinking them pulls down the two largest segments at once.

Pickup time, the wait before a review starts, was already low at 2 hours 22 minutes. That told us the bottleneck was the review itself, not getting someone to look, so the team focused on making each review smaller rather than chasing reviewers.

Deployment frequency rose to 3.86 deploys a day, up from around one a day at baseline, close to a fourfold increase. This is a direct consequence of the changes above rather than a separate initiative.

Smaller changes and a reliable pipeline make deploying routine instead of risky. When each deploy carries less change, the cost and anxiety of shipping drop, so the team ships more often. Higher deployment frequency is one of the four DORA metrics, which our DORA metrics guide explains in full.

Here is the full before and after picture from the pilot:

None of these results came from a single tool or a heroic push. They came from making the right numbers visible and acting on them consistently.

The team focused on three habits: keep pull requests small, review them quickly, and deploy in small increments. Each habit reinforced the others, which is why the metrics moved together rather than in isolation.

Smaller pull requests made reviews faster, faster reviews kept branches short lived, and short lived branches meant fewer conflicts and smaller, safer deploys. Frequent deploys then kept each change small, which closed the loop and pushed throughput up. None of these levers is new, but applying all of them at once is what produced the compounding effect.

That is the pattern we built Poggle around. When a team can see its cycle time, pull request size, and throughput in one place, improvement tends to happen on its own, because the feedback is immediate and shared rather than buried in a dashboard no one opens.

The metrics above are about speed and stability, but they also translate into productivity. Developers lose 40 to 80 hours a month to inefficiency: slow reviews, flaky pipelines, and context switching. At a £70,000 average salary, every lost hour is worth about £34 of productive capacity.

Before the pilot, this 10-person team was sitting near the inefficient end of that range, roughly 80 hours per developer each month. That is around £323,000 a year of productivity lost. After cutting cycle time from 72 hours to under a day and shrinking pull requests, the team moved toward the efficient end, closer to 40 hours, leaving roughly £161,000 a year of lost productivity.

The gap between those two is productivity recovered: roughly £162,000 a year, about £13,500 a month, for a team of 10.

This is not money that lands in a bank account. It is an estimate of recovered capacity, built on the same model as our ROI calculator. The point is the order of magnitude: the same improvements that moved cycle time and throughput give a team this size back the equivalent of a full extra engineer's worth of productive time.

A 2.5x throughput gain in 30 days sounds dramatic, but the inputs were ordinary: smaller pull requests, faster reviews, and more frequent deploys. The compounding between them is what produced the result.

The takeaway is simple. Start with cycle time, make it visible to the whole team, and the other metrics tend to follow. What would your delivery look like 30 days from now if your team focused on the same three habits?

Nick MorganCo-founder at Poggle