Technical decisions shape the trajectory of engineering organisations for years. From technology selection to architectural patterns, the quality of these decisions determines team velocity, system reliability, and developer satisfaction. This guide provides engineering managers with a structured framework for making, documenting, and communicating technical decisions effectively.
Understanding Types of Technical Decisions
Not all technical decisions are created equal. Jeff Bezos's distinction between Type 1 and Type 2 decisions is particularly useful for engineering managers. Type 1 decisions are irreversible or nearly so - choosing a primary programming language, selecting a cloud provider, or designing a core data model. These decisions deserve careful analysis, broad input, and thorough documentation. Type 2 decisions are easily reversible - choosing a library, selecting a testing framework, or deciding on a code formatting standard. These should be made quickly to avoid analysis paralysis.
Engineering managers frequently err in both directions: treating Type 2 decisions with Type 1 gravity (wasting time on inconsequential choices) or treating Type 1 decisions with Type 2 speed (rushing into costly commitments). Developing the judgement to categorise decisions correctly is one of the most valuable skills an engineering manager can develop.
A useful heuristic is to consider the blast radius and reversal cost of each decision. A decision that affects one team and can be reversed in a sprint is clearly Type 2. A decision that affects multiple teams and would require months of migration to reverse is clearly Type 1. Most decisions fall somewhere in between and should be handled with proportionate rigour.
- Type 1 decisions are irreversible and warrant careful analysis and broad input
- Type 2 decisions are reversible and should be made quickly to maintain velocity
- Assess blast radius and reversal cost to categorise decisions appropriately
- Document Type 1 decisions thoroughly including context, alternatives, and rationale
- Delegate Type 2 decisions to the team closest to the problem
Establishing Clear Evaluation Criteria
Before evaluating options, define the criteria that matter for the specific decision. Common criteria for technology decisions include: team expertise, community support and ecosystem maturity, performance characteristics, operational complexity, licensing and cost, scalability trajectory, and alignment with existing architecture. Weighting these criteria forces the team to articulate what matters most.
Involve the right people in defining criteria. Product managers can speak to time-to-market pressures, operations teams can assess operational complexity, and security teams can evaluate risk. An engineering manager who defines criteria unilaterally may miss important dimensions that lead to regret later.
Be explicit about constraints that eliminate options outright. Regulatory requirements, budget limits, existing infrastructure, and team size can all rule out otherwise attractive options. Separating hard constraints from preference criteria prevents the team from spending time evaluating options that are not actually viable.
Gathering Input Without Seeking Consensus
For Type 1 decisions, seek input broadly but do not require consensus. The goal is to surface perspectives, risks, and considerations that the decision-maker might have missed. Request for Comments (RFC) documents are an effective mechanism - publish a proposal, set a comment period, and actively solicit feedback from affected teams and domain experts.
Beware of the loudest voice winning. In technical discussions, the most senior or most vocal engineer's opinion often carries disproportionate weight regardless of its merit. Counter this by requiring written feedback before meetings, using structured evaluation against the defined criteria, and explicitly asking quieter team members for their perspective.
Set a deadline for the decision. Without a clear timeline, technical decisions can languish in discussion indefinitely as the team seeks the perfect option. Communicate the decision date upfront, gather input within that window, and make the call when the deadline arrives - even if not everyone agrees. A good decision made promptly is almost always better than a perfect decision made too late.
Documenting Technical Decisions Effectively
Every significant technical decision should be documented in a way that captures not just the decision itself but the context in which it was made. Architecture Decision Records (ADRs) are the gold standard for this: a short document recording the status, context, decision, and consequences. The context section is particularly important - it explains why the decision made sense given the information available at the time.
Include the alternatives that were considered and why they were rejected. This prevents future engineers from re-litigating settled decisions without understanding the full picture. It also provides valuable context if circumstances change and the decision needs to be revisited - the team can quickly assess whether the reasons for the original decision still hold.
Store decision documents alongside the code they affect. ADRs in a docs directory within the relevant repository are more discoverable than decisions buried in a wiki or Confluence space. Use a consistent numbering scheme and maintain an index of decisions so they are easy to find and reference.
Decision Ownership and Accountability
Every technical decision needs a clear owner - one person who is accountable for making the call and living with the consequences. In many organisations, this defaults to the most senior engineer, but that is not always optimal. The best decision-maker is usually the person closest to the problem with sufficient context to evaluate the trade-offs.
Engineering managers should resist the temptation to make every technical decision themselves. Your role is to ensure that decisions are made well - that the right criteria are considered, the right people are consulted, and the decision is documented - not to make every call personally. Delegating decision-making authority develops your team's technical leadership skills and scales your organisation's decision-making capacity.
When a decision turns out to be wrong, focus on learning rather than blame. If the decision was made with good process - clear criteria, broad input, proper documentation - then a bad outcome reflects new information, not poor judgement. Conduct a brief review to understand what was missed and how the decision-making process can be improved for future decisions.
Key Takeaways
- Categorise decisions as Type 1 (irreversible) or Type 2 (reversible) and apply proportionate rigour
- Define evaluation criteria before evaluating options to prevent post-hoc rationalisation
- Seek broad input for Type 1 decisions but do not require consensus - set a deadline and decide
- Document decisions using ADRs that capture context, alternatives, and consequences
- Delegate decision-making to the person closest to the problem with sufficient context
Frequently Asked Questions
- How do you know when you have enough information to make a technical decision?
- You rarely have complete information, and waiting for it is usually a mistake. A good rule of thumb is to decide when you have about seventy percent of the information you wish you had. Beyond that point, additional research has diminishing returns and the cost of delay exceeds the benefit of additional certainty. For Type 2 decisions, even less information is sufficient because the decision is easily reversible.
- How should engineering managers handle technical decisions they do not fully understand?
- You do not need to understand every technical nuance to ensure good decisions are made. Focus on the process: are the right criteria being evaluated, have alternatives been considered, have affected stakeholders been consulted, and is the rationale documented? Ask clarifying questions, seek explanations in terms of trade-offs and risks, and delegate the technical judgement to trusted senior engineers while you ensure the decision-making process is sound.
- What do you do when the team cannot agree on a technical decision?
- Persistent disagreement usually indicates either unclear criteria or different underlying assumptions. Surface these by asking each party to articulate their evaluation criteria and assumptions. Often, agreement emerges when the criteria are aligned. If genuine disagreement remains, the designated decision-maker should make the call, document the rationale, and commit to revisiting the decision if specific risks materialise. Disagree and commit is a healthy practice.
Try the Decision-Making Tools
Use our interactive technical decision matrix, ADR templates, and decision log tools to bring structure and transparency to your engineering team's technical decisions.
Learn More