How to Tell If Your Engineering Team Is Actually Blocked

Last updated October 2026

Engineering team blockers rarely show up in standup. To tell whether your team is actually blocked, measure waiting rather than asking about it: how long work sits untouched, how long pull requests wait for a first review, how many items are parked on another team or a decision, and whether one person sits in every handoff.

Key takeaways

Standup only surfaces the blockers engineers are willing to name. The costly ones stay silent, so measure waiting instead of asking about it.
Blocked, slow and overloaded look the same on a burndown chart but need opposite fixes: remove a dependency, add pairing, or stop starting new work.
PR pickup time over 16 hours and review time over 24 hours at the 75th percentile fall in the bottom band of LinearB’s 2026 benchmarks.
Google’s engineering practices guide sets one business day as the maximum time to respond to a code review request.
AI-generated pull requests wait 4.6 times longer for a first reviewer, so split pickup time by author type.
A 30-minute weekly routine finds hidden blockers: list aged items, group them by what they wait on, check pickup time, find the single point of failure, and give the top three an owner and a date.

Why doesn’t standup surface engineering team blockers?

Because standup only catches the blockers an engineer is willing to name, and the expensive ones are the ones nobody names. A developer waiting two days on a review does not say “blocked”. They pick up something else, which feels productive and quietly doubles work in progress. A developer waiting on a product decision says “still working on it” because the question has been asked and there is nothing new to report. A developer who cannot get staging access files a ticket and moves on.

The data says this gap is wide. Atlassian’s 2025 State of Developer Experience report, a survey of 3,500 developers and managers across six countries, found that 50% of developers lose 10 or more hours a week to non-coding work, and 90% lose six or more to organizational inefficiencies. The top causes it names are finding information, adapting to new technology, context switching between tools, and collaborating with other teams. The same report found that 63% of developers now say leaders do not understand their pain points, up from 44% the year before.

Read those two numbers together. Most of the time your team loses is spent waiting or searching, and most of your engineers believe you cannot see it. That is the gap the usual advice misses: it tells you to ask about blockers more often, when the blockers that cost the most are the ones that never get raised.

What is the difference between blocked, slow, and overloaded?

These three look identical on a burndown chart and need opposite fixes, so separate them before you act.

Blocked means the work cannot move until someone outside the person doing it acts: a reviewer, a decision maker, another team, an environment. Adding effort does nothing. Removing the dependency fixes it in hours.
Slow means the work is moving, but the task is harder than estimated or the person is new to that part of the code. Adding pairing or splitting the task helps. Escalation does not.
Overloaded means too many items are open per person, so each one waits on its own owner. It looks like being blocked from the outside, but the dependency is internal. The fix is to stop starting work, not to chase anyone.

The tell is where the clock is running. If the item is waiting on someone other than its owner, it is blocked. If the owner is touching it daily, it is slow. If the owner has not touched it because they have five other things open, it is overload.

Which metrics reveal engineering team blockers before anyone reports them?

Every signal below can be pulled from your issue tracker and your Git host without a survey. Run them weekly. The thresholds are the ones we use when we take over a team, and the review thresholds come from published benchmarks.

Signal	Where to find it	What blocked looks like
PR pickup time (opened to first review)	Git host API	Over 16 hours at the 75th percentile, the bottom band in LinearB’s 2026 benchmarks
PR review time (first review to approval)	Git host API	Over 24 hours at the 75th percentile, also LinearB’s bottom band
Work item age in progress	Issue tracker	Any item with no status change and no linked commit for 3 working days
Items flagged or in a “waiting” status	Issue tracker	More than one per engineer at any time, or any item waiting over 5 working days
Open items per engineer	Issue tracker	More than two in progress per person, which usually means work was parked rather than finished
Single-person handoffs	Reviewer and assignee history	One person reviews or approves more than 40% of all merged changes

The review benchmarks come from LinearB’s 2026 Software Engineering Benchmarks, built from 8.1 million pull requests across 4,813 teams. It rates pickup time under one hour at the 75th percentile as elite, one to four hours as good, five to sixteen as fair, and anything over sixteen as needing focus. For review time the bands are under three hours, three to fourteen, fifteen to twenty four, and over twenty four.

Google sets a simpler rule in its public engineering practices guide: one business day is the maximum time it should take to respond to a code review request. The guide is explicit that slow reviews cut team velocity even while each individual looks busy, and that most complaints about strict reviewers disappear when the same feedback arrives quickly. A team that misses that one-day bar on a regular basis is blocked on review, whatever its standup says.

For the longer list of leading indicators, including how work item age and WIP predict a slipped date weeks in advance, see our pillar on engineering delivery metrics that predict a missed deadline.

Are AI-generated pull requests creating a new review blocker?

Yes, and it is the fastest-growing one we see. AI tools have moved the constraint from writing code to reviewing it. LinearB’s same benchmark found that AI-generated pull requests wait 4.6 times longer before a reviewer picks them up, though they are reviewed about twice as fast once someone does. Their acceptance rate is far lower: 32.7% of AI-generated PRs were accepted against 84.4% of manual ones.

The practical effect is a queue. More changes are opened, each one is larger, and reviewers defer the ones they do not trust. Nobody on the team reports this as a blocker because every individual is busy. The signal is in the pickup time split by author type, which most dashboards do not show by default. If you only compute one new number this week, compute that one.

How do you find hidden blockers in 30 minutes a week?

This is the routine we run on every team we take on. It fits inside a single weekly review and needs nothing beyond tracker and Git exports.

Pull every in-progress item older than three working days. For each one, write down who or what it is waiting on, in one line. If the answer is “nothing”, it is slow or overloaded, not blocked, and it goes to a different conversation.
Group the waiting items by what they wait on. In practice there are five buckets: review, a decision, another team, an environment or access request, and one person’s knowledge. The largest bucket is your real constraint, whatever the team believes it is.
Check PR pickup time at the 75th percentile, split by author type. Compare it with the LinearB bands above. If AI-assisted changes wait far longer than human ones, the fix is smaller changes and a named reviewer rota, not more reviewers.
Find the single point of failure. Count approvals and assignments per person over the last month. If one name dominates, that person is the blocker, and they are almost always the busiest and most trusted person on the team.
Assign one owner and one date to each of the top three. A blocker without an owner is a complaint. A blocker with an owner and a date is a work item, and it goes back on next week’s list until it is closed.

We fold these five steps into the agenda described in how to run a weekly engineering review in 25 minutes, so the check costs no extra meeting.

What should you do once you find the blocker?

Match the fix to the bucket. Each one has a known remedy, and most take less than a week to put in place.

Review: cap change size, rotate a named reviewer each day, and publish pickup time weekly. Visibility alone usually moves it.
Decisions: name a decision owner for every epic and give open questions a deadline. An unanswered question becomes a default after 48 hours.
Another team: raise the dependency at the start of the work, not when it blocks. Track multi-team items separately, since they will always run longer.
Environments and access: treat provisioning time as a defect. If a new engineer cannot open a pull request on day one, the onboarding path is broken.
One person’s knowledge: pair, record, and move approvals to a second reviewer. This is the slowest fix and the one most worth starting today.

Watch that you are measuring waiting and not output. A team can raise its story points and still be badly blocked, which is why we argue in velocity is not productivity that flow and quality belong next to throughput.

How does TopDevz keep pods from getting blocked?

We measure the same signals on every engagement. Our PULSE telemetry collects more than 400 data points a week, so a waiting state is visible to us and to the client before it costs a sprint. Continuity matters too: with 96% team retention, the engineers who know the system are still on it next quarter, and knowledge is spread across the pod instead of sitting with one person.

Our Delivery Pods start from $15K per month with 30-day notice, and the blocker routine above is part of how each one runs from week one.

Frequently asked questions

What is a good PR pickup time?

LinearB’s 2026 benchmarks, built from 8.1 million pull requests, rate pickup under one hour at the 75th percentile as elite and one to four hours as good. Anything over sixteen hours needs focus.

How can I tell if a developer is blocked or just slow?

Look at where the clock is running. If the item waits on someone other than its owner, it is blocked. If the owner touches it daily, it is slow. If the owner has not touched it because other items are open, it is overload.

How often should a team check for blockers?

Weekly. Every signal in the table above comes from the issue tracker and the Git host, and the five-step routine fits inside a single weekly review without an extra meeting.

Why do AI-generated pull requests slow down review?

Reviewers defer changes they do not trust. LinearB found that AI-generated PRs wait 4.6 times longer before pickup and are accepted 32.7% of the time, against 84.4% for manual ones. Smaller changes and a named reviewer rota help.

Who is usually the hidden blocker on a team?

Often the busiest and most trusted engineer. If one person reviews or approves more than 40% of merged changes, work queues behind them. Pairing and moving approvals to a second reviewer spread the load.

Book a Code Review

If your dashboards say the team is busy and your dates keep slipping, the answer is usually a waiting state nobody has named yet. A senior engineer can find it in the code and the tracker faster than another round of status meetings will. Book a code review and we will walk your repository and your board, show you where the work is waiting, and reply within one business day.