Mental Models for Engineers and Managers 🎲
My personal top 10, with drawings and a ton of resources.
I am a big fan of mental models, and over time I have built a small arsenal of favorites that I use in many situations.
To me, a mental model is like software for my brain. It is a thought process that I can run, under the appropriate circumstances, to get to some output.
Mental models are also popular with engineers — I suspect because of our familiarity with processes. As engineers, we don’t like ambiguity and uncertainty, so it is comforting to turn something messy into a deterministic series of steps.
So for today I am listing the mental models I like the most, together with the most popular ones in the Refactoring community.
For each model, I will explain it in detail, provide examples for engineering and management, create drawings whenever possible, and include further resources to learn more.
So, consider this post a compendium of the best mental models for engineers and managers in tech. You will be able to bookmark this and revisit it over time.
Here is the agenda:
🗺️ Map vs Territory — an important distinction, which also acts as a premise for this piece.
⚖️ Type 1 vs Type 2 — a Jeff Bezo-ism that also calls for bias for action, and asymmetric rewards.
🔭 Second-order thinking & first principles — two popular models, surprisingly connected.
↩️ Inversion — achieving the positive by avoiding the negative.
🥇 Binstack — making good, multi-dimensional decisions.
🪣 Sunk Cost Fallacy — spotting this cognitive bias in engineering and management.
🔗 Theory of Constraints — finding the weakest links, one at a time.
🌪️ Cynefin — turning chaos into best practices.
➕ Eisenhower Decision Matrix — using it to triage and delegate work.
⭕ Circle of Competence — the popular idea by Charlie Munger, and how it relates to your career.
⚡ Quick models — a lightning round of further simple ideas you can apply in a snap.
Let’s dive in!
🗺️ The Map is not the Territory
The Map is Not the Territory is a mental model that emphasizes the difference between our perceptions / models (the map) and the actual reality (the territory).
It is the first one that we are covering, for a reason. It reminds us that models are useful, but they are not the reality: their goal is to represent a slice of reality, in a way that is useful for a specific goal.
In other words, they are just tools — if you overstep their boundaries / goal, they may turn useless or even harmful.
This is true for all kinds of models, not just the big, high level frameworks we are covering today. We create models all the time:
💻 Software — when designing software, we model how the system works in the form of diagrams, docs, and even tests. However, these are not a perfect representation of the actual code. A diagram could help understand the structure of your codebase, but it may not be exhaustive about dependencies, which makes it insufficient to decide e.g. how to partition the system.
⏱️ Project management — we create plans, roadmaps, and resource estimates, to help us organize and deliver projects. However, these are not the projects themselves, and we must be prepared to adapt our plans if new information becomes available or unforeseen challenges arise.
Whenever you encounter a hard problem, focus on what you need to accomplish, and figure out what models / frameworks can be helpful.
⚖️ Type 1 vs Type 2
Type 1 vs Type 2 is a simple framework by Jeff Bezos to help with decision-making. It divides decisions into two categories:
🏆 Type 1 — irreversible decisions that represent a large amount of risk. They require thorough decision-making and careful consideration. Examples in tech may include choosing your database or committing to a specific stack.
🥈 Type 2 — reversible decisions that can be easily adjusted or undone if they don't work out as planned. They don't require excessive attention and can be made more quickly. Examples may include choosing between two similar tools, or making minor adjustments to a project.
The reason why this matters is that most decisions in life and work are Type 2, so you should move forward quickly with them, as opposed to applying the Type 1 decision-making style. In my experience, analysis paralysis on Type 2 stuff is way more common than the opposite — that is, being careless on irreversible decisions.
This mental model is similar, or correlated to other ones:
1) Bias for action
The general tendency to favor action over inaction. Type 2 decisions are bias for action material, while Type 1 ones are those where you stop and consider.
2) Asymmetric risk-reward
This was made popular by Nassim Taleb in Antifragile, and refers to the strategy of positioning yourself in situations where the potential losses are limited, while the potential gains are high or unlimited.
In other words, aim for capped downside + uncapped upside. This is ideal for Type 2 bets — where you potentially get a big benefit, but quickly cut your losses if things don’t work out.
🔭 Second-order Thinking + First Principles
Second-order thinking is about considering the future consequences of a decision, going beyond the immediate implications.
In engineering, this is literally the name of the game. Whenever you design a system, or create an abstraction, you are never only thinking at solving the problem here and now — you are also thinking at the impact on the larger system, on your team workload, on infrastructure, and more.
On a practical level, I know two ways to prompt second-order thinking: