Ladder of Inference
We climb from a few selected facts to firm beliefs in seconds; walk back down the ladder together to resolve disagreement.
To an executive
Disagreements often come from people noticing different facts and making different assumptions, not from bad judgement. Comparing how each person got there resolves more than arguing conclusions.
To an engineer
In a design dispute, ask what data each person looked at and what they assumed. Compare those first, and check your own leaps before defending a position.
The idea
Chris Argyris described how people move from observation to action in a series of quick, mostly invisible steps. Peter Senge's The Fifth Discipline made it widely known. Climbing from the bottom:
- Data — everything that could be observed.
- Selected data — what we notice.
- Meaning — what we take it to mean.
- Assumptions — what we add, often unexamined.
- Conclusions — what we decide is true.
- Beliefs — what we now hold about the world.
- Actions — what we do because of them.
There is a loop: our beliefs shape which data we notice next time, so the ladder tends to confirm itself.
Why it works
Disagreement is usually high on the ladder. Two architects arguing about "the right design" are often working from different selected data or different assumptions. Arguing conclusions gets nowhere; comparing rungs does.
It makes reasoning visible without blame. "Help me see how you got there" invites people to share data and assumptions instead of defending a position.
It slows down your own leap. Noticing that you jumped from one slow query to "this team can't build performant systems" is the first step to checking it.
Where it applies
- Design reviews where two strong opinions collide.
- Stakeholder conflicts, such as a business owner convinced the platform team is blocking them.
- Incident reviews, to separate what the logs showed from what people concluded.
How to apply
- Notice which rung you are on when you feel certain.
- Share your reasoning from the bottom: the data you saw, what it meant to you, and what you assumed.
- Ask for theirs the same way: "What did you see that led you there?"
- Find the rung where you diverge, and test that step — often with new data.
Example scenario
A product owner told the steering group that the integration team "doesn't care about our deadline". The architect asked what had led to that view.
It came from one data point: a ticket left in "waiting" for two weeks. The integration team had seen the same ticket as blocked on a missing contract from the vendor. Once both sides looked at the same ticket history, the argument became a request to the vendor, and it was resolved that week.
Questions to ask
- What data am I actually looking at, and what did I leave out?
- What did I assume to get from that data to my conclusion?
- What would they need to see to reach my conclusion — or me theirs?
When not to use it
- During an active incident, when you need decisive action more than a shared understanding; save the walk down for the review.
How it misleads you
Used as a weapon — "you're high on the ladder" — it becomes another way to win an argument. Apply it to your own reasoning first, and invite the other person down with you rather than pointing at them.
Further reading
Last reviewed · Suggest an improvement