Saying "No" to a Bad Technical Decision — Without Losing the Argument or the Relationship

Decision framework for pushing back:

Always push back on:
- Security vulnerabilities (stored plaintext passwords, no auth on admin routes)
- Data integrity risks (no foreign key constraints, no transactions)
- No rollback path for irreversible operations
- Decisions that will require 10x the work to undo later

Push back with evidence on:
- Architecture choices that will create scaling problems
- Tech choices that will reduce team velocity
- Missing observability that will make future incidents harder
- Skipping testing on high-risk paths

Accept and move on:
- Naming conventions you disagree with
- Code style preferences when alternatives work equally well
- Technology choices in low-risk, isolated areas
- Prioritization of features (not your call)

Know the difference: some things are irreversible (security breach, data loss),
some are slow-to-reverse (architecture), and some are easily changed later.
Only die on the first two hills.

Engineering language (loses the argument):
"We shouldn't use a monolith — it won't scale and it's not microservices-best-practices."

Business language (wins the argument):
"If we build this as a monolith now, we'll ship in 6 weeks instead of 6 months.
Here's the migration plan to extract services when we need to — we've done it
before and it takes 2 sprints. The risk: if we get acquired or need to scale
a specific component before then, we'll have 3 weeks of extraction work.
Given our current stage, I recommend we take that risk and move fast."

Engineering language:
"We can't skip tests — that's bad practice."

Business language:
"Skipping tests on the payment flow creates roughly 15% chance of a silent
billing bug per feature shipped. At our transaction volume, that's $X in
potential incorrect charges per month. I can write the critical path tests
in 4 hours — would you like me to prioritize those?"

The pattern:
1. State the risk in terms of money, time, or customer impact
2. Quantify if possible — even rough numbers force the right conversation
3. Offer a path forward that addresses the underlying business need
4. Make the tradeoff explicit — they may still choose the risk, and that's their call

# RFC Template for Contested Technical Decisions

## Problem Statement
[What business or technical problem are we solving?]

## Proposed Solution
[What's being proposed?]

## Alternatives Considered
| Option | Pros | Cons | Effort |
|--------|------|------|--------|
| Option A (proposed) | Fast to ship | No rollback, security risk | 2 weeks |
| Option B (alternative) | Safe, reversible | Slower to ship | 3 weeks |

## Risk Analysis
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|-----------|
| Data loss | Low | Critical | Automated backups + tested restore |
| Security breach | Medium | High | Rate limiting + audit log |

## Recommendation
[Your recommendation and reasoning — be explicit about the tradeoff]

## Decision
[Left blank until reviewed — fills in with the decision and who made it]

// RFCs serve multiple purposes:
// 1. Force you to think through alternatives before proposing
// 2. Create a written record of tradeoffs considered
// 3. Give stakeholders time to review without real-time pressure
// 4. Provide documentation when future engineers ask "why did we do this?"

// Rule: any architectural decision that takes > 1 sprint to reverse
// should have an RFC or ADR (Architecture Decision Record)

Instead of "No, we shouldn't do X" → "Yes, we can do X if we also do Y"

Example: "Let's ship without authentication on the admin panel — it's internal only"
Instead of: "No, that's insecure."
Try: "Yes, we can launch without auth — if we add a firewall rule to allow only
our office IP range, and we have a ticket to add auth in the next sprint.
Can we add that ticket now and time-box it to 2 days?"

Example: "Let's rewrite in Rust for performance"
Instead of: "No, that's 6 months of work we can't afford."
Try: "Yes, Rust would be faster — let's identify which specific endpoints
are actually the bottleneck. If it's the image processing worker, we can
rewrite just that in Rust (2 weeks), keep everything else in Node.js,
and get 90% of the performance benefit with 10% of the cost."

The pattern:
→ Acknowledge the valid concern behind the proposal
→ Propose a scoped version that gets the core value
→ Add the safety condition as a natural part of the yes
→ You've said yes, solved the problem, and maintained the relationship

// If you push back and are overruled — document it
// Not to "I told you so" later, but to:
// 1. Ensure the decision-maker owns the risk consciously
// 2. Create a path back when things go wrong
// 3. Protect yourself professionally

// Architecture Decision Record (ADR) template
const adrs = [
  {
    id: 'ADR-2026-003',
    title: 'Storing user preferences in localStorage instead of database',
    date: '2026-03-15',
    status: 'Accepted with known risks',
    context: 'PM requested faster implementation; database approach would take 3 days.',
    decision: 'Store in localStorage for MVP. Will migrate to database by Q2.',
    consequences: [
      'Risk: User loses preferences on browser data clear or new device',
      'Risk: Cannot sync preferences across devices',
      'Risk: Cannot analyze preference data for product decisions',
      'Mitigation: Add database sync in Q2 sprint (estimated 2 days)',
    ],
    approvedBy: 'Sarah Chen (PM), Mark Liu (Eng Lead)',
    reviewDate: '2026-06-01',  // Check if risk materialized
  },
]

Decision tree for after a failed pushback:

Can I live with this decision?
→ Yes: Accept it, document it (ADR), do your best work on it
→ No, it's a safety/security issue: Escalate to CTO or VP Engineering in writing

Does this decision create legal liability?
→ Yes (GDPR, PCI, HIPAA): Escalate with specific compliance citation
→ No: Document and accept

Will this decision hurt customers?
→ Immediately: Document, escalate, make your concerns unmissable
→ Eventually: Document timeline, create ticket for future fix, move on

Are you being asked to do something unethical?
→ Yes: This is different — escalate outside the immediate chain if needed

The key: most technical disagreements are opinion disagreements,
not ethical ones. Lose gracefully, document well, and deliver well.
Being the engineer who says "I disagreed but here's what I did to
make it work as well as possible" is more valuable than being right.