Decision-Making Tools for Tech
Every technical leader faces a barrage of decisions. Should we rewrite this service? Buy or build? Ship now or refactor first? The problem isn't making decisions, it's making good decisions consistently.
Most teams rely on gut feeling or "how we've always done it." But there are actual tools that can sharpen your thinking.
One-Way vs Two-Way Doors (Or: Stop Overthinking Everything)
Jeff Bezos popularized this mental model at Amazon, and it's brilliant in its simplicity.
One-way doors are irreversible. Once you walk through, you're committed. Think major architecture overhauls, choosing a primary programming language, or signing that five-year vendor contract.
Two-way doors are reversible. You can back out if it doesn't work. Feature flags, A/B tests, or trying a new deployment process (depending on how complicated you’ve made it!).
It’s easy to treat every decision as a one-way door, agonizing over reversible choices for yonks. Actually, most decisions are reversible. Making a decision quickly means you learn faster. When faced with a decision, ask: "Can we undo this?" If yes, just try it. The cost of delay often exceeds the cost of reversal.
Architecture Decision Records (Write It Down, Future You Will Thank You)
ADRs are structured documents capturing why you made specific technical decisions. Not what you decided: why you decided it.
Here's what makes them powerful:
They prevent the "why did we do this?" archaeology sessions
New team members understand the context, not just the outcome
You stop having the same debates over and over
I’ve mentioned this before in a previous article, but at my current company we’re really seeing the benefits of this approach at scale. We've created over 500 ADRs. That's 500 decisions with full context, alternatives considered, and trade-offs made explicit. It's become an incredibly valuable resource - a kind of organizational memory that compounds over time.
The format doesn't matter much. What matters is capturing the context, alternatives considered, and rationale. Future you (or your successor) will thank present you.
Total Cost of Ownership (The Hidden Costs Will Get You)
I love shiny new tech, and I don’t think I’m alone! We see the elegant API, the impressive benchmarks, the slick documentation or the code that just looks great!. What we often miss are the hidden costs that bite us later.
TCO forces you to think beyond the initial implementation:
What's the learning curve for the team?
Who maintains it when the original implementer leaves?
What happens when the vendor changes their pricing model? (😱)
What are the ongoing operational costs?
How much will we spend on licenses over five years?
I've seen teams choose "free" open-source solutions that ended up costing millions in maintenance. I've also seen teams overpay for enterprise solutions when a simple library would suffice.
If you’re trying to buy a third-party system to speed you up, make sure you consider the whole suite of costs it will accrue.
Technical Debt (Stop Pretending It Doesn't Exist)
Ward Cunningham's metaphor is perfect: shortcuts in code are like financial debt. They accrue interest.
It’s also one of the most talked about thinking tools so I won’t go into detail
Tracking your development performance is key here. As Fowler discusses in the Design Stamina hypothesis, as systems grow and become more complicated it becomes harder to add features. That’s your technical debt. If you’re not measuring this, then things will get slower over time and no-one will notice.
The key for technical debt is being intentional about it. Track it. Make it visible. Most importantly, have a plan to pay it down. Debt ignored eventually becomes bankruptcy.
Second-Order Thinking (Then What Happens?)
First-order thinking: "This microservices architecture will let teams work independently!"
Second-order thinking: "...which means we'll need service discovery, distributed tracing, contract testing, and suddenly every developer needs to understand distributed systems."
Most bad technical decisions come from stopping at first-order effects. The real costs often hide in the second and third-order consequences.
Before making a decision, play it forward. What happens next? And then what? The ripple effects often dwarf the initial impact.
Pre-Mortems (Imagine Failure Before It Happens)
Post-mortems are great for learning from failure. Pre-mortems give a different perspective. What might go wrong and how could we prevent failure?
Before starting a project, imagine it's failed spectacularly. Now work backwards. What went wrong? Maybe:
The key engineer left mid-project
The API we're depending on changed
Performance requirements were 10x higher than estimated
This isn't pessimism, it's strategic paranoia! By imagining failure modes upfront, you can build in safeguards or adjust the plan entirely.
The best part? It creates psychological safety. When someone raises concerns, they're not being negative, instead they're contributing to the pre-mortem.
Wardley Mapping (See the Whole Playing Field)
Simon Wardley created this technique for visualizing your technical landscape. It maps components by:
Value to users (vertical axis)
Evolution stage (horizontal axis): genesis → custom → product → commodity
Why does this matter? Because you should build differentiators and buy commodities.
Building your own container orchestration system in 2024? That's like building your own database, a solved problem you're re-solving. Focus engineering effort where it creates unique value.
The maps make build-vs-buy decisions visual and objective instead of emotional.
Last Responsible Moment (Decide Later, Decide Better)
This lean principle says: delay decisions until the last moment you can make them responsibly.
Why? Because information has a half-life. The earlier you decide, the less you know. Wait, and you'll have:
Real usage data instead of guesses
Actual requirements instead of assumptions
Market feedback instead of projections
This isn’t to be confused with procrastination. It’s delaying until you have the information to make a better decision.
First Principles (Question Everything)
Most technical decisions are based on "how things are done." First principles thinking asks "why are they done that way?"
Example: "We need a message queue for async processing.". Nope - that’s a solution. First principles would say "we need to decouple request processing from time-consuming operations." and allow you to explore alternatives.
Maybe you need a queue. Maybe you need background jobs. Maybe you need to make the operation faster. By breaking down to fundamentals, you often find simpler solutions.
Putting It All Together
There’s no one-size fits all decision framework for technical decisions. This post has (hopefully) give a whole bunch of tools to think about tech decisions with a different view.
I’m sure I’m missing many others - what are they?