Suffocating reviews
The pull request opens on Monday. The change is ready for review, the tests pass, and the author explains the approach.
A reviewer questions the transaction boundary. The author describes why they chose it. The reviewer suggests moving the operation into another service. The author points out the failure case that would introduce. Both have reasonable concerns. Neither knows who should settle the trade.
By Wednesday, the conversation has stopped.
The author picks up another ticket. The reviewer assumes the author is considering the suggestion. At stand-up, the work is “still in review.” The board gives the waiting a familiar name, and everyone moves on.
The pull request stays open because the decision has nowhere to go.
Age makes the work easy to find. The more revealing signal is the conversation inside it: an exchange exposes uncertainty or disagreement, then falls silent while the uncertainty remains.
A suffocating review can begin with careful engineering. Someone sees a real risk and asks a useful question. Another person explains a legitimate constraint. The review has done its first job by bringing different knowledge into contact. The difficulty begins when the team has a place to express the conflict and no dependable way to resolve it.
This gives the pattern a particular shape.
Private work becomes visible too late. Code going in circles accumulates revisions without useful learning. A suffocating review may contain a small, stable change that everyone has already read. Its progress depends on a choice the participants have stopped discussing.
Silence is easy to misread because it carries so little information.
The reviewer may believe their comment clearly requires a revision. The author may read the same comment as an optional suggestion. “Could we use the existing queue here?” can mean curiosity, a strong preference, or a release-blocking concern. The words leave room for all three. Each person waits for the other to take the next step.
Sometimes the disagreement concerns evidence. One engineer expects the operation to remain small. Another expects it to grow beyond the current design. Both argue from experience, and neither names an observation that would change their view. The thread collects predictions while the decision remains suspended between them.
Sometimes it concerns authority. The author owns the feature, a staff engineer owns the architectural direction, and an operations engineer carries the production risk. Each can explain why a particular choice matters. The team has yet to agree who decides when those responsibilities pull in different directions.
Hierarchy can make the silence heavier.
A junior engineer answers a senior reviewer's concern and receives another question. After several exchanges, they become uncertain whether disagreement is still welcome. They stop replying until they can produce an argument strong enough to feel safe. The reviewer sees an unanswered thread and assumes the author needs time.
The same situation can form around a forceful author. A reviewer raises a concern, receives a lengthy rebuttal, and decides that pursuing it will cost more energy than they have. They leave the thread open because approving feels dishonest. The author interprets the absence of further objection as agreement and waits for the approval.
Both people can experience the other as the blocker.
An open comment records a concern. It needs a next step to become a path forward.
Workload can produce a similar trace. A reviewer is pulled into an incident after asking a question. The author replies while the reviewer is away. Notifications accumulate, another project becomes urgent, and the conversation drops out of both people's working context. Before interpreting the silence as conflict, find out whether the participants still have time assigned to the work.
Elapsed time alone deserves care. A draft may be open throughout a deliberate experiment. A change may await an external dependency or a scheduled security assessment. A team working across time zones will have a different response rhythm from colleagues sharing an office. An old pull request becomes useful evidence when its age is paired with its readiness, expected timeline, and unresolved decisions.
Look at what happened just before progress stopped.
Did the reviewer ask for a concrete change? Did the author answer? Does the latest comment contain a question, an objection, or a preference? Is anyone named as the next person to act? Can the participants explain what would allow the change to merge?
A thread with twenty comments may have a clear route to completion. A thread with two comments may have exhausted the team's ability to choose.
Waiting changes the work around it.
The author starts something else and loses the context they will need when review resumes. The branch falls behind the main codebase. A later change invalidates an assumption that was sound when the review began. Other engineers build around the missing feature or wait on a dependency whose status still says “in review.”
When the conversation returns, everyone pays to reconstruct it. The original concern may now sit beneath a merge conflict, a changed requirement, and a fresh round of review. Delay has created additional reasons to delay.
A manager or tech lead should begin by making the state explicit.
Ask the author what is preventing the next step and who they believe needs to act. Ask the reviewer the same question. Different answers often reveal the missing agreement immediately. One person is waiting for code; the other is waiting for a decision about whether to write it.
Keep the inquiry close to the work. “This thread stopped after the discussion about retries. What remains unresolved?” gives the participants something concrete to explain. A general request to “clear the review backlog” can produce hurried approvals while leaving the decision problem intact.
Turn the disagreement into a question the team can answer.
In the transaction example, the question might be whether a failed downstream call can leave a payment recorded without its corresponding order. Trace the failure path together. Identify the guarantee the system needs. A focused test, a small experiment, or a short explanation from the service owner may supply the missing evidence.
Some disagreements remain trade-offs after the facts are clear. One approach offers simpler recovery and another keeps service boundaries cleaner. Name the costs of both, the constraint that matters most for this change, and the person accountable for the choice. The technical lead may own the design decision; a product or operational consequence may require another owner.
Bring the participants together when the thread has stopped carrying useful meaning. A short call or working session can expose assumptions that several rounds of comments failed to reach. Give it a specific question and the people able to resolve that question.
The session should end with a decision or an explicit route to one. If evidence is missing, name who will obtain it and when the team will return. If the change proceeds, record the rationale, remaining risk, and required follow-up in the pull request. That record lets absent colleagues understand the choice and gives reviewers a stable basis for their final check.
Agreement to proceed needs a clear account of the concern. A concrete correctness or safety issue still requires resolution, and acceptance of residual risk belongs with someone authorized to carry it. Pressure to merge can otherwise turn an unresolved objection into apparent consensus.
Sometimes the useful decision is to close the pull request. The need may have disappeared, the approach may have been superseded, or a smaller change may now be possible. Preserve the relevant learning and state what happens next. An explicit ending releases attention that an abandoned branch continues to occupy.
Prevention depends on making review an owned part of delivery.
Every ready change needs a known reviewer, a visible next action, and a route for unresolved decisions. The author can keep track of progress and surface a stall. The reviewer needs time to respond and responsibility for making concerns actionable. The team needs cover when either person becomes unavailable.
Make the intent of comments legible. A required change should explain the risk and what would satisfy it. A suggestion should leave the author room to choose. An open question should make clear whether an answer is needed before merging. This small discipline saves people from having to infer authority from phrasing or seniority.
Agree on a response rhythm that fits the team. Reserve capacity for review, and decide when an unanswered question or repeated exchange should move into a direct conversation. A useful escalation happens while the participants still remember the reasoning. It should bring access to evidence or a decision owner, with enough time to use both.
Review age and response times can help locate neglected work. Read them alongside the last meaningful exchange and the next expected action. A target that rewards fast comments can fill threads with acknowledgments while decisions continue to wait. Look for whether the team resolves uncertainty, resumes work, or deliberately closes it.
Across several reviews, recurring stalls reveal where the organization needs attention. Architecture debates may need earlier design decisions. Repeated waits for one specialist may need broader knowledge or protected review capacity. Junior engineers going quiet after senior objections may need clearer support for questioning those objections. The same symptom can point to very different repairs.
A healthy review leaves the participants able to explain the next step, even when they still disagree. They know which evidence matters, who will decide, and when the conversation will continue.
The review can breathe when a concern has somewhere to go.