The Feynman Technique for Learning Anything

I once sat in a meeting where an architect spent 45 minutes explaining a new caching strategy. He used the words "eventual consistency," "cache coherence protocol," and "invalidation topology" in every other sentence. When he finished, I asked: "So when a user updates their profile, how long until they see the change?"

He paused. "I'd have to check."

He understood the jargon but not the system. And that distinction is exactly what the Feynman Technique exposes.

The Technique

Richard Feynman was a Nobel Prize-winning physicist known not just for his discoveries but for his ability to explain complex ideas simply. His learning method has four steps:

Step 1: Choose the concept you want to learn.

Step 2: Explain it as if you're teaching it to a 12-year-old. No jargon. No technical vocabulary. Plain language. If you can't explain it simply, you don't understand it deeply enough.

Step 3: Identify where your explanation breaks down. These gaps are where your understanding is shallow. You were using jargon as a substitute for comprehension.

Step 4: Go back to the source material and fill those gaps. Then try explaining it again.

Repeat until your simple explanation is complete and accurate.

Why Jargon Hides Ignorance

Every field develops specialized vocabulary. In software engineering: microservices, event-driven architecture, CAP theorem, eventual consistency, idempotency. These terms are useful shortcuts among experts. But they're also hiding places.

When you say "we need an event-driven architecture," do you mean:

• Services communicate through a message broker asynchronously?
• We use the event sourcing pattern where state is derived from an event log?
• We trigger functions in response to database changes?
• Something you read in a blog post that sounded smart?

The Feynman Technique forces you to disambiguate. If you can't explain "event-driven architecture" without using those three words, your understanding is lexical, not conceptual.

Applied to Learning New Technology

When I need to learn a new technology -- say, Kubernetes -- I follow Feynman's steps literally.

Step 1: I want to understand what Kubernetes does and why.

Step 2 (first attempt): "Kubernetes is a system that manages containers across multiple servers. You tell it what you want running (like 'three copies of my web app'), and it figures out which servers to use. If a server dies, Kubernetes moves your stuff to another server automatically. It's like a hotel concierge for your applications -- you say what you need, and it handles the logistics."

Step 3: Where does my explanation break down? I glossed over how Kubernetes decides which server to use. I can't explain what happens during a rolling deployment. I don't understand how networking works between pods on different nodes.

Step 4: I go read specifically about the scheduler, deployment strategies, and pod networking. Not the whole documentation -- just the gaps.

Step 2 (second attempt): Now I can explain the scheduler's decision process in plain language. I can describe a rolling deployment as "replacing old versions one at a time, like changing tires on a moving car -- one wheel at a time so the car never stops." The networking gap is partially filled but I need another round.

Each iteration deepens my understanding precisely where it's weakest.

Applied to Code Reviews

The Feynman Technique transforms code reviews. When reviewing someone's PR, instead of just checking correctness, I ask: "Can you explain what this code does in plain English, without referring to the implementation?"

If they can: they understand what they built.
If they can't: there's a gap between what they wrote and what they intended.

I've caught more design problems through this question than through any amount of line-by-line review. A function that can't be simply explained is usually doing too much, or is structured in a way that obscures its purpose.

Applied to Technical Interviews

As an interviewer, I've adopted a Feynman-based approach. After a candidate solves a technical problem, I ask: "Now explain your solution to me as if I'm a smart product manager who doesn't write code."

The candidates who can do this are the ones who genuinely understand what they built. The ones who can't -- who can only describe their solution in code-level terms -- have a mechanical understanding that won't transfer to new problems.

As a candidate, the same principle applies: if you can explain your previous work simply, interviewers trust that you deeply understand it. If you lean on jargon, they suspect you're hiding behind terminology.

The Compound Effect on Communication

The Feynman Technique doesn't just improve learning. It improves every form of professional communication.

Documentation: Technical docs written with Feynman-level clarity are actually read and understood. Docs written in jargon are shelf-ware.

Architecture proposals: A design document that explains the system in plain language before diving into technical specifics is more persuasive and more likely to surface problems during review.

Cross-team communication: When you can explain your team's system to the product team, the design team, or the executives, you become invaluable. You're not just an engineer -- you're a translator between technical and non-technical worlds.

Mentoring: The best mentors explain complex ideas simply. The Feynman Technique is what makes that possible. You can't teach what you can't articulate clearly.

The Uncomfortable Discovery

The hardest part of the Feynman Technique is Step 3: discovering that you don't understand things you thought you did. This is uncomfortable. You've been using the term "RESTful API" for years, but when you try to explain REST constraints in plain language, you realize your understanding is fuzzy.

This discomfort is the signal that the technique is working. Every gap you discover and fill makes your knowledge more robust. Every concept you can explain simply is one you can apply flexibly.

The great mental model thinkers -- Munger, Feynman, Buffett -- all share this commitment to fundamental understanding over surface fluency. For a collection of these thinking principles organized by category, the principles section on KeepRule is a useful reference for building depth across multiple domains.

Start Today

Pick one concept you use regularly at work. Try to explain it in three sentences that a non-technical friend would understand. If you can't, you've just found your next learning opportunity.

The test of understanding isn't whether you can use a concept. It's whether you can explain it.

As Feynman himself said: "If you can't explain it simply, you don't understand it well enough."

Start explaining. The gaps will reveal themselves.