Tacit Knowledge

Brian Marick
(Originally published in Volume 6, Number 1, of Better Software.)

My wife Dawn teaches veterinary students how to cure cows. Each sick cow is assigned a student and each day that student has to decide - among other things - whether the cow is "bright" or "dull." Students usually err on the side of bright. It's Dawn's job to correct them. She and a student will stand near a misclassified cow, and Dawn will say, "This cow is dull. See - it's not cleaning its nostrils." (Trust me. You don't want to know how cows clean their nostrils.)

From this conversation, the student will create a rule:

(1) If it looks bright, but it's not cleaning its nostrils, it's dull.

That rule might work for a while, but eventually Dawn and the student will be standing beside a cow, and Dawn will say, "That cow is dull." The student will say, "But it's cleaning its nostrils!" To which, Dawn will reply, "But its ears are droopy."

Now the student adds a new rule:

(2) Droopy ears mean dull, and perky ears mean bright.

But those two rules don't work either. It might take a while for the student to be able to reliably decide between bright and dull. What's interesting is that, when she does, she's lost the rules. She can't articulate any complete set of rules that define bright or dull. In fact, the notion of defining them seems somewhat beside the point. Cows simply are either bright or dull, the way the student herself is either alert or sleepy, or the way a joke is either funny or lame. Any explanation of how she knows seems contrived and after the fact. It's as if the student's perceptual world has expanded.

Another way of putting it is that she's gained new tacit knowledge. Tacit knowledge, a phrase apparently coined by Michael Polanyi in his book Personal Knowledge, is a characteristic of experts, who often have no explicit theory of their work: they simply perform skillfully.

Today is probably the last time in your life that you'll be in any way affected by tacit knowledge of cows. But you are affected by other kinds of tacit knowledge, all the time, and you'll do better in your job if you're aware of that.

For example, consider the lovingly detailed requirements document that someone handed you, saying "Go implement this!" or "Test that code against these requirements." Experts were - you hope - involved in its creation, but you have to understand that their participation wasn't a matter of them tossing off a set of "the system shall..." statements that came readily to mind. It was a painfully laborious and incomplete attempt to put tacit knowledge into words. In some sense, that document misses the point, just as my wife's collection of statements about particular cows misses the point of what "dull" means.

Realizing that, you'll also realize that you have to gain access to tacit knowledge. You'll be inspired to watch the experts in action. You'll try to bring them closer to the team. You'll show them samples of the product, watch what they do with it, and adjust your explicit understanding according to what you see of their skillful performance. You will, I hope, abandon the notion that the requirements document is any sort of explicit definition. Instead, you'll see it as a tool for aligning the unexpressed wishes of the experts with the emerging abilities of the product.

For another example, consider articles in this magazine. They're written by experts who are doing the best they can to express their tacit knowledge, to create explicit guidelines for things that they do simply because, well, that's the way to do it. Now, I know I'm overstating for effect. It's not that our authors never think about what they're doing until we ask them to write about it, but the contribution of tacit knowledge is so often ignored that I want to emphasize it.

The lesson is that you can't absorb expertise just by reading these articles. If one strikes your fancy - if someday you want to be like its author - you'll have to find ways to practice its guidelines, over and over and over.