Don't Treat All Decisions Equally
The biggest organizational failure mode is applying a "Type 1 approval process" to "Type 2 decisions." This is the root cause of bureaucracy, slow velocity, and engineer frustration. When a developer needs three approvals to change a log level, the process is broken — not because the approvals are inherently bad, but because the process weight is wildly disproportionate to the decision's reversal cost.
Matching Process to Decision Type:
| Decision Type | Process | Example Mechanism |
|---|---|---|
| Type 2 — Low impact, easy reversal | No approval. Individual decides. | Engineer changes a feature flag, updates a dashboard, or tries a new library in a branch. |
| Type 2 — Moderate impact, easy reversal | Inform, don't ask. | Post in Slack: "I'm switching our test runner from Mocha to Vitest. Here's why. Speak up if you see a problem." |
| Type 1 — Moderate impact, hard reversal | Lightweight review. | One senior engineer or tech lead reviews a short decision document. Turnaround: 1-2 days. |
| Type 1 — High impact, hard reversal | Full RFC/ADR with deadline. | Written proposal, comment period (1 week max), decision meeting, recorded outcome. |
The "Disagree and Commit" Principle
For Type 1 decisions, vigorous debate is healthy and necessary. But debate must have a deadline. Once the decision is made — even if you personally disagreed — you commit fully to making it succeed. This is not about suppressing dissent. It's about preventing the organizational dysfunction where people passively sabotage decisions they opposed by dragging their feet, withholding effort, or saying "I told you so" at the first sign of trouble.
The phrase comes from Amazon's Leadership Principles, but the concept is universal. In practice, it sounds like: "I don't think Kafka is the right choice here — I'd prefer NATS for our scale. But the team has decided on Kafka, and I'm going to make our Kafka implementation the best it can be."
The distinction between healthy dissent and passive sabotage is timing. Before the decision: argue loudly, present data, escalate if needed. After the decision: commit completely. The window for debate closes when the decision is made, not when you feel satisfied with the outcome.
Calibrating Over Time
Your team's decision policy isn't static. Review it quarterly:
- Are Type 2 decisions still moving fast, or has process crept in?
- Did any Type 1 decisions turn out to be more reversible than expected? Recalibrate.
- Did any Type 2 decisions have unexpectedly large blast radius? Learn from it and adjust the classification criteria.
If asked "Tell me about a time you disagreed with a technical decision," interviewers are testing for the 'disagree and commit' pattern. Structure your answer as: (1) what you disagreed with and why, (2) how you expressed your disagreement constructively with data or alternatives, (3) how you committed to the decision once it was made, and (4) what the outcome was. Never frame it as "I was right and they were wrong." Even if you were right, the interviewer wants to see collaboration maturity, not vindication.
Key Point: The approval threshold should be proportional to the reversal cost, not to the seniority of the person making the decision. A junior engineer should be empowered to make Type 2 decisions without asking permission. A VP should still write an RFC for a Type 1 decision. Process follows consequence, not hierarchy. Organizations that invert this — requiring junior engineers to get approval for everything while letting senior leaders make Type 1 decisions informally — get the worst of both worlds: slow execution and poor strategic choices.