skills/tjboudreaux/cc-thinking-skills/thinking-second-order

thinking-second-order

SKILL.md

Second-Order Thinking

Overview

Second-order thinking, articulated by Howard Marks, moves beyond immediate effects to consider what happens next, and what that leads to. First-order thinking is simplistic ("This action solves the problem"); second-order thinking asks "And then what?" repeatedly.

Core Principle: The obvious answer to "What should I do?" is often wrong because it ignores downstream effects.

When to Use

  • Making strategic or architectural decisions
  • Evaluating policy or process changes
  • Considering incentive structures
  • Planning features that change user behavior
  • Decisions with long-term consequences
  • When the "obvious" solution feels too easy

Decision flow:

Decision with consequences beyond immediate? → yes → APPLY SECOND-ORDER THINKING
                                            ↘ no → First-order may suffice

First vs Second-Order Thinking

Situation First-Order Second-Order
Team is slow Add more engineers More engineers → more coordination → slower decisions → may get slower
Users complain Add the feature they request Feature → complexity → more support load → less time for core work
Costs too high Cut spending Cuts → reduced quality → customer churn → revenue drop → worse situation
Bug in prod Hotfix immediately Hotfix → skip testing → more bugs → trust erosion → slower deployments

The Process

Step 1: Identify the Decision and First-Order Effect

Decision: Add a feature flag system
First-order: Teams can ship features independently ✓

Step 2: Ask "And Then What?"

Chain the consequences:

Feature flags → More flags created → Flag debt accumulates
             → Teams don't clean up → Combinatorial testing complexity
             → Bugs from flag interactions → "Turn it off" becomes risky
             → Flags become permanent → Codebase complexity explodes

Step 3: Apply the 10/10/10 Framework

Evaluate impact across time horizons:

Timeframe Question Analysis
10 minutes How will I feel right after? Relief—problem solved
10 months How will this affect things in 10 months? Flag sprawl emerging
10 years What's the long-term trajectory? Technical debt crisis

Step 4: Consider Systemic Effects

Ask: "What if everyone did this?"

Decision: Skip code review for urgent fixes
If everyone: All urgent fixes skip review
Result: Definition of "urgent" expands → most things skip review
Outcome: Quality collapses, more urgent fixes needed

Step 5: Map the Consequence Chain

┌─────────────────┐
│ Decision: X     │
└────────┬────────┘
┌─────────────────┐
│ 1st Order: A    │ ← Obvious, intended
└────────┬────────┘
┌─────────────────┐
│ 2nd Order: B    │ ← Less obvious
└────────┬────────┘
┌─────────────────┐
│ 3rd Order: C    │ ← Often counterintuitive
└────────┬────────┘
┌─────────────────┐
│ Feedback Loop   │ ← May reinforce or counteract
└─────────────────┘

Common Second-Order Effects in Software

Optimization

1st: Optimize critical path → Faster
2nd: Team focuses on optimization → Less feature work
3rd: Premature optimization spreads → Complexity increases
4th: Maintenance burden grows → Slower overall

Hiring

1st: Hire senior engineers → More capacity
2nd: Salary expectations rise → Budget pressure
3rd: Junior engineers feel stuck → Attrition
4th: Knowledge concentrated in seniors → Bus factor risk

Process Addition

1st: Add approval process → More oversight
2nd: Approvals create bottleneck → Slower delivery
3rd: People route around process → Shadow processes
4th: Formal process becomes theater → Worst of both worlds

Technical Shortcuts

1st: Skip tests to ship faster → Feature delivered
2nd: Bugs emerge → Support load increases
3rd: Team fights fires → Less time for features
4th: More shortcuts taken → Quality death spiral

Application Framework

For any significant decision, fill out:

## Second-Order Analysis: [Decision]

### Immediate Effect (1st Order)
[What happens right away]

### Near-Term Consequences (2nd Order)
[What does the immediate effect cause? 1-3 months]

### Medium-Term Consequences (3rd Order)  
[What do the near-term effects cause? 3-12 months]

### Long-Term Trajectory
[Where does this path lead? 1+ years]

### Feedback Loops
[Does this create reinforcing or balancing dynamics?]

### If Scaled
[What happens if this becomes standard practice?]

### Revised Decision
[Given analysis, what should we actually do?]

Questions to Surface Second-Order Effects

  • "And then what?"
  • "Who else is affected, and how will they respond?"
  • "What incentives does this create?"
  • "What behavior does this encourage/discourage?"
  • "If this works, what problems does success create?"
  • "What will we wish we had done differently in a year?"
  • "What does this look like if everyone does it?"

Verification Checklist

  • Identified first-order effect clearly
  • Asked "and then what?" at least 3 times
  • Applied 10/10/10 framework
  • Considered systemic/scaled effects
  • Identified potential feedback loops
  • Revised decision based on full consequence chain
  • Documented reasoning for future reference

Marks' Warning

"First-level thinking is simplistic and superficial, and just about everyone can do it. Second-level thinking is deep, complex, and convoluted."

The crowd uses first-order thinking. Competitive advantage comes from thinking one level deeper—seeing what happens after the obvious effect.

Weekly Installs
3
GitHub Stars
13
First Seen
6 days ago
Installed on
amp3
cline3
openclaw3
opencode3
cursor3
kimi-cli3