From Engineer to Architect · The Field Guide48 models · 7 categories
An architect makes decisions all day with incomplete information. The difference between a good
one and a bad one is rarely more data. It is recognising, in the moment, which invisible force is
bending your judgment, and having a name for it. This is the catalogue of those forces.
// the crux
The fourteen disciplines are how an architect behaves. These models are what you must recognise to behave that way. Learn to name them, and you start to see them coming.
// what is in here
Forty-eight models, biases, traps, and effects across seven categories, each in one line.
The Core 10 to master first, if you only have room for ten.
A deep-dive link wherever one of these already has a full essay on the site. Many already do.
The whole toolkit as one map: each model its own island, all wired back to where the decision gets made.The same person at three altitudes: apprentice developer, skilled engineer, architect. What changes between the stages is how many of these models they can see in the room.
How to use this. It is a reference, not a read. Skim it once to learn the names, then come back to it before a hard decision and ask which of these is in the room. Start with the Core 10. Follow the deep-dive links where a model has its own essay. It is the toolkit behind the fourteen disciplines; the disciplines are how you behave, these are what you have to see first.
start here
// If you master ten
The Core 10
The highest-leverage models for an architect, drawn from across the categories below. If you only have room for ten, these are the ten. They shape not just technical decisions but people, incentives, risk, and the long game.
1
Cognitive Bias
Recognising that your own judgment is the first thing bending the decision.
Biases we knowingly, or half-knowingly, choose to apply. The cognitive ones happen to you; these you let happen. They power Discipline 11 – convince with data, not ego.
Political Bias
Supporting the decision that increases your own influence.
Department Bias
Optimising for your own team at the system’s expense.
Vendor Bias
Preferring the familiar technology or vendor over the fitting one.
Personal Preference Bias
Choosing a technology because you happen to like it.
Recency Bias
Favouring whatever worked the last time you tried it.
// a conscious bias in the wild
“I know Kubernetes isn’t needed here, but it’s good for my career growth.”
That is closer to a conscious bias than a cognitive one. Nothing about the judgment is mistaken – the engineer is right that it is not needed. The danger is that it will be dressed up as a technical argument in the review, and the real reason will never be said out loud.
// Category 3 · the spiral
Decision-Making Traps
Patterns that pull a group deeper into a bad decision. They power Discipline 8 – reduce decision turnaround, and know when to say no.
Sunk Cost Fallacy
Continuing because of what you have already spent, not what is left to gain.
Assuming everyone quietly agrees with you because nobody objected.
Planning Fallacy
Underestimating the time and effort, every single time.
// Category 4 · the ripple
Systems Thinking Effects
The ones an architect feels most. Consequences travel, incentives bite back, metrics rot. These power Discipline 4 – perspective over perception, the 360 degree view.
Butterfly Effect
A small change creating a wildly disproportionate outcome.
How systems actually break, and how we fool ourselves about it beforehand. These power Discipline 9 – inverted thinking: ask what could go wrong first.
Survivorship Bias · Core 10
Studying the systems that lived while the ones that died stay silent.
The forces that decide whether the truth reaches the decision. These power Discipline 12 and 13 – let the best idea win; be ego-free, blame-free, collaborative.
Psychological Safety
People speaking up with a doubt or a dissent without fear.
Often more valuable than any technical pattern. These power Discipline 2 and 3 – trade-off analysis, and knowing what pragmatism actually means. Six of the Core 10 live here.
Trade-Off Analysis · Core 10
Every decision optimises something while sacrificing something else.
Viewing the whole ecosystem, not the individual components.
Constraints Thinking
Using limits as a forcing function. Innovation often starts here.
Nobody recognises all forty-eight in the moment. That is not the point. The point is that the
architect who can name even a handful of these, out loud, in a room full of smart people heading
confidently toward a bad decision, is worth more than the one with the deepest stack of technical
patterns. The patterns change every few years. These do not. Learn the names. Then learn to say
them gently, at the right time.
// carry forward
This is the toolkit. The character that wields it is the other half of the field guide. Start with the discipline that governs all the rest: cognitive bias is enemy number one, and how to decide on merit, not momentum.