Ask: and then what?
Second-Order Thinking
Every decision has consequences, and those consequences have consequences. Train yourself to see past the obvious first move.
First-order thinking stops at the immediate outcome. Second-order thinking asks: if that happens, what happens next? And then what after that? Most decisions that feel obviously correct to everyone in the room are only obviously correct at the first order.
The method
After deciding on any significant action, map the consequences. First order: what is the direct, immediate effect? Second order: what does that first-order outcome trigger? Third order (if relevant): what cascade does the second-order outcome set off? Usually two levels is enough. Rare decisions warrant three.
The classic trap
Cobra effect: the British government in colonial India offered a bounty for dead cobras to reduce the cobra population. First order: people kill cobras. Second order: people breed cobras to kill them for the bounty. Third order: when the programme is cancelled, breeders release their cobras. Cobra population rises. Many well-intentioned policies fail exactly this way.
Speed and complexity
Second-order thinking slows you down. That is often the point. Decisions with long time horizons and high reversibility cost — staff changes, architectural choices, pricing models — deserve second-order analysis. Tactical decisions that are easy to undo do not.
In engineering leadership
Adding headcount: first order — more people, more output. Second order — coordination cost rises, onboarding reduces senior eng bandwidth, communication paths increase quadratically. The output increase is smaller than expected, the friction increase is larger. This isn't a reason not to hire; it's a reason to sequence it correctly.
In practice
Introducing a code freeze before a major launch. First order: reduced deployment risk. Second order: engineers batch risky changes just before the freeze, creating a spike of risk right before it starts. Third order: the freeze culture makes engineers delay work to avoid the spike, slowing overall velocity. Map this before you announce the policy.
TL;DR
Every outcome has outcomes. Ask 'and then what?' twice before committing.