Three years ago, I hit a wall. Not technically — technically I was fine. I was a senior developer shipping features and reviewing code. But I kept making the same kinds of bad decisions on repeat. Overcommitting to timelines. Saying yes to projects I should have declined. Choosing tools based on excitement rather than fit. Each mistake felt different in the moment, but when I looked at them together, the patterns were obvious.
I was treating every decision as a unique event. Considering each one from scratch, using whatever mental framework happened to be accessible at the time. Sometimes that was careful analysis. Sometimes it was gut feel. Sometimes it was "whatever gets this decision off my desk fastest."
What I needed was a system. Not a productivity hack or a mental model — a complete operating system for how I make decisions. Something that handles inputs, applies consistent processing, generates outputs, and includes feedback loops for continuous improvement.
Here's the system I built. It's been running for two years now, and the difference in decision quality is measurable. Not marginal — measurable.
The Architecture
Like any operating system, this has layers. Each layer handles a different aspect of decision-making.
┌─────────────────────────────────────┐
│ FEEDBACK LOOP │
│ (Review → Learn → Adjust) │
├─────────────────────────────────────┤
│ OUTPUT LAYER │
│ (Decision + Rationale + Review) │
├─────────────────────────────────────┤
│ PROCESSING LAYER │
│ (Rules, Models, Frameworks) │
├─────────────────────────────────────┤
│ INPUT LAYER │
│ (Classify → Prioritize → Prep) │
├─────────────────────────────────────┤
│ ENVIRONMENT LAYER │
│ (Time, Energy, Stakes, Context) │
└─────────────────────────────────────┘
Let me walk through each layer.
Layer 1: The Environment Layer
Before processing any decision, assess the conditions you're operating under. This is the equivalent of checking system resources before launching a process.
Time assessment: When during the day is it? Research consistently shows decision quality degrades throughout the day. If it's after 3 PM and the decision isn't urgent, schedule it for tomorrow morning. This single rule has eliminated roughly a third of my bad decisions.
Energy assessment: How many decisions have you already made today? After a morning of PR reviews and architecture discussions, you're depleted whether you feel it or not. Rate your energy honestly: fresh, moderate, or depleted. Depleted means only urgent, low-stakes decisions get processed.
Stakes assessment: What's the cost of getting this wrong? I use a simple scale:
- Low: Easily reversible within a day. Decide quickly, don't agonize.
- Medium: Reversible within a week but with meaningful friction. Give it structured thought.
- High: Difficult or impossible to reverse. Months of consequence. Full processing pipeline required.
Context assessment: Are you under social pressure? Emotional? Excited about a new technology? Any strong emotional state is a flag. Not a stop signal, but a flag that says "apply extra scrutiny to this decision."
Layer 2: The Input Layer
Once the environment checks pass, process the incoming decision through three steps.
Step 1: Classify
Every decision falls into one of four categories:
Binary decisions (yes/no, go/no-go): These are simpler than they appear. The key question is "what's the default?" If you're deciding whether to add a new dependency, the default should be "no" — and the burden of proof is on "yes." Establishing clear defaults for binary categories saves enormous cognitive energy.
Selection decisions (pick one of N options): The key here is ensuring you've actually identified all viable options. The biggest failure mode isn't picking the wrong option — it's never considering the right one. Force yourself to list at least three alternatives before evaluating.
Allocation decisions (how much time/resources/attention to give): These are the sneakiest because they feel like they don't have discrete options. But they do. "How much time should we spend on testing?" can be framed as "Which of these three testing strategies matches our risk tolerance?"
Design decisions (open-ended creative choices): Architecture, API design, user experience. These require the most cognitive resources and should be scheduled for peak energy times. They also benefit most from sleeping on them.
Step 2: Prioritize
Not all decisions deserve equal attention. Use the stakes assessment from the environment layer:
- Low stakes: Apply the two-minute rule. If you can decide in two minutes, do it now. Don't add it to a list. Don't schedule a meeting.
- Medium stakes: Schedule 15-30 minutes of structured thinking. Use a framework (see Processing Layer).
- High stakes: Full processing pipeline. Written analysis, premortems, outside perspectives, sleeping on it.
The most common mistake I see — and that I used to make constantly — is giving medium-stakes decisions high-stakes treatment. This wastes cognitive resources and creates decision bottlenecks. Not every technical choice deserves an architecture review.
Step 3: Prepare Information
For medium and high-stakes decisions, gather information before processing. But set a hard boundary on information gathering. Unlimited research is a form of decision avoidance.
My rule: for medium-stakes decisions, 30 minutes of research maximum. For high-stakes decisions, one day. If I don't have enough information after that, the question isn't "do I need more information?" — it's "can this decision be broken into smaller, lower-stakes decisions that require less information?"
Layer 3: The Processing Layer
This is where decisions get made. I maintain a library of processing tools, organized by decision type.
For Binary Decisions: The 10/10/10 Framework
How will I feel about this decision 10 minutes from now? 10 months from now? 10 years from now? This framework is simple but remarkably effective at separating emotional reactions from lasting consequences. Most decisions that feel scary in the moment (saying no to a colleague, pushing back on a deadline) look obviously correct from the 10-month perspective.
For Selection Decisions: Weighted Criteria Matrix
List your options as columns and your evaluation criteria as rows. Weight each criterion by importance. Score each option against each criterion. Total the weighted scores.
This sounds mechanical, and it is. That's the point. The matrix forces you to make your evaluation criteria explicit, which prevents the halo effect (where one impressive aspect of an option colors your entire evaluation) and ensures you're comparing options on the same dimensions.
For Allocation Decisions: Regret Minimization
Ask: "Which allocation would I regret least in six months?" This reframes the decision from optimizing outcomes (which requires predicting the future) to minimizing regret (which only requires understanding your own values).
For Design Decisions: The Premortem
Imagine it's six months from now and this design has failed spectacularly. Write down why it failed. This exercise is consistently the highest-value five minutes you can spend on any design decision. It surfaces risks that forward-looking analysis misses because your brain generates failure scenarios more easily than success scenarios.
Universal Tool: Decision Rules
For any category, pre-built decision rules shortcut the entire processing pipeline. "We don't adopt technologies unless someone on the team has production experience." "We don't extend deadlines without cutting scope." "We default to the boring, proven option unless there's a specific, documented reason to choose otherwise."
Every decision rule I maintain represents a category of decisions I've stopped thinking about individually. The cognitive savings are substantial.
Layer 4: The Output Layer
A decision isn't complete until it's documented. Every medium and high-stakes decision gets a written record:
## Decision: [What was decided]
**Date:** [When]
**Category:** [Binary/Selection/Allocation/Design]
**Stakes:** [Low/Medium/High]
**Context:** [Relevant constraints and conditions]
**Alternatives Considered:** [What else was on the table]
**Rationale:** [Why this option]
**Premortem Notes:** [What could go wrong]
**Confidence:** [1-10]
**Review Date:** [When to evaluate this decision]
This takes five minutes. The value it provides during review is worth hours.
Layer 5: The Feedback Loop
Every month, I spend one hour reviewing decisions from three months prior. This is the part that makes the whole system work. Without the feedback loop, you're just making documented guesses. With it, you're running an improvement cycle.
The review process:
- Read the decision record. Remember what you were thinking at the time.
- Assess the outcome. Was the decision clearly right, acceptable, or wrong?
- Identify the cause. If wrong, was it bad reasoning, bad information, bad luck, or a bias you can name?
- Update your system. Do you need a new decision rule? A different framework? An adjustment to your stakes calibration?
After two years of monthly reviews, I've identified my three most consistent failure modes:
- Overconfidence in my ability to reverse decisions later
- Underweighting operational concerns relative to features
- Making high-stakes decisions after 3 PM
Each of these has a corresponding rule in my system that compensates for the pattern.
Tools and Implementation
You don't need special software for this. A directory of markdown files works. A spreadsheet works. What matters is consistency.
That said, I've found it valuable to use purpose-built tools for managing decision rules specifically. KeepRule has been useful for organizing my processing-layer frameworks and maintaining my library of decision rules in a way that's easier to reference than scattered markdown files. The prompt-based structure maps well onto how I actually use decision frameworks — I need the right framework to surface at the right moment, not buried in a document I'll forget to open.
The specific tool matters less than the practice. What matters is:
- Decisions are classified before processing
- Processing uses explicit frameworks, not gut feel
- Outputs are documented
- Feedback loops are regular and honest
Why This Works
This system works for the same reason software works: it replaces inconsistent ad-hoc processes with repeatable, improvable systems. A human brain doing ad-hoc decision-making is like a developer writing code without version control — it might work, but you can't track what happened, learn from mistakes, or reliably improve.
The system doesn't eliminate bad decisions. Nothing does. But it eliminates categories of bad decisions — the ones caused by fatigue, by bias, by insufficient information gathering, by failing to consider alternatives. Those account for the majority of poor decisions most people make.
After two years of running this system:
- My overconfidence calibration has improved significantly (I now estimate difficulty more accurately)
- I've reduced time-pressure decisions by roughly 70% (by identifying which decisions are actually urgent)
- My technology evaluation accuracy has improved (by consistently using operations-first assessment)
- Decision-related stress has decreased (because the system handles the "how should I decide?" meta-decision)
Getting Started
You don't need to implement the whole system at once. Here's the minimum viable decision OS:
Week 1: Start documenting medium and high-stakes decisions. Just the decision, rationale, and a review date.
Week 2: Add the environment check. Before any significant decision, assess: time of day, energy level, stakes, emotional state.
Week 3: Add one processing framework. I recommend the premortem — it's the highest value-to-effort ratio of any decision tool I've used.
Month 2: Start monthly reviews of decisions from the prior month.
Month 3: Build your first decision rules based on patterns you've noticed.
Month 4+: Continue expanding. Add classification. Add more frameworks. Refine your rules.
The first month feels like overhead. The second month feels useful. By month three, you'll wonder how you ever made decisions without a system. Not because the system is magic, but because it makes the quality of your thinking visible — and visibility is the prerequisite for improvement.
I'm curious whether other developers have built similar systems. What does your decision process look like, and what tools do you use? I'd especially love to hear from people who've tried formal decision journaling — what surprised you most about your own patterns?
Top comments (0)