Here's something that's been bothering me for years: two developers with identical years of experience can have wildly different decision-making speed and quality. One agonizes over every library choice. The other picks confidently and moves on, and they're usually right.
We tell ourselves the fast one just "has more experience." But that's a lazy explanation. I've met 15-year veterans who are paralyzed by every technical choice and 5-year developers who cut through ambiguity like a scalpel.
Last year, I set out to understand why. I interviewed 43 senior and staff engineers across companies ranging from early-stage startups to FAANG. I asked them one question: "Walk me through how you made your last significant technical decision."
The patterns that emerged had almost nothing to do with experience. They had everything to do with decision frameworks.
The Experience Myth
Let me be clear: experience matters. Pattern recognition is real. But experience is necessary, not sufficient, for fast, quality decision-making.
Here's what I observed. Engineers who relied primarily on experience ("I've seen this before, so I know the answer") had two failure modes:
- False pattern matching. The current situation looked like a past situation but had critical differences they missed.
- Paralysis in novel situations. When they hit something genuinely new, they had no process. They'd stall, seek consensus, or defer to whoever spoke loudest.
Engineers with decision frameworks handled both scenarios. They were fast on familiar problems AND unfamiliar ones. That's the giveaway that something beyond experience is at work.
What the Best Decision-Makers Actually Do
From my interviews, five distinct practices separated the fastest, most accurate decision-makers from everyone else.
1. They Classify Before They Decide
The number one pattern across all 43 interviews: fast decision-makers immediately classify the type of decision before engaging with the specifics.
One staff engineer at a fintech company described it this way: "The first thing I do is figure out if this is a one-way door or a two-way door. If it's reversible, I decide in minutes. If it's irreversible, I slow down and bring in other perspectives."
This framework comes from Jeff Bezos, and most senior engineers have internalized some version of it. But the best ones go further. They classify across multiple dimensions:
- Reversibility: Can we undo this? How expensive is the undo?
- Blast radius: If we're wrong, what breaks? One service? The platform? Customer trust?
- Time sensitivity: Does deciding next week cost us anything meaningful?
- Information curve: Will waiting a week give us significantly better information?
A principal engineer at a cloud infrastructure company told me she maps every decision on a 2x2 grid: reversibility vs. blast radius. Low reversibility, high blast radius gets her full analytical treatment. Everything else gets a 30-minute timebox.
2. They Use Premortems Instead of Pros/Cons Lists
Not a single fast decision-maker mentioned using traditional pros/cons lists. Every single one used some form of premortem or inversion.
Instead of "What are the benefits of choosing Kafka vs. RabbitMQ?", they ask "It's six months from now, and our messaging system is a disaster. What went wrong?"
One senior engineer explained why: "Pros/cons lists are symmetric, but decisions aren't. The cost of being wrong is almost never equal to the benefit of being right. A premortem forces you to think about the asymmetry."
This is a critical insight. When you're choosing between two message brokers, the pros might be similar. But the failure modes are completely different. Kafka failures look like consumer lag, partition rebalancing storms, and offset management nightmares. RabbitMQ failures look like memory exhaustion, queue buildup, and clustering headaches.
Understanding the failure modes tells you which system your team can actually operate, which is usually the right choice.
3. They Define "Good Enough" Before Starting
Fast decision-makers set explicit criteria for what constitutes a good-enough decision before they start evaluating options. Slow decision-makers evaluate options and then try to figure out which is best.
The difference is enormous. Without predefined criteria, you fall into satisficing traps, where every option looks flawed because you keep finding new evaluation dimensions.
One architect I interviewed uses what she calls a "decision spec" for any choice that will take more than an hour to make:
Decision: Which database for the new analytics service?
Must-haves: Handles 50K writes/sec, SQL-compatible, managed option available
Nice-to-haves: Column-oriented, supports materialized views
Dealbreakers: Requires dedicated DBA, no managed cloud option
Timeline: Decide by Friday
She told me: "Once I write this down, the decision usually makes itself. Ninety percent of the time, only one option meets all the must-haves without hitting a dealbreaker."
4. They Separate the Decision from the Commitment
This was the most subtle pattern and, I think, the most powerful.
Senior developers distinguish between deciding and committing. They'll make a tentative decision early, maybe within hours, and then test it before committing. The testing isn't exhaustive research. It's a quick spike, a conversation with someone who's used the technology, or a 30-minute prototype.
A staff engineer at a logistics company described his process: "I decide fast, commit slow. I'll say 'I think we should use X' within the first day. Then I spend two to three days poking holes in that decision. If it survives, we go. If it doesn't, I'm only out a few days, not weeks of analysis."
Compare this to the common antipattern: spending two weeks in analysis mode, making a decision, and then being so invested in the sunk cost of analysis that you never question it.
The decide-fast-commit-slow approach means your testing is targeted. You know what you're testing (your tentative decision), and you know what would change your mind (the criteria from step 3).
5. They Maintain a Decision Journal
This was the one I didn't expect. About a third of the engineers I interviewed, and nearly all of the ones I'd rate as truly exceptional decision-makers, keep some form of decision journal.
The practice is simple. When you make a significant decision, write down:
- What you decided
- Why you decided it
- What alternatives you considered
- What you expect to happen
- What would tell you the decision was wrong
Then, three to six months later, review it.
One principal engineer showed me a spreadsheet with 200+ entries spanning four years. "This is how I actually learned from experience," she said. "Without this, I would have the same one year of decision-making experience repeated fifteen times."
The journal creates a feedback loop that raw experience doesn't provide. Most decisions play out over months. By the time the consequences are visible, you've forgotten your original reasoning. The journal preserves it.
I've since found that this practice has roots in investment philosophy. Investors like Ray Dalio and Warren Buffett have long advocated for systematic decision logging. There's an interesting collection of decision-making scenarios and frameworks that maps these investment-world practices to other professional contexts, which is what initially convinced me the technique could translate to engineering.
The Framework Behind the Frameworks
If I had to distill all 43 interviews into a single process, it would be this:
Step 1: Classify (5 minutes)
What type of decision is this? Reversible or irreversible? High blast radius or low? Time-sensitive or not?
Step 2: Spec (15 minutes)
What are the must-haves, nice-to-haves, and dealbreakers? What does "good enough" look like?
Step 3: Tentative Decision (30 minutes to 1 day)
Based on what you know now, what would you choose? Write it down with your reasoning.
Step 4: Targeted Testing (1-3 days for big decisions)
Specifically try to break your tentative decision. Talk to people who've used the technology. Build a quick spike. Look for dealbreakers.
Step 5: Commit or Pivot (30 minutes)
Did your decision survive testing? Commit and move on. Did it break? You learned something specific. Make a new tentative decision and test again.
Step 6: Record (10 minutes)
Log the decision, your reasoning, and your expectations. Set a calendar reminder to review in three to six months.
The entire process for a major decision (database choice, architecture pattern, build vs. buy) takes three to five days. For a minor decision (library choice, API design detail), it takes an hour.
Why This Matters More Than Experience
Frameworks are transferable in ways that experience isn't.
When a senior React developer moves to a backend role, their frontend experience doesn't directly help with database choices. But their decision-making framework does. They still know how to classify decisions, define criteria, run premortems, and test tentative choices.
This is why some engineers seem to "level up" fast in new domains while others struggle despite decades of total experience. It's not intelligence. It's not even adaptability. It's that they've built a decision-making process that works independent of domain knowledge.
How to Start
If you want to build these skills, start small:
This week: Write a decision spec for the next technical choice you face. Define must-haves and dealbreakers before evaluating options.
This month: Start a decision journal. Even a simple text file works. Log every significant technical decision with your reasoning and expectations.
This quarter: Practice premortems. For your next architecture review, spend 20 minutes on "It's six months from now and this failed. Why?"
This year: Review your decision journal quarterly. Look for patterns. Where are your predictions accurate? Where do they consistently miss?
The framework compounds. After six months, you'll notice you're making decisions faster. After a year, you'll notice you're making better decisions. After two years, people will describe you as someone with great technical judgment.
They'll think it's experience. You'll know it's the framework.
What's your decision-making process for significant technical choices? Do you have explicit frameworks, or do you mostly go by gut feel? I'd love to hear how others approach this, especially if you've found practices that work in high-stakes environments.
Top comments (0)