The Weight of Technical Decisions
Every software system is the product of thousands of technical decisions, from small (naming conventions, library choices) to large (database selection, service architecture, API design). As a Tech Lead, you are responsible for ensuring these decisions are made well. This does not mean you make every decision yourself; it means you ensure the right process, the right people, and the right information are involved for each decision's level of impact.
Poor technical decisions are expensive. A wrong database choice can cost months of migration work. An overly complex architecture can slow the team for years. The goal is not to make perfect decisions (impossible with incomplete information) but to make good enough decisions at the right speed with mechanisms to course-correct.
Decision Frameworks
One-Way vs Two-Way Doors
Amazon popularized this framework: a one-way door decision is difficult or impossible to reverse (choosing a primary database, defining a public API contract). A two-way door decision is easily reversible (choosing an internal library, picking a UI framework for an admin tool). Apply proportional rigor:
- One-way doors: Require thorough analysis, RFC process, multiple reviewers, and clear documentation
- Two-way doors: Can be made quickly by the engineer closest to the problem, with lightweight documentation
The Biggest Decision-Making Mistake
Treating two-way door decisions as one-way doors. This leads to analysis paralysis, where teams spend weeks debating decisions that could be made in an afternoon and reversed if wrong. As a Tech Lead, your job is often to identify that a decision is a two-way door and give the team permission to move fast.
The DACI Framework
For important decisions, use DACI to clarify roles:
DACI Roles
| Role | Definition | Example |
|---|---|---|
| Driver | Owns the process, gathers input, drafts the proposal | The engineer who identified the need for the change |
| Approver | Has final decision authority | Tech Lead or Staff Engineer |
| Contributors | Provide input and expertise | Relevant engineers, SREs, security team |
| Informed | Need to know the outcome | Dependent teams, product managers |
The RFC Process
A Request for Comments (RFC) is a written document that proposes a significant technical change, explains the reasoning, considers alternatives, and invites feedback from the team and organization. RFCs are one of the most effective tools for making high-quality technical decisions.
## RFC Template
### Title
Brief description of the proposed change
### Status
Draft | In Review | Accepted | Rejected | Superseded
### Context
What problem are we solving? What is the current state?
### Proposal
Detailed description of the proposed solution.
Include diagrams, API contracts, data models as needed.
### Alternatives Considered
What other approaches were evaluated?
Why were they rejected?
### Risks and Mitigations
What could go wrong? How do we mitigate each risk?
### Migration Plan
How do we get from the current state to the proposed state?
What is the rollback plan?
### Open Questions
What still needs to be resolved?
### Decision
[Filled in after review]
Outcome and rationale for the decision.Building Consensus
Consensus does not mean unanimous agreement. It means everyone has been heard, concerns have been addressed (or explicitly acknowledged), and the team can commit to the decision even if individuals would have preferred a different outcome. As a Tech Lead, your role in consensus building includes:
- Create space for dissent: Actively ask "What could go wrong?" and "Does anyone disagree?" Silence is not agreement.
- Separate opinions from data: When debates get heated, redirect to measurable criteria and evidence.
- Set a decision deadline: Open-ended discussions drift. Set a date by which the decision will be made.
- Disagree and commit: Once a decision is made, everyone supports it publicly, even those who argued for alternatives.
- Document the decision: Write down what was decided, why, and what alternatives were considered (this is an ADR).
When to Decide Yourself vs Delegate
Not every decision needs group discussion. Use this heuristic:
- Decide yourself: When you have clear expertise, the decision is urgent, and the stakes are low to moderate
- Consult then decide: When you need input from others but retain final authority (most architectural decisions)
- Delegate: When someone on the team is closer to the problem and has sufficient expertise (most implementation decisions)
- Facilitate consensus: When the decision affects multiple teams or has organization-wide implications
Decision Quality Indicators
- Reversibility: Can we change course if this proves wrong? Prefer reversible options.
- Time to value: How quickly does this deliver benefit? Prefer incremental delivery.
- Team capability: Does the team have the skills to execute? An elegant solution the team cannot maintain is worse than a simple one they own.
- Maintenance cost: What is the ongoing cost of this choice in complexity, infrastructure, and cognitive load?
- Alignment: Does this move us toward our long-term technical vision or create divergence?
Common Decision Anti-patterns
- HiPPO: The Highest-Paid Person's Opinion wins, regardless of evidence. Combat by requiring data and written proposals.
- Analysis paralysis: Endlessly evaluating options without committing. Set time-boxes for decisions.
- Undocumented decisions: Decisions made in hallway conversations without a record. Leads to revisiting the same debates. Always document.
- Design by committee: Trying to incorporate everyone's preferences leads to bloated, compromised solutions. Have a clear decision maker.
- Sunk cost fallacy: Continuing with a bad decision because of prior investment. Evaluate decisions based on future value, not past cost.