Thinking Backwards
Overview
Most people approach problems by asking "how do I succeed?" Inversion asks the opposite: "what would guarantee failure?" Then you avoid those things.
Charlie Munger, Warren Buffett's business partner, put it simply: "All I want to know is where I'm going to die, so I'll never go there." Instead of trying to be brilliant, figure out what would be catastrophic and steer away from it.
This is not pessimism. It is a practical thinking tool that reveals risks and failure modes that forward-thinking misses. When you invert a problem, you often discover that avoiding a handful of specific mistakes matters more than executing any particular strategy.
The Inversion Process
Forward thinking (normal approach):
"How do I build a successful product?"
→ Good design, fast performance, useful features,
marketing, user research...
→ The answer is vague and has too many variables.
Inverted thinking:
"What would guarantee this product fails?"
→ Ignoring user feedback after launch
→ Building features nobody asked for
→ Making it slow and unreliable
→ Changing the API every month
→ Not having any way to measure usage
Now invert the failures:
→ Establish continuous user feedback loops
→ Validate features before building them
→ Prioritize performance and reliability
→ Maintain API stability
→ Instrument everything from day one
The inverted version is more actionable because it gives you
specific things to avoid, not vague aspirations to pursue.
Applying Inversion to System Design
"What Would Cause an Outage?"
Instead of asking "how do I build a reliable system," ask "what would take this system down?"
Inverted question: What would guarantee our system goes down?
→ Single point of failure in the database
→ No health checks, so we don't know it's down until users complain
→ No rate limiting, so a traffic spike overwhelms everything
→ Deploying on Friday at 5pm with no rollback plan
→ Secrets hardcoded in the codebase that get rotated without a deploy
→ No circuit breakers, so one slow dependency cascades everywhere
→ Log volume so high that logging infrastructure itself fails
Now avoid those things:
→ Add database replicas with automatic failover
→ Implement health checks and alerting
→ Add rate limiting at the API gateway
→ Deploy during business hours with automated rollback
→ Use a secrets manager with dynamic rotation
→ Add circuit breakers on all external calls
→ Set log retention policies and rate limit log output
This approach is more thorough than forward thinking because failure modes are concrete and finite, while success strategies are abstract and infinite.
"What Would Make This Architecture Unmaintainable?"
Inverted question: How do I guarantee nobody can work on this
codebase in two years?
→ No documentation of architectural decisions
→ Clever code that optimizes for brevity over readability
→ Circular dependencies between modules
→ Business logic scattered across controllers, models, and views
→ No tests, so every change requires manual verification
→ Environment-specific code paths with no clear separation
→ Database schema with no migration history
Now avoid those things:
→ Write ADRs (Architecture Decision Records) for major choices
→ Optimize for readability; clever code is a liability
→ Enforce clear dependency direction between modules
→ Centralize business logic in a service layer
→ Write tests that cover critical paths
→ Separate configuration from code
→ Use a migration tool and never modify schemas manually
Applying Inversion to Hiring
"What Would Make This Hire Fail?"
Inverted question: What would guarantee this new hire doesn't
work out?
→ Hire purely on technical skill, ignore collaboration ability
→ No onboarding plan; throw them into the codebase on day one
→ Unclear expectations for the first 30/60/90 days
→ The role description doesn't match the actual work
→ No mentor or buddy assigned
→ Team has no documentation, so the new hire is dependent
on tribal knowledge they don't have access to
→ Manager doesn't meet with them regularly for the first months
Now avoid those things:
→ Evaluate collaboration in interviews (pair programming, design discussion)
→ Create a structured onboarding plan with clear milestones
→ Define what success looks like at 30, 60, and 90 days
→ Be honest about the role in the job posting and interviews
→ Assign a mentor who has dedicated time for onboarding
→ Invest in documentation before the hire starts
→ Schedule weekly 1:1s for the first three months minimum
Applying Inversion to Product Decisions
"What Would Make Users Leave?"
Inverted question: What would guarantee users abandon our product?
→ Break their existing workflows with a redesign
→ Make the product slower with each release
→ Ignore their feature requests and support tickets
→ Change pricing without warning
→ Lose their data
→ Force them to re-learn the interface regularly
→ Make it hard to export their data (they'll leave AND be angry)
Now avoid those things:
→ Introduce changes incrementally with opt-in periods
→ Set performance budgets and measure them in CI
→ Create visible feedback loops between users and the roadmap
→ Grandfather pricing for existing users or give advance notice
→ Invest heavily in backup, replication, and data integrity
→ Maintain UI consistency; evolve, don't revolution
→ Provide robust data export (this builds trust even if
they never use it)
Why Inversion Works
Reason 1: Failure modes are concrete, success factors are vague
"Build a great product" — how?
"Don't lose user data" — clear and actionable.
It's easier to enumerate what will definitely fail than
to enumerate what will definitely succeed.
Reason 2: Avoiding mistakes has a larger impact than pursuing excellence
A system with no single points of failure, decent monitoring,
and basic testing will be more reliable than a system with
brilliant architecture but a hardcoded password in the config.
Removing the worst failure modes improves outcomes more than
optimizing the best success factors.
Reason 3: It breaks optimism bias
Forward thinking tends toward "everything will work out."
Inversion forces you to confront "here's how it won't."
Teams that only think forward are surprised by failures.
Teams that also think backward have contingency plans.
Reason 4: It surfaces non-obvious risks
"What would guarantee our migration fails?"
→ "We don't have a rollback plan."
This is obvious once stated, but forward-thinking teams
often skip it because they're focused on how the migration
will succeed, not how it will fail.
The Inversion Checklist
Use this for any significant engineering decision.
Step 1: State the goal
"We want to successfully migrate from PostgreSQL to DynamoDB"
Step 2: Invert it
"What would guarantee this migration fails?"
Step 3: List failure modes
→ Migrate all tables at once instead of incrementally
→ No dual-write period, so rollback means data loss
→ Don't test with production-scale data
→ Assume DynamoDB access patterns match PostgreSQL query patterns
→ Don't train the team on DynamoDB's data modeling
→ No performance benchmarks before and after
→ Set an aggressive deadline with no buffer
Step 4: Invert the failure modes into actions
→ Migrate one table at a time, starting with the least critical
→ Run dual-writes for a transition period
→ Load test with production-scale data before cutover
→ Redesign data models for DynamoDB access patterns
→ Train the team; run workshops on single-table design
→ Benchmark read/write latency and cost before and after
→ Build buffer into the timeline for surprises
Step 5: Check your plan against the inverted list
Does our current plan avoid all the failure modes we listed?
If not, fix the plan.
Inversion in Daily Engineering
You do not need a formal exercise for every decision. The habit is simply asking the inverted question.
Before a code review:
"What would make this PR introduce a bug?"
→ Untested edge cases, missing error handling,
race conditions, implicit state dependencies
Before a sprint:
"What would make this sprint fail?"
→ Unclear requirements, blocked dependencies,
key person on vacation, no spike time for unknowns
Before a meeting:
"What would make this meeting a waste of time?"
→ No agenda, wrong people invited, no decision-maker present,
no follow-up actions documented
Before an on-call shift:
"What would make this on-call week terrible?"
→ No runbooks, no escalation path, noisy alerts
that wake you up for non-issues, no handoff notes
from the previous shift
Combining Inversion with Forward Thinking
Inversion is not a replacement for forward thinking. It is a complement.
Forward thinking tells you: what to build, what to aim for,
what the ideal outcome looks like.
Inverted thinking tells you: what to avoid, what to plan for,
what the failure modes look like.
The best engineering plans include both:
1. Here is our architecture and why we believe it will work.
2. Here is what would cause it to fail and how we've
mitigated each failure mode.
A plan without inversion is optimistic.
A plan with only inversion is paralyzed.
Use both.
Common Pitfalls
- Using inversion to justify doing nothing: Inversion reveals risks, not reasons to avoid all action. Every path has failure modes. The goal is to choose the path with manageable risks and mitigate them, not to find the path with zero risks (it does not exist).
- Only inverting once: Inversion is most powerful as a recurring habit, not a one-time exercise. Ask the inverted question before every sprint, every major PR, every architecture decision. The more routine it becomes, the more failure modes you catch early.
- Inverting too broadly: "What would guarantee our company fails?" is too broad to be useful. Invert specific decisions: "What would guarantee this database migration fails?" Specific inversions produce actionable insights.
- Stopping at the inversion without creating a plan: Listing failure modes is the first step. The value comes from converting each failure mode into a concrete mitigation. If you list "no rollback plan" as a failure mode but do not create a rollback plan, the inversion was wasted.
- Confusing inversion with pessimism: Inversion is pragmatic, not negative. A team that inverts their plans and addresses the failure modes is more confident in execution, not less. They know what can go wrong and have prepared for it.
Key Takeaways
- Inversion means asking "what would guarantee failure?" instead of "how do I succeed?" The inverted question produces more concrete, actionable insights because failure modes are specific and finite.
- Apply inversion to system design (what would cause an outage?), hiring (what would make this hire fail?), product decisions (what would make users leave?), and daily engineering (what would make this sprint fail?).
- Avoiding the worst mistakes has a larger impact on outcomes than pursuing the best strategies. A system without single points of failure and with basic monitoring beats a brilliantly architected system with a hardcoded password.
- Build inversion into your routine. Before every significant decision, spend five minutes listing failure modes and converting them into mitigations. This small investment prevents large problems.
- Inversion complements forward thinking; it does not replace it. The best plans describe both what you are building and what failure modes you have identified and mitigated.