Authority is a currency. Every time you say ‘No’ you spend it. We all know that one Senior Engineer. Let’s call him Rick. Rick Rick is brilliant. He knows the codebase better than anyone. But everyone hates asking Rick for a code review. Why? Because Rick finds a reason to block everything. everything He blocks PRs because of variable naming preferences. He blocks architectural RFCs because “we tried that in 2019 and it failed.” He blocks library upgrades because “the new version is bloated.” Rick thinks he is the Guardian of Quality. The team thinks he is the Department of No. Guardian of Quality Department of No Eventually, the team stops inviting Rick to design meetings. They start merging code when Rick is on vacation. They build “Shadow IT” systems just to bypass his approval. Rick has lost his Political Capital. When a truly dangerous security flaw actually appears, and Rick screams “Stop!” nobody listens. He has already spent all his bullets on variable names. As a Staff or Principal Engineer, your job is not to be the Gatekeeper. It is to be the Cost Revealer. Political Capital Gatekeeper Cost Revealer You cannot do that if you veto everything. You need a framework for when to pull the emergency brake and when to let the train keep moving. The Veto Matrix: Risk vs. Reversibility Before you say “No,” you must ask two questions: How high is the risk? (Is this a mild bug or a data breach?)How reversible is the decision? (Can we fix this tomorrow or are we stuck with it for 5 years?) How high is the risk? (Is this a mild bug or a data breach?) How high is the risk? How reversible is the decision? (Can we fix this tomorrow or are we stuck with it for 5 years?) How reversible is the decision? 1. Low Risk / Reversible (The “Nitpick”) 1. Low Risk / Reversible (The “Nitpick”) Example: A junior dev uses a slightly inefficient loop in a non-critical background job.Your Action: Approve.The Comment: “This is O(n^2). It’s fine for now because the dataset is small, but if we scale, we will need to refactor. Merging.”Why: If you block here, you are just flexing your ego. Example: A junior dev uses a slightly inefficient loop in a non-critical background job. Example: Your Action: Approve. Your Action: Approve. The Comment: “This is O(n^2). It’s fine for now because the dataset is small, but if we scale, we will need to refactor. Merging.” The Comment: Why: If you block here, you are just flexing your ego. Why: 2. High Risk / Reversible (The “Guardrail”) 2. High Risk / Reversible (The “Guardrail”) Example: Deploying a routine code change on a Friday afternoon when SRE is offline.Your Action: The “Yes, If” Veto.The Tactic: Attach a Price Tag.The Comment: “Yes, we can deploy this today. If you are willing to join the on-call rotation this weekend because SRE is offline. Are you okay with that risk?”Why: You aren’t saying “No.” You are saying “Here is the cost.” Usually, when you expose the price tag, they withdraw the request themselves. Note: If they accept the cost, document their decision and help them mitigate the risk. Your job is to reveal trade-offs, not make business decisions. Example: Deploying a routine code change on a Friday afternoon when SRE is offline. Example: routine code change Your Action: The “Yes, If” Veto. Your Action: The “Yes, If” Veto. The Tactic: Attach a Price Tag. The Tactic: Attach a Price Tag. The Comment: “Yes, we can deploy this today. If you are willing to join the on-call rotation this weekend because SRE is offline. Are you okay with that risk?” The Comment: If Why: You aren’t saying “No.” You are saying “Here is the cost.” Usually, when you expose the price tag, they withdraw the request themselves. Note: If they accept the cost, document their decision and help them mitigate the risk. Your job is to reveal trade-offs, not make business decisions. Why: Note: 3. Low Risk / Irreversible (The “One-Way Door”) 3. Low Risk / Irreversible (The “One-Way Door”) Example: Choosing a new niche database for a minor service.Your Action: The “Disagree and Commit.”The Comment: “I believe this database adds unnecessary operational overhead. However, it fits the use case. I am noting my objection in the doc, but I will support the team’s decision.”Why: This builds massive trust. You showed you have an opinion, but you prioritize the team’s momentum over your preference.The Caveat: Do not use this if the “One-Way Door” leads to a cliff. If the decision creates 5 years of painful technical debt, move it to Quadrant 4. Example: Choosing a new niche database for a minor service. Example: Your Action: The “Disagree and Commit.” Your Action: The “Disagree and Commit.” The Comment: “I believe this database adds unnecessary operational overhead. However, it fits the use case. I am noting my objection in the doc, but I will support the team’s decision.” The Comment: Why: This builds massive trust. You showed you have an opinion, but you prioritize the team’s momentum over your preference. Why: The Caveat: Do not use this if the “One-Way Door” leads to a cliff. If the decision creates 5 years of painful technical debt, move it to Quadrant 4. The Caveat: 4. High Risk / Irreversible (The “Hard Veto”) 4. High Risk / Irreversible (The “Hard Veto”) Example: Hardcoding encryption keys, violating GDPR compliance, or deploying a bulk-delete script without safeguards.Your Action: The Hard Veto.The Comment: “I am blocking this. This implementation exposes customer PII and violates our compliance constraints. We cannot ship this under any circumstances.”Why: This is why you saved your bullets. When you use the Hard Veto, the room should go silent because they know you don’t use it lightly. Example: Hardcoding encryption keys, violating GDPR compliance, or deploying a bulk-delete script without safeguards. Example: Your Action: The Hard Veto. Your Action: The Hard Veto. The Comment: “I am blocking this. This implementation exposes customer PII and violates our compliance constraints. We cannot ship this under any circumstances.” The Comment: Why: This is why you saved your bullets. When you use the Hard Veto, the room should go silent because they know you don’t use it lightly. Why: A Real Example: The “November Blackout” At a previous e-commerce company, a Product Manager wanted to switch payment gateways one week before Black Friday to save 0.5% on transaction fees. The Junior Engineers were arguing about API compatibility. The PM was ignoring them. The Staff Engineer didn’t argue about APIs. He used the Price Tag tactic from Quadrant 2. Price Tag He wrote: “We can switch gateways. However, we cannot complete the integration testing before the code freeze. If this gateway fails on Black Friday, we will lose approximately $4.5M in orders per hour. I am willing to approve this if you sign off on that risk.” “We can switch gateways. However, we cannot complete the integration testing before the code freeze. If this gateway fails on Black Friday, we will lose approximately $4.5M in orders per hour $4.5M in orders per hour . I am willing to approve this if you sign off on that risk.” The PM withdrew the request five minutes later. The Engineer didn’t say “No.” He just put the $4.5M Price Tag on the table and let the PM decide if they wanted to pay it. $4.5M Price Tag Policy as Code in 2026 In the past, the Senior Engineer had to be the “Bad Guy” in the code review. Now, we use tools to be the Bad Guy for us. Don’t argue with a junior dev about Terraform formatting or S3 bucket permissions. Write an Open Policy Agent (OPA) rule or a GitHub Action that automatically blocks the build if an S3 bucket is public. Open Policy Agent (OPA) GitHub Action The Script: “Hey, I’d love to approve this, but the CI pipeline is blocking it because of the Security Policy we agreed on last quarter. We’ll need to fix that permission to get it merged.” The Script: “Hey, I’d love to approve this, but the CI pipeline is blocking it because of the Security Policy we agreed on last quarter. We’ll need to fix that permission to get it merged.” Now it’s not You vs. Them. It is Us vs. The Robot. You can step to their side of the table and help them “beat the robot.” You vs. Them Us vs. The Robot Your Homework Remember Rick? If Rick had used this framework, he would have Approved the variable naming PR (Quadrant 1), Disagreed and Committed to the library upgrade (Quadrant 3), and saved his Hard Veto for the security flaw (Quadrant 4). Approved Disagreed and Committed Hard Veto The team would have trusted him when it actually mattered. Look at your last 5 Code Review comments. Count how many times you blocked or requested changes. Ask yourself: “If I had approved this immediately, would the company have lost money or customers?” “If I had approved this immediately, would the company have lost money or customers?” If the answer is “No,” then you are leaking political capital. Next time, try the “Disagree and Commit” approach. Write: “I would have done this differently [Link to reason], but this works. Approved.” “Disagree and Commit” “I would have done this differently [Link to reason], but this works. Approved.” Watch how much weight your “Hard Vetos” carry when you’ve built trust through selective approval.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

If You Block Every PR, Don’t Be Surprised When No One Listens

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How To Explain Code to People Who Control the Budget

Best Practice For Code Reviews In Engineering Teams

Golden Rules of Code Reviews

How to do Code Reviews

Elevating Software Quality: A Guide to Effective Code Reviews

A Beginner's Guide to Pull Request Stacking

How To Explain Code to People Who Control the Budget

Best Practice For Code Reviews In Engineering Teams

Golden Rules of Code Reviews

How to do Code Reviews

Elevating Software Quality: A Guide to Effective Code Reviews

A Beginner's Guide to Pull Request Stacking

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps