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 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.
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.
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.
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?)
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.
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.
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.
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.
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.
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.”
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.
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.
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.”
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).
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 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.”
Watch how much weight your “Hard Vetos” carry when you’ve built trust through selective approval.