Jan 29, 20224 min read
Making Decisions When Everything is Uncertain
Most project decisions are made with incomplete information. Here's how I think through risk, budget, and trade-offs.
Every project is a series of decisions under uncertainty. You never have perfect information. You're always trading off time, money, scope, and risk.
Most people either overthink decisions (analysis paralysis) or underthink them (shoot from the hip). There's a better way.
The Framework I Use
For any significant decision, I run through these questions:
1. What's reversible vs irreversible?
Reversible decisions: Make them fast, iterate.
- UI choices
- Feature flags
- Internal tools
- Most process changes
Irreversible decisions: Take your time, get input.
- Architecture choices
- Public API contracts
- Team structure changes
- Vendor commitments
I've seen teams spend weeks debating button colors (reversible) while making database schema decisions in a single meeting (hard to reverse). Get this backwards and you're in trouble.
2. What's the cost of being wrong?
If the downside is small, just decide and move on. If the downside is catastrophic, build in safeguards.
Example: Choosing a CSS framework? Pick one, you can change it. Choosing a payment processor? That's a 6-month migration if you get it wrong. Different levels of rigor needed.
3. What do we know vs assume?
List your assumptions explicitly. Challenge them.
"Users want feature X" — Do we have data? Or is this one person's opinion? "It will take 2 weeks" — Based on similar past work? Or wishful thinking? "The vendor is reliable" — Have we talked to their other customers?
Most bad decisions come from untested assumptions treated as facts.
Budget Decisions
Budget constraints are the most common decision filter. Here's how I think about them:
Fixed budget, flex scope: Know your budget ceiling. Cut features to fit, not quality.
Value vs cost: Not "can we afford this?" but "is the value greater than the cost?" A $50K feature that generates $200K revenue is worth it. A $5K feature that nobody uses isn't.
Opportunity cost: Money spent here isn't spent elsewhere. "We can afford it" isn't the question. "Is this the best use of this money?" is.
Hidden costs: The software is $10K/year. Plus $20K in integration work. Plus $5K/year in maintenance. Plus engineer time to learn it. Real cost: much higher than the sticker price.
Dealing With Bottlenecks
Every project has them. Usually people, sometimes systems, occasionally approvals.
Identify early: Don't wait until you're blocked. "What could slow us down?" in the planning phase.
Protect the critical path: The bottleneck sets the pace. Everything else is secondary.
Don't add people to solve people bottlenecks: Adding engineers to a late project makes it later. (Brooks's Law, still true.)
Sometimes the answer is parallel work: Can't use resource X? Find something else useful to do while waiting.
When Problems Arise
They always do. The question is how you respond.
Don't hide problems. Surface them early. A problem discovered in week 2 is much cheaper than one discovered at launch.
Separate symptoms from causes. "Tests are failing" is a symptom. "We changed the database schema without updating the test fixtures" is the cause. Fix causes, not symptoms.
Make decisions with the information you have. Waiting for perfect information means waiting forever. Make the best call with 70% certainty, then course-correct.
Own the decision. "We decided to X because of Y and Z, knowing the risks were A and B." Not "We had to do X because..." Passive voice kills accountability.
My Decision Log
For non-trivial decisions, I keep a simple log:
Decision: [What we decided]
Date: [When]
Context: [Why this came up]
Options considered: [What else we could have done]
Rationale: [Why we chose this]
Risks: [What could go wrong]
Review date: [When to check if this was right]
This takes 5 minutes to write. It saves hours of "why did we do this again?" conversations later.
The Meta-Decision
Sometimes the most important decision is: who should make this decision?
Not every decision needs consensus. Not every decision should be made by the most senior person.
My rule: Decision rights go to whoever has:
- The context to understand the tradeoffs
- The accountability for the outcome
- The ability to course-correct if wrong
Often that's the person closest to the work, not the person with the fanciest title.
Most project failures aren't from making wrong decisions. They're from not making decisions at all — letting things drift until options run out. Decide. Learn. Adjust. Repeat.