Tech culture has an embarrassing fetish for borrowed thinking.
Walk into any architectural review or product sync, and you’ll witness the same ritual. Someone drops an acronym like RICE, quotes Charlie Munger out of context, or invokes “first principles” like they’re summoning an ancient pagan deity. Everyone nods solemnly. A spreadsheet appears, weighted scores get tweaked until the outcome conveniently matches whatever the highest-paid person in the room already wanted, and the team marches off a cliff feeling deeply rational about it.
It’s theater. Most people in this industry don’t actually know how they make choices. They don’t have a framework; they have a security blanket.
Recently, Nish Tahir wrote about building your own decision model, and it hit a nerve because it exposed the dirty secret behind modern tech leadership: we’ve outsourced our judgment to public-domain mental crutches because taking personal responsibility for an outcome is terrifying.
Here’s the hard truth: every generic framework you pull off Twitter or read on Farnam Street is designed for someone else’s context, someone else’s risk tolerance, and someone else’s bank account. If you want to stop wandering into easily avoidable disasters, you have to build your own decision model from the ground up.
The Illusion of the Turnkey Framework
The appeal of off-the-shelf frameworks is obvious. They absolve you of guilt. If you use a standard scoring rubric and the project catches fire six months later, hey, don’t blame me—the matrix said it was a high-impact, low-effort slam dunk!
It’s corporate cover-your-ass hygiene disguised as intellectual rigor.
A real decision model isn’t a spreadsheet formula where you punch in arbitrary numbers between 1 and 5 to spit out a roadmap. A real model is an explicit codification of your principles, your blind spots, and your non-negotiables. It’s an engine designed to answer one question: Given what I value and what I cannot afford to lose, how do I evaluate this trade-off?
Notice that word: trade-off.
If your decision-making process doesn’t cause you active discomfort, you aren’t making a decision. You’re just rubber-stamping the obvious path. A good model forces you to name the sacrifice. Are you trading developer velocity for system reliability? Are you burning customer goodwill today for cash runway tomorrow? When you use somebody else’s framework, those trade-offs stay hidden in the margins. When you construct your own, you’re forced to look them directly in the face.
How to Actually Build One (Without the Fluff)
Building a personal decision model doesn’t require a master’s degree in systems engineering. It requires honesty, which is significantly rarer.
First, define your anti-goals. Most people start by listing what they want. That’s a mistake, because everyone wants the same garbage: scale, speed, money, impact. Start with what you refuse to tolerate. Do you refuse to manage complex distributed state? Do you refuse to work with vendors whose support is a Discord server? Do you refuse to ship features that lock users into predatory data contracts? Write them down. Your anti-goals immediately eliminate 70% of the noise before you even have to think hard.
Second, classify reversibility ruthlessly. Jeff Bezos talked about one-way and two-way doors years ago, and tech bros have beaten the analogy to death, but almost nobody actually implements it. Most teams treat lightweight experiments like permanent architectural commitments, and treat irreversible migrations like whimsical weekend side projects. Your model needs an explicit speed bump for asymmetry: if the downside of being wrong is existential, consensus and deliberation are required; if the downside is an afternoon of git reverts, make the call in five seconds and move on.
Third, audit your post-mortems. Look back at the last three terrible calls you made. Why did they fail? Did you underestimate operational complexity? Did you talk yourself into trusting an unproven library because the README looked slick? Did you defer to an authority figure you knew was out of touch? Your decision model must contain guardrails specifically tailored to your personal failure modes. If you tend to over-engineer, your model needs a mandated “minimum viable stupidity” test.
Stop Outsourcing Your Agency
The modern software landscape is designed to turn your brain into mush. We have LLMs writing our copy, cloud providers abstracting our infrastructure, and venture capitalists telling us which buzzwords to paste into our slide decks.
If you don’t intentionally build the mechanism by which you navigate ambiguity, the machine will make your choices for you. You’ll default to the path of least resistance, ship bloated software, manage disengaged teams, and wonder why everything feels slightly mediocre.
Build the framework yourself. Calibrate it against your scars. Break it when the world changes, and rebuild it better. Just stop pretending someone else’s book report is going to save you from having to think.
Hot take: The engineers and managers who post the most threads about “mental models” are invariably the ones least capable of making a hard call under pressure—they’ve spent so much time studying the anatomy of a hammer that they’ve forgotten how to drive a nail.