Technical Decision-Making
Technical decision-making is the practice of choosing among technical options by connecting business goals, constraints, evidence, risks, and trade-offs. It helps a team make a clear choice, record why it fits, and revisit it when the context changes.
itEngineering leadership and delivery management | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Technical Decision-Making
Technical decision-making is the small but persistent discipline of making a choice visible before it turns into a fossil in a repository. It is not a ceremony for choosing the best database, because there is no best database wandering the universe waiting to be selected. There is only a bounded choice in a particular system, with an outcome it must support and a bill that someone will eventually receive.
Begin with the frame. Name the boundary, the current state, and the cost of doing nothing. Then name the decision drivers, the ranked criteria that distinguish the credible options. This is the useful bit: reliability, delivery effort, operating burden, cost, and reversibility do not become friendly merely because they are placed in a spreadsheet together.
A weighted matrix can help, but it cannot achieve sentience or objectivity. Its numbers still contain assumptions, so run a sensitivity check, a test that changes uncertain weights or ratings. If a tiny adjustment crowns another winner, the choice is fragile. That is not an administrative failure. It is information: gather better evidence, narrow the scope, or record the risk plainly.
The other indispensable creature is the decision owner, the person with authority and accountability for the call. Contributors provide evidence and consequences. Reviewers challenge reasoning. Consensus can be useful, but without an owner, deadline, and escalation path it has a remarkable ability to turn into weather.
Write an ADR while options can still change. Capture context, options, evidence, consequences, validation, and review triggers. The record preserves intent; it does not enforce it. Connect the choice to delivery work, tests, operational measures, security checks, or cost data, then revisit it when a failed assumption, missed target, or changed dependency gives reality a vote.
Read the Course tab for the full decision loop, Slides for the mental map, Cheatsheet for the comparison and ADR templates, Practice for the techniques, and Quiz when it is time to see whether the matrix has been mistaken for a prophecy.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_eval_tradeoffs.html
Supports
- Governance based on business outcomes, benefits, risks, and evidence
- Explicit roles, authority, conflict resolution, and prioritization
- Central treatment of hard-to-reverse decisions
- Delegation of reversible decisions
- Cost, security, reliability, performance, and delivery trade-offs
- https://learn.microsoft.com/en-us/azure/well-architected/what-is-well-architected-framework
Supports
- Reliability, security, cost, operational excellence, and performance drivers
- Workload requirements as the context for acceptable trade-offs
- Iterative assessment and optimization over time
- https://www.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method/
Supports
- Multiple competing quality attributes
- Scenarios, risks, sensitivity points, and trade-off analysis
- Candidate architectures followed by analysis and risk mitigation
- https://learn.microsoft.com/en-us/azure/well-architected/architect-role/fundamentals
Supports
- Business requirements and constraints as design inputs
- Proof-of-concept validation for high-risk or novel components
- ADRs with context, consequences, justification, trade-offs, and rejected options
- https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html
Supports
- ADR definition and minimum context, decision, and consequences
- Significant decision scope
- Ownership, proposal, review, acceptance, and rejection
- Decision records used during later code and architecture review
- https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/best-practices.html
Supports
- Explicit ADR ownership
- Preserving history and linking superseding records
- Central and accessible decision storage
- https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record
Supports
- Significant decision selection
- Alternatives, requirements, constraints, justification, and implications
- ADR maintenance across a workload lifecycle
- https://google.github.io/eng-practices/review/reviewer/standard.html
Supports
- Technical facts and data over opinions and preferences
- Consensus based on engineering principles
- Escalation to a lead, maintainer, or manager when conflict remains
- https://github.com/sindresorhus/awesome
Supports
- Required Awesome ecosystem discovery starting point
- https://github.com/joelparkerhenderson/architecture-decision-record
Supports
- Discovery of relevant ADR ecosystem projects
- MADR, adr-tools, and Log4brains as decision-record resources
- https://adr.github.io/adr-tooling/
Supports
- Tool categories and supported decision-record templates
- MADR, adr-tools, and Log4brains discovery and workflow descriptions
- https://adr.github.io/madr/
Supports
- Markdown decision records
- Context, drivers, options, outcome, consequences, and confirmation
- Examples and a project decision log
- https://github.com/npryce/adr-tools
Supports
- Command-line initialization and record creation
- Numbering, supersession links, and table-of-contents generation
- https://github.com/thomvaill/log4brains
Supports
- Markdown ADR authoring and static knowledge-site publication
- Timeline and decision relationship views
- https://www.sei.cmu.edu/library/tool-support-for-architecture-analysis-and-design/
Supports
- 1996 publication documenting SAAMtool and architecture analysis support
- https://www.itcon.org/papers/2005_10.content.04400.pdf
Supports
- 2005 research on tracking decision-making during architectural design
- https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
Supports
- 2011 publication of lightweight Architecture Decision Records
- https://github.com/npryce/adr-tools/blob/master/LICENSE.txt
Supports
- 2016 copyright record for adr-tools
- https://aws.amazon.com/blogs/architecture/announcing-the-new-version-of-the-well-architected-framework/
Supports
- 2015 public release of the AWS Well-Architected Framework
- 2017 lenses and 2018 AWS Well-Architected Tool launch
- https://aws.amazon.com/blogs/aws/new-aws-well-architected-tool-review-workloads-against-best-practices/
Supports
- 2018 public launch of the self-service AWS Well-Architected Tool
- https://aws.amazon.com/blogs/aws/well-architected-custom-lenses-internal-best-practices/
Supports
- 2021 launch of AWS Well-Architected Custom Lenses
- https://docs.structurizr.com/server/decisions
Supports
- Structurizr decision logs, ADR rendering, and decision relationship exploration
- https://aws.amazon.com/well-architected-tool/
Supports
- AWS Well-Architected Tool evaluates cloud architectures against a framework
- https://sparxsystems.com/products/ea/
Supports
- Enterprise Architect supports architecture modeling and traceability