Note: this is Part 1 in a series about tacit knowledge.
I want to spend an essay talking about tacit knowledge, and why I think it is the most interesting topic in the domain of skill acquisition. If you are a longtime Commonplace reader, you’ll likely have come across this idea before, because I’ve written about it numerous times in the past. But I think it’s still good idea to dedicate a whole piece to the topic.
The reason I think it’s important to write this piece is because every time I touch on the topic of tacit knowledge, inevitably someone will pop up on Twitter or Hacker News or Reddit or email and protest that tacit knowledge doesn’t exist. I want something to link to whenever I come up against someone who says this, mostly so that I don’t have to repeat myself.
There is one other reason I think it is good to explore what tacit knowledge is: tacit knowledge does exist, and understanding that it does exist is one of the most useful things you can have happen to you. Once you understand that tacit knowledge exists, you will begin to see that big parts of any skill tree is tacit in nature, which means that you can go hunting for it, which in turn means you can start to ask the really useful question when it comes to expertise, which is: that person has it; that person is really good at it; how can I have it too?
What is Tacit Knowledge?
Tacit knowledge is knowledge that cannot be captured through words alone.
Think about riding a bicycle. Riding a bicycle is impossible to teach through descriptions. Sure, you can try to explain what it is you’re doing when you’re cycling, but this isn’t going to be of much help when you’re teaching a kid and they fall into the drain while you’re telling them to “BALANCE! JUST IMAGINE YOU ARE ON A TIGHTROPE AND BALANCE!”.
Undoubtedly there will be people who say that if you just explain better, if you could find the right words to talk to your students, you can teach them to ride bikes. If you happen to believe this … well, I urge you to test this theory yourself. Go find a couple of kids (or adults!) who haven’t yet learned to ride a bike and see if you can teach them — through the power of your explanations alone! — how to cycle without scraping their shins. And if you are successful, be critical with yourself: how much of your success is due to the bike rider figuring it out on their own? And how much of it is due to your verbal instructions?
This explanation bit deserves some attention. In pedagogy, this is known as ‘transmissionism’, and it is regarded amongst serious educators with the same sort of derision you and I might have about flat-earth theories today. It goes something like this: some people believe that it is possible to teach technique by explaining things to others. They think that if you can find just the right combinations of words with the right sorts of analogies; if you can really break things down into the right level of atomic details, things will magically click in their students’s heads and they will succeed. Such people have likely never attempted to do so in a serious manner. And if you are one such person, then I hope that you pick up coaching at some point, in a sport that I am interested in, so that my kids can go up against your kids, and then I get to watch as they absolutely crush yours.
How do you teach tacit knowledge? How do you teach bike riding, for that matter?
When I was a kid, I taught myself how to ride a bike … by accident. And then I taught my sisters and then my cousin and then another kid in the neighbourhood who was interested but a little scared. They were zooming around in about an hour each. The steps were as follows:
- Pick a small bike, much smaller than the body of your learner, and therefore not far off the ground. This is useful for the learner because they will be able to put their feet down and save themselves at any moment. It’s also less scary to be not far off the ground.
- Have them push with their legs and go forward a short distance, again with their feet only inches off the ground. Do this repeatedly, by pushing off, putting both feet down, then stopping and repeating.
- Make the pushes harder and the distances longer. Eventually, they will spend tens of seconds gliding with their feet held up. The goal here is have them learn how it feels like to balance on a bike.
- On one of those glides, once they feel ready (and likely a little bored — the point is to get them to do step 3 so many times that they’re feeling secure and eager to move on) — well, once you reach that point, tell them to start peddling.
- Voilà. You have a bicycling kid.
Notice how little verbal instruction is involved. What is more important is emulation, and action — that is, a focus on the embodied feelings necessary to ride a bicycle successfully. And this exercise was quite magical for me, for within the span of an hour I could watch a kid go from conscious incompetence to conscious competence and finally to unconscious competence.
In other words, tacit knowledge instruction happens through things like imitation, emulation, and apprenticeship. You learn by copying what the master does, blindly, until you internalise the principles behind the actions.
You might see this and think “ahh, this works for physical things like cycling and tennis and Judo, but what about more cerebral things?” To which I say: tacit knowledge exists all around us. Researcher Samo Burja explains tacit knowledge by way of example: he calls it “the ability to create great art or assess a startup (…) examples include woodworking, metalworking, housekeeping, cooking, dancing, amateur public speaking, assembly line oversight, rapid problem solving, and heart surgery.”
If you are a knowledge worker, tacit knowledge is a lot more important to the development of your field of expertise than you might think.
Tacit Knowledge in Knowledge Work
It took me years before I realised that my method of teaching people to bicycle contained a number of principles that might be applicable to other domains.
In my previous job, my technical lead, Hieu, had an uncanny ability to sit in on requirements meetings and, within minutes, sketch out a program structure that would be the simplest possible solution with the fewest moving parts. That sketch was often the one we ended up implementing, and yet I noticed that Hieu always left enough wiggle room for the inevitable changes that came with any software project. (To be clear, he usually implemented a throwaway prototype to confirm the sketch, before passing on the design). When I designed implementations, something always had to be redesigned later. I simply wasn’t as good. Eventually, I asked him how he did this, and tried multiple times to get it out of him over the years we worked together. Our conversations would inevitably go something like the following:
“Well” Hieu would begin, “When you hear there is an external API, you should focus your program around that because there is a lot of risk there.”
“Yeah but then why didn’t you worry about the calendar API?”
“Oh, because I’ve worked with it before and I think it is easy to implement.”
“Why focus so much on Firebase?”
“Because we want to use it as a database layer. Quite risky ah.”
“So always focus on a core layer first, because more important?”
“Yes. Try to focus on the most dangerous bits first.”
“But how come you didn’t worry about the inventory API? We’ve never integrated with that before.”
“Ya that one not that important now I think. The client might change it later. Or maybe our feature is going to change. We do the basics first.”
I thought back to my Viki days, when I was a software engineering intern and was writing software tests for the first time. A senior software engineer took a few seconds to look at about a hundred lines of code I’d written, and said “Oh, that’s not good, this would be a problem later. Structure it this way.”
I asked him how he knew, within five seconds, that it was bad. He gave me a long explanation about software engineering principles. I waved him away and asked how he did it in five seconds. He said “Well, it just felt right. Ok, let’s go to lunch, you can fix it afterwards.”
I’ve written about this Viki episode in my post about perceptual learning. I don’t mean to say that Hieu or the senior software engineer couldn’t explain their judgment, or that they couldn’t make explicit the principles they used to evaluate the tradeoffs between a dozen or so variables: they could, even if terribly. My point is that their explanations would not lead me to the same ability that they had.
Why is this the case? Well, take a look at the conversation again. When I pushed these people on their judgments, they would try to explain in terms of principles or heuristics. But the more I pushed, the more exceptions and caveats and potential gotchas I unearthed.
This is actually generalisable. People with expertise in any sufficiently complicated domain will always explain their expertise with things like: “Well, do X. Except when you see Y, then do Z, because A. And if you see B, then do P. But if you see A and C but not B, then do Q, because reason D. And then there are weird situations where you do Z but then see thing C emerge, then you should switch to Q.”
And if you push further, eventually they might say “Ahh, it just feels right. Do it long enough and it’ll feel right to you too.”
Eventually I realised that the way to learn Hieu’s techniques was to copy him: to design some software and then ask for his feedback. And I realised that if you ever hear someone explaining things in terms of a long list of caveats, the odds are good that you’re looking at tacit knowledge in action.
This phenomenon is actually well established in the study of expertise. It has also been written about, many times, by practitioners in other fields. As an example, here’s surgeon Atul Gawande on appendicitis surgery:
Say you’ve got a patient who needs surgery for appendicitis. These days, surgeons will typically do a laparoscopic appendectomy. You slide a small camera—a laparoscope—into the abdomen through a quarter-inch incision near the belly button, insert a long grasper through an incision beneath the waistline, and push a device for stapling and cutting through an incision in the left lower abdomen. Use the grasper to pick up the finger-size appendix, fire the stapler across its base and across the vessels feeding it, drop the severed organ into a plastic bag, and pull it out. Close up, and you’re done. That’s how you like it to go, anyway. But often it doesn’t.
Even before you start, you need to make some judgments. Unusual anatomy, severe obesity, or internal scars from previous abdominal surgery could make it difficult to get the camera in safely; you don’t want to poke it into a loop of intestine. You have to decide which camera-insertion method to use—there’s a range of options—or whether to abandon the high-tech approach and do the operation the traditional way, with a wide-open incision that lets you see everything directly. If you do get your camera and instruments inside, you may have trouble grasping the appendix. Infection turns it into a fat, bloody, inflamed worm that sticks to everything around it—bowel, blood vessels, an ovary, the pelvic sidewall—and to free it you have to choose from a variety of tools and techniques. You can use a long cotton-tipped instrument to try to push the surrounding attachments away. You can use electrocautery, a hook, a pair of scissors, a sharp-tip dissector, a blunt-tip dissector, a right-angle dissector, or a suction device. You can adjust the operating table so that the patient’s head is down and his feet are up, allowing gravity to pull the viscera in the right direction. Or you can just grab whatever part of the appendix is visible and pull really hard.
Once you have the little organ in view, you may find that appendicitis was the wrong diagnosis. It might be a tumor of the appendix, Crohn’s disease, or an ovarian condition that happened to have inflamed the nearby appendix. Then you’d have to decide whether you need additional equipment or personnel—maybe it’s time to enlist another surgeon.
Over time, you learn how to head off problems, and, when you can’t, you arrive at solutions with less fumbling and more assurance. After eight years, I’ve performed more than two thousand operations. Three-quarters have involved my specialty, endocrine surgery—surgery for endocrine organs such as the thyroid, the parathyroid, and the adrenal glands. The rest have involved everything from simple biopsies to colon cancer. For my specialized cases, I’ve come to know most of the serious difficulties that could arise, and have worked out solutions. For the others, I’ve gained confidence in my ability to handle a wide range of situations, and to improvise when necessary.
Notice how Gawande includes all sorts of caveats in his explanation of his expertise. This is probably tacit knowledge in action. Learning this type of complicated judgment — this instantaneous solution selection that happens to balance dozens of considerations against each other — this is what is valuable to learn. And it is almost impossible to learn it through explanation alone.
Can Tacit Knowledge Be Made Explicit?
It is worth it to re-examine that last sentence, above. Could it — in principle — be possible to externalise tacit knowledge into a list of instructions? Perhaps we could extract expert decision-making into a multi-branched process, and code that into an ‘expert system’. Or perhaps we could turn it into a process list, and give that to every practitioner in the field, instead of having them learn tacit knowledge the traditional way.
The consensus answer to that question seems to be: “Yes, in principle it is possible to do so. In practice it is very difficult.” My take on this is that it is so difficult that we shouldn’t even bother; assuming that you are reading this because you want to get good in your career, you should give up on turning tacit knowledge into explicit knowledge and just go after tacit knowledge itself.
Why do we know this?
In the 1970s, a bunch of organisations — amongst them the US military — commissioned a number of studies to look into the possibility of building out all sorts of expert systems to augment or replace human agents. This notion of replacing humans with expert systems was a bit of a fad at the time, the same way that neural networks are big on the hype train today, but expert systems have fallen to the wayside in the decades since.
What many researchers found in the wake of that fad was that it is extremely difficult to encode all the possible branches and gotchas and nuances from a human expert into an expert system.
One of these projects, commissioned shortly after the Yom Kippur war, was to enter log books for Israeli aircraft maintenance into a US database, with the goal of perhaps replacing aircraft maintenance officers with an expert system. And a young researcher at the time — by the name of Gary Klein — was tasked with the job of interviewing aircraft maintenance officers to get at the core of their expertise.
He describes that project in a recent podcast episode:
“I could fill out 80% of the forms, but the other 20% ... maybe something was left blank … or maybe there was an error. And then I would interview them and ask “how did you fill this in?”
And then they (the maintenance officers) said: “OK look at this damage. Look at the size of the damage. And then the plane was back in service two days later. Now for this kind of damage, I know, if it severed any of these lines, it’s going to take a week or two (to repair). So obviously it didn’t sever those lines. So here’s the way the damage must have propagated, that they could get it back in service (so quickly).”
In other words, these guys could go beyond the logbooks, and imagine what it was like to be a maintenance technician, working on these kinds of problems.
(…) So when I wrote my report, the report was: here’s what I could do that was formulaic, but here are the critical incidents that I collected, so you can understand their expertise. And as a result the Air Force decided they could not build an expert system to replace these guys, and they had to keep paying them.”
You can sort of squint and see this result being repeated across many organisations, in many domains, during the same period. (Wikipedia calls this problem the ‘knowledge acquisition problem’, which is a nice way of putting it; it was what ultimately caused expert systems to decline in popularity). As people rapidly discovered, it wasn’t so easy to get the ‘rules’ out of experts’s heads in the first place.
But there are other objections, of course. Klein — now considered one of the pioneers of the Naturalistic Decision Making (NDM) branch of psychology — likes to say that over-reliance on procedures makes human operators fragile (Chapter 15, Source of Power). In other words, giving people a list of procedures to execute, blindly, denies them the ability to build expertise, which in turns prevents them from doing the sorts of creative problem solving that is common amongst expert operators. It also means that when something goes drastically wrong — and something always goes drastically wrong in the real world — they would not be able to adapt.
Are there indications that this isn’t a completely hopeless enterprise? Yes, it turns out there are:
- I have friends in artificial intelligence research who argue that it is possible for expert systems to make a comeback, perhaps by using more contemporary AI methods.
- Gary Klein himself has made a name developing techniques for extracting pieces of tacit knowledge and making it explicit. (The technique is called ‘The Critical Decision Method’, but it is difficult to pull off because it demands expertise in CDM itself).
- It is sometimes possible for a particularly gifted person to synthesise an entire field’s worth of tacit knowledge into an effective and explicit method of instruction. Arguably, John Boyd did this with the first fighter tactics manual for the US Air Force — where before people thought that dogfighting was an art that couldn’t be organised into explicit principles. But Boyd somehow managed to do so anyway, after a couple of years of teaching, and a full year of writing.
All of these points are valid, and worth thinking about — but whether or not they turn out to be generally correct is irrelevant, I think. You may say “actually, since all tacit knowledge can be made explicit, there is no such thing as tacit knowledge” — but that is a pedantic exercise that is uninteresting to me. It is not reasonable to wait for an expert systems revival, nor is it fruitful to expect CDM to be applied to your field, or for a Boyd-like genius to appear. We should act as if tacit knowledge were a fact, because it is more useful to think about ways to gain that tacit knowledge directly, instead of hoping for some breakthrough to make tacit knowledge explicit.
Learning Tacit Knowledge
What does this mean for us? It means that we should start looking into the published research on tacit knowledge if we want to pursue expertise in our fields.
“But wait,” I hear you say — “What about the field of deliberate practice? Isn’t that the predominant subfield most concerned with the development of expertise?” And the answer to that is no, it is not.
In my review of Ericssons’ Peak, and in my summary of The Problems with Deliberate Practice, I explained that deliberate practice is defined as possible only in domains with a long history of well-established pedagogy. In other words, deliberate practice can only exist in fields like music and math and chess.
K. Anders Ericsson lays out this narrow definition in Peak, and then does a cop-out, arguing that while he hasn’t studied practice outside of such domains, the ideas from deliberate practice may be applied to pedagogically less established fields. But Ericsson is well aware that NDM methods exist — he was one of the editors, alongside many names from the NDM community — who worked on the Cambridge Handbook for Expertise and Expert Performance.
And so if you are a programmer, or designer, or businessperson, an investor or a writer reading about deliberate practice, you may be asking: “Well, what about my field? What if there are no established pedagogical techniques for me?” And if you have started to ask this question, then you have begun travelling a more interesting path; this is really the right question to ask.
The answer, of course, is that the field of NDM is a lot more useful if you find yourself in one of these fields. The process of learning tacit knowledge looks something like the following: you find a master, you work under them for a few years, and you learn the ropes through emulation, feedback, and osmosis — not through deliberate practice. (Think: Warren Buffett and the years he spent under Benjamin Graham, for instance). The field of NDM is focused on ways to make this practice more effective. And I think much of the world pays too much attention to deliberate practice and to cognitive bias research, and not enough to tacit knowledge acquisition.
If tacit knowledge exists — and I believe it does — then the most useful tools about skill acquisition will come out of the fields that study it. Late last year, the NDM community got together and published The Oxford Handbook of Expertise. It is the single most comprehensive overview of the field that we know today.
It took about 30 years before Ericsson’s work about deliberate practice penetrated mainstream consciousness, due in part to the success of Malcolm Gladwell’s Outliers. If we use that as a comparison, how long before NDM methods seep into the mainstream?
Perhaps we’ll talk about tacit knowledge in 2030 the same way people talk about the ‘10,000 hour rule’ today. But if you’re reading this post, you’ll have a head start. Keep an eye out on NDM methods, and watch for things that focus on tacit knowledge. They are — in this writer’s opinion — the most interesting, overlooked topic in expertise today.
Note: this is the first entry in a series of posts about tacit knowledge, and what is known about how to learn it effectively. Subscribe to the Commonplace newsletter if you want updates; if you can't wait, I've written about NDM's methods in Parts 4 and 5 of my series on Putting Mental Models To Practice. But, be warned: those two posts are embedded in a 30,000 word series that summarises large parts of the judgment and decision making literature. If you don't want to read all of that, you might just want to wait for the next one.
Update: Part 2 is out here.
Originally published , last updated .
This article is part of the Expertise Acceleration topic cluster. Read more from this topic here→
