Why Fragmented Pull Requests Are Killing Your Shipping Velocity

Last week, I watched a senior engineer spend 45 minutes on a PR review that should have taken 15.

Not because the code was complicated. Because the change was split across three separate pull requests, each depending on the last one, and the context for understanding the whole picture was scattered across three different tabs, three different descriptions, and three different review threads.

When he finally merged the third PR and moved on, he’d lost two hours of deep work to context-switching. And that was just one review.

If you’re scaling a technical team, this is happening at your company right now. And it’s costing you way more than you think.

The Hidden Cost of Fragmented Work

Here’s what most founders don’t see: the cost isn’t in the extra time per PR. It’s in the death of flow state.

An engineer in deep work - focused, building momentum, holding all the context in their head - is operating at maybe 95% of their capacity. They’re present. The code they write is better. The decisions are faster. The throughput is highest.

Interrupt that with a PR review? They drop to 40% capacity. They have to rebuild context. That takes about 20 minutes for code review and closer to 45 minutes for code changes in an unfamiliar area.

But here’s the hidden part: the context never fully restores. Even after they’re back in the work, there’s a residual attention leak. They’re thinking about the other PR they just reviewed. They’re wondering if their fix is compatible with something they saw in the related ticket.

That’s cognitive load. And when you have related work split across multiple PRs, that load compounds with every review.

Now multiply that across a team. If you have five engineers and each one loses 45 minutes a day to context-switching on related PRs, you’re burning 225 minutes of engineering time per day. That’s almost six hours - the equivalent of losing one full-time engineer to workflow inefficiency.

At a $150K salary, that’s about $36K a year in lost productivity. Per team of five.

Most founders think they need to hire faster when the real problem is their team can’t use the capacity they already have.

Why This Happens

The problem usually starts innocently. A feature is big. Someone says “let’s break it into smaller PRs so reviews are easier.” Totally reasonable. But then you hit the real world:

First PR: Authentication layer. Depends on a new database migration. Ready for review.

Second PR: API endpoints that use the auth. Can’t merge until first PR is approved. Waiting.

Third PR: Frontend components that call the API. Can’t be tested until second PR lands. Still waiting.

Meanwhile, the engineer who wrote the auth layer is context-switching to write documentation. Or fix bugs in production. Or start on something else, then get distracted when the first review comes back with questions.

The PRs are smaller and easier to review individually. But they’re harder to understand as a system, because the full picture only exists in three places at once.

And here’s the part that kills me: most teams add “re-reviews” into this mess because the interaction between the three PRs isn’t obvious until they’re all live. So you get:

Review PR 1
Review PR 2
Review PR 3
Merge 1, 2, 3 and discover they don’t actually work together
Re-review PR 4 (the “fix”)

You’re not shipping three PRs. You’re shipping five.

How GitHub Stacked PRs Changes This

Last month GitHub announced stacked PRs are now in public preview. Most people saw it as a feature optimization. A nice-to-have for large companies.

I see it as a fix for the fragmented work problem.

With stacked PRs, you can still break work into logical chunks - auth, endpoints, frontend - but keep them visually and logically connected. The reviewer sees the full dependency chain. They understand why a particular piece exists because they can see the next PR in line that uses it.

More importantly, an engineer can keep the whole thing in context. They’re not jumping between three separate browser tabs, three separate descriptions, three separate threads. They’re looking at one coherent change with multiple parts.

That sounds small. It’s not. That’s the difference between “write the code” and “write the code while holding the entire system architecture in your head.”

When you get that second thing back, your code is better. Your decisions are faster. Your shipping velocity actually increases.

At Jetpack Labs, we’ve started using stacked PRs on some of our bigger features. The first thing we noticed: fewer re-reviews. The second thing: fewer questions during code review. The third thing: features shipping faster overall, even though the individual PRs are the same size.

The math: fewer context-switches × better code quality × faster shipping × lower re-review overhead = velocity that goes up, not down, when you add structure.

What You Should Actually Do

If you have an engineering team, here’s where I’d start:

First: Look at your last 10 PRs. How many of them have dependencies? How many reviews happened in the wrong order because the dependency wasn’t clear? That’s your baseline for the problem.

Second: If you’re using GitHub, turn on stacked PRs. (You might be in the waitlist, but sign up now.) Run one feature through the new workflow. Just one. See what happens to your review cycle time and re-review rate.

Third: If you’re not on GitHub yet, this is one reason to seriously consider it. Other platforms are adding similar features, but GitHub’s implementation is the most mature right now.

Fourth - and this is critical: Don’t just add the tool. Talk to your team about why you’re changing the workflow. The point isn’t “write smaller PRs.” The point is “keep related work connected so reviews and shipping are faster.” If your team understands the goal, they’ll use stacked PRs properly. If they think it’s just another process mandate, they’ll fight it.

The Real Lever

Here’s the thing that keeps me up at night when I talk to founders: you’re all hiring faster because your teams feel slow. But most of you never measured why they’re slow.

Is it because you need more people? Maybe. But more often, it’s because you’ve split your attention across five PR windows instead of one. Because context is scattered. Because the system you built assumes independent work, but your features don’t work that way anymore.

Adding a person to that system doesn’t make it faster. It makes context-switching worse.

Fixing the system - making related work visible, connected, and reviewable as a unit - costs nothing except a workflow change. And it’s usually worth more than hiring.

If you want to 2x your shipping velocity, try stacked PRs. Then measure the change. I think you’ll be surprised.