Circle of Competence: Know What You Know

In 2015, I confidently told my team we should build our own search engine instead of using Elasticsearch. I'd read a few blog posts about inverted indexes. I understood the theory. How hard could it be?

Eight months later, we threw it all away and migrated to Elasticsearch in two weeks. The custom solution was slow, buggy, and impossible to maintain. I'd wasted half a year of engineering time because I confused "understanding a concept" with "having competence to execute on it."

That failure taught me the most important lesson of my career: knowing the boundary of what you actually know.

What the Circle Is

Warren Buffett and Charlie Munger use the term "circle of competence" to describe the domain where you have genuine, tested expertise. Inside the circle, you can make confident judgments. Outside it, you're guessing -- even if it doesn't feel like guessing.

Buffett has been remarkably disciplined about this. He avoided technology stocks for decades, not because he thought tech was bad, but because he knew he couldn't evaluate tech businesses with the same depth he could evaluate insurance companies or consumer brands. When others called him outdated, he shrugged. When the dot-com bubble burst, his restraint looked like genius.

But it wasn't genius. It was honest self-assessment.

The Three Zones

I think of competence in three concentric rings:

Core competence (inner ring): Things you've done repeatedly, in production, under pressure. You know the failure modes, the edge cases, the things that textbooks don't cover. For me: relational database design, REST API architecture, Go and Python backend systems.

Working knowledge (middle ring): Things you understand conceptually and could execute with some research and help. You know enough to ask the right questions but might miss subtle problems. For me: frontend frameworks, basic DevOps, message queues.

Awareness (outer ring): Things you've read about or explored casually. You could hold a conversation but shouldn't make critical decisions. For me: machine learning, distributed consensus algorithms, compiler design.

The danger zone isn't the outer ring -- you know you don't know those things. The danger zone is the boundary between the middle and inner rings. That's where you feel confident but aren't actually competent.

How It Shows Up in Engineering

Architecture decisions: The most expensive mistakes happen when someone designs a system outside their competence. A backend engineer designs the frontend architecture. A web developer designs the mobile app. A junior engineer designs the distributed system. The results are architectures that look reasonable on paper but fail in practice because they miss the hard-won lessons that come from experience in that specific domain.

Technology selection: Every year, teams adopt technologies they don't deeply understand because someone read a blog post or attended a conference talk. Event sourcing. CQRS. GraphQL. Kubernetes. These are all legitimate tools -- for teams that understand them. For teams outside their circle, they're complexity multipliers.

Hiring decisions: I've seen engineering managers hire for skills they can't evaluate because those skills are outside their own competence. They end up optimizing for interview performance rather than actual ability, because they lack the depth to tell the difference.

Expanding the Circle

The circle isn't fixed. You expand it through deliberate practice and real-world experience. But the expansion is slower than most people think.

Reading a book about distributed systems doesn't put distributed systems inside your circle. Building one toy project doesn't either. Running a distributed system in production for two years, debugging it at 3am, handling the failures that no documentation warned you about -- that's when it enters your circle.

The honest cadence:

1. Study a new area (weeks)
2. Experiment with toy projects (weeks to months)
3. Apply in low-stakes production scenarios (months)
4. Master through repeated production experience (years)

Skipping steps is how you end up with my search engine disaster.

Practical Rules

Here's what I do now:

For decisions inside my circle: Move fast. Trust my judgment. Don't over-analyze.

For decisions at the boundary: Slow down. Seek input from someone whose circle includes this area. Build a prototype before committing.

For decisions outside my circle: Either bring in someone who has genuine competence, or invest the time to develop it myself before making the call. Never fake it.

The honesty check: Before any significant technical decision, I ask myself: "Have I actually done this before in a real system, or have I just read about it?" The answer determines how confident I should be.

The Organizational Dimension

Circles of competence aren't just individual -- they're organizational. A company that's excellent at B2B SaaS may be incompetent at consumer mobile apps, even though they have smart engineers. The organizational knowledge, processes, and instincts are tuned for a different domain.

The best organizations I've worked in explicitly acknowledge their collective circle of competence. They don't try to do everything. They hire for the gaps. They partner where they're weak instead of pretending to be strong.

Connecting the Dots

Buffett's circle of competence principle connects to several other mental models: margin of safety (leave room for error when operating near the edge of your circle), inversion (ask "where am I most likely to be wrong?"), and incentive analysis (people are incentivized to overstate their competence).

If you want to explore how these principles interconnect, the principles collection on KeepRule maps these mental models by category. It's a useful reference for understanding not just individual models but how they reinforce each other.

The Hardest Part

The hardest part of the circle of competence isn't the intellectual framework. It's the ego management. Admitting "I don't know" in a room full of peers takes courage. Deferring to someone more junior because they have deeper expertise in a specific area takes humility.

But the alternative -- making confident decisions outside your competence -- is how careers and projects go sideways.

Know what you know. Know what you don't. Act accordingly.