CHAPTER 10
Talk Five: The Need for More Multidisciplinary Skills from Educational Professionals
Read It
If I had to choose between letting a smart person keep digging deeper into one discipline or helping them master the core models of several, I'd pick the second. Not because the first is worthless, but because its ceiling is too obvious. In this chapter Munger stops scolding elite education and moves the problem forward: if hammer-thinking is harmful, how exactly do we train people out of it? His answer isn't "read more books." It's to train people like pilots—to make cross-disciplinary competence a set of hard requirements that must be passed, must be retested, and must be allocated effort according to risk.
Open full image ↗Draw It
In prose, "knowing" and "being able to use" get compressed into the same thing. Munger's emphasis on real fluency, forward-and-reverse reasoning, and prioritizing effort by importance collapses into a single phrase: "be interdisciplinary." The diagram separates them into different training demands: breadth is the entry point, fluency is the threshold, reverse reasoning is the test, and risk-based prioritization determines which model gets called first when a problem appears. Checklists and periodic retraining show this isn't a one-time acquisition.
Rethink It
In technical design reviews, plenty of people can recite the CAP theorem and list several cache-penetration solutions. But in a concrete scenario, they still reach for their most familiar hammer. A read-heavy system gets sharded from day one, because that's what the architect knows best. Munger's "prioritize effort by importance" translates to: first identify whether the biggest risk is consistency, availability, or scalability, then decide which discipline's core models to deploy. It's not a knowledge gap; it's a training gap.
Take It With You
The real bottleneck in cross-disciplinary education isn't a lack of courses. It's that no one takes responsibility for deciding which models must be fluent enough to be called up automatically. Academia imports a few concepts here and there, like a codebase with random libraries pulled in—they work, but nobody maintains the dependencies.