The company builds B2B software and runs engineering as five teams. Some of them sit in different time zones, so on any given day part of the team is starting work while another part is logging off. The VP of Engineering owns delivery across all five.
The challenge: work kept piling up in review
Ask almost any engineering team where things slow down and someone will say “review.” This team was no different. Tasks moved through development at a decent pace, then sat in review for days.
The VP of Engineering had heard about it in retros and one-on-ones. The trouble was that nobody could say where exactly. Jira showed tickets parked in “In Review.” GitHub showed open pull requests. Neither one explained why one PR got approved in an hour and another waited until Friday.
“Everyone agreed review was the problem. When I asked which repos, I got opinions.” — VP of Engineering
Time zones made it worse. A pull request opened at the end of the day in one office would often go to a reviewer who had already left, and a whole day passed before anyone looked at it.
I didn't want to change how 40 people work based on a hunch. I needed to see which queues were actually stuck and why.
So the question was pretty specific: where is work waiting for review, who is it waiting on, and what’s the smallest change that fixes it?
The solution: one view of Jira and GitHub, split by stage
The team didn’t want another tool that asks engineers to change how they work. AndonPulse reads from the systems they already used, so nothing changed on the board or in the repos.
Setup took two weeks. The team connected Jira and GitHub, mapped engineers into their five teams, and configured workflow stages. That last part mattered most. Once a task’s cycle time was split into stages, the “review is slow” feeling turned into numbers: how long work waited for a first review, how long the review itself took, and what happened after.
The pattern showed up quickly. Review wasn’t slow everywhere. Most of the waiting traced back to a few reviewers who handled a big share of pull requests across several repositories. They knew the code best, so work kept getting routed to them. When they were busy or offline in another time zone, everything queued up behind them.
It wasn't that those engineers were slow. They were just doing everyone's reviews, and nobody had seen how much.
From there the managers made two changes:
Shared the review load. Pull requests that used to go to the same few people by default were spread across more engineers who knew the code well enough to give a first pass.
Agreed on time for review. Teams set aside regular time for reviews instead of squeezing them in between tasks, which helped most with handoffs across time zones.
Neither change was new. What was new was knowing which repositories and which reviewers to start with, and being able to check a few weeks later whether it was working.
Results: half the wait, two days off every task
After four months:
Median wait for a first review: 2 → 1 working day. The queue that used to eat most of the cycle shrank by half.
Median task cycle time: 8 → 6 working days, −25%. The day saved on review carried through to the rest of the cycle.
No change to how engineers work. The data came from Jira and GitHub as they were already used.
| Metric | Before | After 4 months | Change |
|---|---|---|---|
| Median wait for first review | 2 working days | 1 working day | −50% |
| Median task cycle time | 8 working days | 6 working days | −25% |
The fix itself was pretty boring. We shared the load. What changed is that we knew we were fixing the right thing, and we could watch it get better week by week.
Time-to-value
From connecting Jira and GitHub to a clear picture of where review was stuck took two weeks. The results above were measured over the four months that followed.
What’s next: keeping the bottleneck from coming back
Review load has a habit of drifting back to the same people, especially as teams grow and new repositories appear. The VP of Engineering now keeps an eye on review distribution and waiting time as regular delivery metrics, so the next bottleneck shows up on a dashboard, not in a retro.
“Now when someone says review is slow, I can open the data and see if it’s true.” — VP of Engineering
