4 ms·
> Tacit knowledge, often called “tribal knowledge” in tech, is prevalent in this industry. Tacit knowledge is not the same as tribal knowledge. Tribal knowledg
by Swizec 3y ago
> Tacit knowledge, often called “tribal knowledge” in tech, is prevalent in this industry.
Tacit knowledge is not the same as tribal knowledge. Tribal knowledge is undocumented stuff. Tacit knowledge is about things that cannot be learned from documentation.
Riding a bike is an example of tacit knowledge. No amount of reading about the theory of riding a bike will teach you how to ride a bike. You have to hop on the bike and fail a few times until you figure it out.
In software engineering, tacit knowledge are things like "How to factor a system so 50 engineers can work together without stepping on each other's toes" and "How to structure your files to naturally reduce architectural complexity" and "How do you write a useful test that isn't just writing tests for the sake of tests". You can read about these things all you want, but you can only learn by experience. You have to get it wrong a bunch of times, see how it was wrong, and then you eventually start doing it less wrong.
Learning by example also works to speed up the process.
But that's not the same as undocumented.
- travisjungroth 3y agoI wrote a very similar comment and you beat me to it by one minute! Deleted and reposted below for compactness. Their usage of “tacit knowledge” is different from the most common usage. Tacit knowledge ≠ tribal knowledge. Tacit knowledge isn’t knowledge that no one has bothered to write down. It’s knowledge that is inherently difficult to write down. Riding a bike is tacit knowledge. Knowing when a class is doing “too much” is tacit knowledge. Knowing that the internal account must be created before the external account is not, but it’s the sort of thing that they’re talking about. I wouldn’t make such a big deal about semantics but it’s the title and the first few sentences of the blog post. I expected something very different than “tribal knowledge is bad”.
- er4hn 3y agoThanks for the comments everyone. You're not the first ones to give me feedback about co-inflating the two. In my mind saying that something is "hard to" write down is still pretty similar to saying it is not written down. For one, if you say it's hard to write something down, you're setting yourself up for a scenario where judging outcomes based on that lack of written down knowledge is going to be painful. For example: "It's hard to describe how to write good tests, so we didn't write it down. But we also want our tests to be more reliable." How do you solve the two without writing down some way to learn how to be better at tests? Likewise, if you want to learn how to ride a bike, how do you get started? Back in the pre-covid days you could do a lot of experimentation and learning from others in person, but that doesn't scale as well in the post-covid, remote and global, workplace. That's one of the core concepts I was trying to capture.
- travisjungroth 3y agoBeing pretty blunt here. I have a hard time taking your suggestions on documentation seriously when you’re redefining a well established term. “Tacit knowing” was introduced by Michael Polanyi in 1958. Its meaning has generally held in modern usage. https://en.m.wikipedia.org/wiki/Tacit_knowledge https://en.m.wikipedia.org/wiki/Tacit_knowledge There’s also a meaningful critique here that documentation is not a solution to tacit knowledge sharing. It doesn’t work. To answer your bike question, you learn a bike by riding it. There’s skill progressions and tips and mental models to share, but you absolutely can’t learn to ride a bike by reading docs. There are skills that are only learned through experience and mentorship. People try otherwise and it usually fails. Do you have evidence otherwise? Do you have a case where you were able to pass tacit knowledge efficiently to a large group of people through docs?