ワンクリックで
thinking-circle-of-competence
// Know the boundaries of your expertise and operate within them. Use when evaluating opportunities, making decisions outside your domain, or assessing when to defer to experts.
// Know the boundaries of your expertise and operate within them. Use when evaluating opportunities, making decisions outside your domain, or assessing when to defer to experts.
| name | thinking-circle-of-competence |
| description | Know the boundaries of your expertise and operate within them. Use when evaluating opportunities, making decisions outside your domain, or assessing when to defer to experts. |
The Circle of Competence, articulated by Warren Buffett and Charlie Munger, emphasizes knowing the boundaries of your genuine expertise. The key insight isn't about having a large circle—it's about knowing precisely where your circle ends. Operating within your circle leads to better decisions; operating outside it without recognizing it leads to costly mistakes.
Core Principle: "Know what you don't know. The boundaries of your circle are more important than its size." — Warren Buffett
Decision flow:
Decision to make? → yes → Inside your circle? → yes → Proceed with confidence
↘ no → Delegate, learn, or pass
↘ no → Not applicable
True competence through deep experience
Characteristics:
Example: Senior backend engineer
Inside circle:
- API design patterns that scale
- Database optimization strategies
- When to use caching vs. not
- Common failure modes in distributed systems
- Debugging production issues
Familiar but not expert
Characteristics:
Example: Same backend engineer
Edge of circle:
- Frontend performance optimization
- Basic security practices
- Cloud cost optimization
- Team management fundamentals
Dangerous territory
Characteristics:
Example: Same backend engineer
Outside circle:
- Mobile app development
- Machine learning model tuning
- Legal/compliance decisions
- Financial forecasting
What areas do you have experience in?
For each domain, ask:
| Question | Inside | Edge | Outside |
|---|---|---|---|
| Could I teach this to an expert? | ✓ | ||
| Have I made real decisions here? | ✓ | ✓ | |
| Do I know the failure modes? | ✓ | ||
| Can I predict second-order effects? | ✓ | ||
| Do I know what I don't know here? | ✓ | ✓ | |
| Is my knowledge current? | ✓ |
Common self-deceptions:
Look at past decisions:
✓ Make decisions directly
✓ Move quickly
✓ Trust your intuition (it's trained)
✓ Teach and mentor others
✓ Push back on outside opinions if warranted
→ Seek input from those with deeper expertise
→ Validate assumptions before acting
→ Build in more margin for error
→ Document reasoning for review
→ Use this as learning opportunity
Option A: Delegate
- Find someone with this in their circle
- Trust their judgment
- Don't override without strong reason
Option B: Learn First
- Invest significant time (months/years)
- Get hands-on experience
- Make small decisions first, learn from mistakes
- Gradually expand circle
Option C: Pass
- Some opportunities aren't for you
- "I don't know enough" is valid
- Opportunity cost of learning may be too high
Your circle in one area doesn't extend to adjacent areas:
Inside: iOS development
Doesn't mean inside: Android development
Doesn't mean inside: iOS design
Doesn't mean inside: iOS project management
Circles shrink if not maintained:
2015: Expert in jQuery
2024: jQuery knowledge is inside, but modern frontend is edge/outside
Feeling confident ≠ being competent:
Dunning-Kruger peak: Know just enough to feel expert
Actually expert: Know enough to know how much you don't know
General intelligence doesn't expand circles:
Being smart at X doesn't make you competent at Y
Many smart people fail at investments, businesses, etc.
because they operate outside their circle confidently
Question: Should we adopt GraphQL?
Self-assessment:
- Have I built and maintained GraphQL at scale? No → Outside
- Do I know the failure modes? No → Outside
- Have I seen it succeed/fail in similar contexts? Partially → Edge
Decision: Consult with team members who have deep GraphQL experience,
or run small pilot before committing
Question: Should I become a manager?
Self-assessment:
- Have I led teams before? A little → Edge
- Do I know management failure modes? Not really → Outside
- Can I predict what makes a good manager? Vaguely → Edge
Decision: Don't assume IC success transfers; seek mentorship,
start with small team, treat as learning opportunity
Question: Should I invest in this startup?
Self-assessment:
- Do I understand this market? Superficially → Edge
- Can I evaluate the technology? No → Outside
- Do I know startup failure modes? Generally → Edge
- Have I made successful startup investments? No → Outside
Decision: This is outside my circle; either pass or find
co-investors who have this in their circle
"What counts for most people in investing is not how much they know, but rather how realistically they define what they don't know."
The advantage comes not from having the biggest circle, but from staying inside whatever circle you have—and knowing exactly where the boundary is.
Recognize Senge's Systems Archetypes to diagnose recurring organizational and technical problems, identify why fixes keep failing, and design interventions that address root structure.
Update beliefs systematically based on new evidence using probabilistic reasoning. Use when estimating probabilities, learning from data, or making decisions under uncertainty.
Apply Herbert Simon's Bounded Rationality and satisficing to make good-enough decisions under real-world constraints. Use for design decisions under time pressure, recognizing cognitive limits, and setting appropriate stopping criteria.
Classify problems by complexity domain (clear, complicated, complex, chaotic) and match approach to domain. Use for choosing methodologies, problem framing, and process design.
Systematic checklist to identify and counteract cognitive biases in decision-making. Use before major decisions, when evaluating recommendations, or when stakes are high.
Apply Kahneman's Dual-Process Theory to recognize when to trust intuition vs engage deliberate analysis. Use for high-stakes decisions, error-prone contexts, or when balancing speed vs accuracy.