12 ms·

Tacit Knowledge Is Dangerous

159 points by Wingy 3y ago

vt100 3y ago
Does this mean tacit knowledge only exists within in-person teams? So projects like the Linux kernel don't have any tacit knowledge?
MarkusQ 3y ago
This looks like a really good use case for LLMs. When you're small and starting out in person, record everything the dev team does -- meetings, whiteboads, pairing sessions, etc. (yeah, creepy, but I'm in brainstorming mode) and then as you start to scale beyond the ability to "ask someone who knows" trail up an LLM to serve as the 24x7 lore master.
- DaveSchmindel 3y ago
  Ah, nice, like feeding a custom GPT everything that goes on at the company. That seems dangerous to me, and not in the typical LLM weariness way. Meetings can be messy, full of ambiguity, and "unsolved" at then end. If you feed a number of these experiences into an LLM, would its knowledge base be _that great_ at helping teach somebody about the company holding said meetings? I'd argue that in order for your LLM suggestion to be effective, the input to it would need to be human-written content. I.E: the knowledge that the OP is discussing. In that case, the human effort is still required up front.
  - FeepingCreature 3y ago
    It would be interesting to see if you could train a LLM, given "<A> The foo is definitely xyfied" to exclusively answer "Well, at least two months ago, A thought that the foo was xyfied" rather than opine about foo directly.
- haltist 3y ago
  This is very much like my panoptic computronium cathedral™. I only need $80B to build it to achieve AGI. The AGI requires 24/7 surveillance for making optimal decisions because it needs access to as much information as possible. The second stage will require worshipers to ingest nanosensors so that even their bowel movements can be tracked and analyzed by the AGI. This is all for the benefit of those who are under constant surveillance in the cathedral.
  - peteradio 3y ago
    Surely I wouldn't need to ingest anything to monitor my bowels, mightnt I simply insert a device up my ass?
    - haltist 3y ago
      Intriguing possibility.
    - thfuran 3y ago
      It's more robust to have multiple modalities, so you really ought to do both.
- pavel_lishin 3y ago
  A loremaster who will lie when they don't know the answer instead of saying, "I don't know".
  - ycombinete 3y ago
    At which point it becomes the Dungeon Master
    - pavel_lishin 3y ago
      Funny joke and not inaccurate, but as a regular Dungeon Master, there have definitely been times where I'll say I don't know! For example: - "Sorry, I'm not sure right now how that class feature would work in this situation. For now, let's assume it works like X so we don't have to bog down the session to google the answers or scour the books, and I'll take the time to look it up later and make sure we do the correct thing going forward." - "You know what, I actually don't know what happens in this kingdom if the king is incapacitated, but still alive, I didn't think to prepare for that scenario! Um, roll me a history check, and if you get a 15 or higher, then you'll have heard of this happening before, and you tell us what happens!" - "Ok friends, I didn't expect you to just go north into the woods and build a raft to cross the river. I literally have nothing prepared for this scenario, so instead of me making up something bad, let's call the session for now, and I'll prepare something that I know will be fun for next time."
      - ycombinete 3y ago
        My dungeon master has done similar things in the past. I do love finding out, after a campaign, that a favourite npc or room was made up on the fly after we did something unexpected though! I especially like your second example. Rule of cool + added space for role play.
jmfldn 3y ago
Perhaps such products are in the works, but I would love a private company LLM that slurps all messages, docs, meetings, and becomes an oracle that can be relied upon. Perhaps it could even infer tacit knowledge even when it's not explicit in any docs, since it could abstract principles and concepts from the maze of data.
- ericbarrett 3y ago
  Such an oracle would be a devastating thing to lose to industrial espionage.
  - jmfldn 3y ago
    Indeed it would. But then the source training data would be bad to lose too. That already exists. I understand it would be a higher level of damage to lose the model of course, but the benefits outweigh the risks, and these could be managed via a very security-hardened product.
    - ericbarrett 3y ago
      I think being able to steal a language model that can instruct you on things like the notes of every meeting, employee relationships, back-channel drama, security discussions, etc. and how these things relate to corporate and technical assets, all contained in a single artifact/tarball, really ups the ante for what kind of "security hardening" you'd need for this. Even exfiltration of API access for a few well-prompted queries could be really bad.
      - jmfldn 3y ago
        Yep for sure. Loads to consider here! My initial comment was just a brainstorm /bluesky thinking kind of idea. Clearly the implications are incredibly deep for security, data retention and a host of other concerns.
    - plugin-baby 3y ago
      Presumably threat actors can already feed stolen document dumps to LLMs to quickly find interesting data.
phkahler 3y ago
Sometimes it's best to get answers from the horses mouth - meaning the resident expert. This is ideally the person who created a thing, but can also be the person currently responsible. If no such person even exists for critical infrastructure, your company is IMO in trouble. Yes, documentation is important and should be kept up to date. People should consult documentation, and update it if it turn out to be old. But real, up to date, or deep understanding does not exist outside of human brains.
ChrisMarshallNY 3y ago
Well, as in all of these absolutist black/white, binary statements, "it depends." In my experience, tribal knowledge, which also includes cultural inculcation, can be the difference between success and failure. Sometimes, on the success side, and, sometimes, on the failure side. The main thing about "tribal knowledge," is that it relies on long-term association/employment, and that is not something we see much of, these days.
- botalert 3y ago
  Come now Chris, you know articles like these are cat nip for the HN circlejerk. Put up a straw man and then beat it down over and over again. PS. I loved the page you put up of your dad a few days ago and mentioned in the thread about diplomacy. Very interesting person.
- vt100 3y ago
  Surely there are tribes that transcend and cross corporations. That's why you can hire old colleagues and get a team up and running in a startup or new firm
  - ChrisMarshallNY 3y ago
    That would be "association." But there is also a great deal of extremely mercenary behavior, in today's workplace (not just tech). I suspect that it would be hard to have contiguous relationships. I worked at my last company for 27 years. I knew many folks for decades. I believe that this kind of thing is ... uncommon ... these days.
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 ago
  I 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 ago
    Thanks 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.
deleted 3y ago
[deleted]
datadrivenangel 3y ago
Scaling organizations requires work organizing the information about how things work. Tacit knowledge allows you to get stuff done with small groups without having to pay the extra cost of investing in organization.
tikhonj 3y ago
Tacit knowledge is inevitable... but it's also different from what this article is about. Tacit knowledge is the kind of knowledge (and skill!) that cannot be fully explained or taught in words—think mechanical skills you can only pick up through physical practice or very context-specific expertise you only get through experience. In programming good taste is crucial and entirely tacit: we can try to distill taste into words and write books about it, but it will never be enough. Tacit knowledge is not the same as explicit knowledge that just happens to not be documented. Tacit knowledge is not documented because it is undocumentable. You cannot avoid tacit knowledge. Human language fundamentally cannot express all the knowledge that experts develop through years of practice and experience. Even if an expert can express their experience, there are simply ideas and skills that people cannot learn exclusively from words. This is an important distinction. Trying to eliminate undocumented explicit knowledge is useful for teams. Trying to eliminate tacit knowledge is disastrous. I've seen attempts to make tacit knowledge legible to management—it is one of the most direct ways to sabotage your own experts because experts fundamentally cannot make all their knowledge explicit. Expertise is tacit knowledge and tacit knowledge is expertise. People generally understand that design by committee or design by regulation has awful results; one of the main reasons for this is that committees require decisions to be fully explicit and explainable—which hamstrings creative problem-solving and pushes for poor design decisions. Exclusively explicit processes get you lowest-common-denominator results: not the lowest common denominator of the expertise present, but the lowest common denominator of what people can explicitly communicate and understand, which is even lower! If you don't let experts be experts, you won't get expert-level work.
- fidotron 3y ago
  This. This article confuses tacit knowledge for the phenomenon most eloquently described by a former (superb) sysadmin colleague “documentation is the enemy of job security”.
  - pheres 3y ago
    One should not look to be unreplaceable, but rather the opposite. Only when you become replaceable at a certain task (or able to delegate it) you can progress to do new (more interesting) things.
denial 3y ago
This is an odd definition for tacit knowledge. My understanding is that it's more caught up in the intuition of concepts/systems that's difficult to codify because it's very contextual. This "tribal knowledge" perspective seems more like processes and facts that aren't documented. Not because of the inherent difficulty but instead because of priorities. Not that there isn't some intersection between the two.
hoherd 3y ago
At a previous company where I had a lot of this "tacit knowledge", I had made a policy for myself. Whenever somebody asked me a question over IM or e-mail, I would look in the wiki. If the answer was not in the wiki, I would write a new wiki article or update an existing article with the answer, and I would respond with a link to the article, and a statement like "if this doesn't answer your question let me know what is missing or could be described better." The reasons for this were for me to dump my tribal knowledge out of my brain into something everybody could search and read, and to promote usage of the wiki as a place where people found answers. Unfortunately it did not appear to have another desired effect of getting everybody to contribute content. I think this was probably because people came to see the wiki as a place to find knowledge, not to put knowledge.
- sonicanatidae 3y ago
  How do you keep your wiki from evolving into a kludge of random-ish info? One example of tacit knowledge is knowing the Dell T420s Tower Servers have very poor cooling for the raid controllers and often, this can cook them over time, requiring replacement or, at least repasting the heatsink. Now imagine 100s of those little tidbits. Useful, but hard to categorize.
  - jsty 3y ago
    Use an internal Q&A / Quora-style tool with good search. Trying to keep little snippets of info like that under useful MECE categories only ever ends in pain & frequent refactoring.
  - lucidguppy 3y ago
    I don't want to get too much on the ai hype train - but it seems like this would be perfect for machine learning, trained on the wiki-snippets of the company and emails (initiator would have to set a flag saying this is going to be training data).
    - sonicanatidae 3y ago
      That would be a good use of LLM AI, imo. Good idea.
artemonster 3y ago
I only once saw proper „knowledge“ documentation working in a german company which had a strict waterfall methodology. When project started, we spent at least 1/3 of the time writing documentation and specification first, then code. Onboarding was a breeze and when corona hit - nothing has changed, we could operate as usual too. I also had to overtake a domain of another engineer who was leaving, the handover was minimal, as everything was written down.
matt3210 3y ago
I find that "figuring it out on my own" takes a bit longer, but I learn a LOT of answers to alot of other things I didn't know I needed. "If I walk into a bookstore and you help me find the book I'm looking for, then You've robbed me of the opportunity to find all the books I wasn't looking for" -- paraphrasing Neil Tyson
antoineMoPa 3y ago
One easy and very useful habit we have where I work is to post all questions (even the stupidest questions) in public slack channels. That's also where most technical conversations happen. This helps us to hide less information in private chats.
bookofjoe 3y ago
It can also be lucrative: witness Joe Flacco, who three weeks ago was sitting on his couch watching games on TV, now with a chance to lead the Cleveland Browns to the playoffs.
cloogshicer 3y ago
Tacit knowledge is inevitable. Some people, like Turing Award winner Peter Naur, claim that the knowledge in the programmer's head is actually the main "product" of programming. He calls this "Theory Building". There's an excellent paper on it, but it's pretty verbose, here's [1] a summary with some additional case studies. [1] https://hiringengineersbook.com/post/autonomy/ https://hiringengineersbook.com/post/autonomy/
rodrigosetti 3y ago
No knowledge can be fully explained in words
wslh 3y ago
I think it is good to start by defining the concept because I first hear about "tacit knowledge" in the context of knowledge management [1]. In that context tacit knowledge is inherent to social systems. It is something that exists and could not be prevented. At the end what the author should criticize is not the tacit knowledge but how the organization manages the knowledge. And that is, knowledge management. [1] https://en.wikipedia.org/wiki/Knowledge_management https://en.wikipedia.org/wiki/Knowledge_management
austin-cheney 3y ago
The US Army has formal training about this and provides an Advanced Skill Identifier (ASI) to those training to practice it. See: * Techniques for Effective Knowledge Management, ATP 6-01.1, https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/atp6_01x1.pdf https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/atp6_01... The Army technique follows the DIKW model. https://en.wikipedia.org/wiki/DIKW_pyramid https://en.wikipedia.org/wiki/DIKW_pyramid When I did that job as NCOIC for a major sustainment command in Afghanistan I learned how to mix documentation, automation, and empathy to create a shared vision amongst the 24 shops that comprised the unit. I never would have matured into this writing corporate software. Since being laid off this year I am choosing to regress and aggressively embrace tacit knowledge. In the past I used to publish things I had learned to GitHub and many people found those writing extremely beneficial. As a JavaScript developer, however, I have finally been beaten into submission by the neglectful immaturity of my profession and so many of my peers. I have grown tired of debasing myself when so many people are hostile to any concepts of helpful guidance. The name of the game is attain employment by writing the same framework glue over and over thereby pandering to the desires of the least competent and least employable of the workforce. Any deviation is met with hostility first and possibly curiosity later. As a result I abandoned that line of work until I found a career change and now keep my learning about automation, performance, and architecture to myself.
PakG1 3y ago
Per other comments here, this is not what tacit knowledge is. There is an entire body of research devoted to understanding tacit knowledge. Anyone interested in tacit knowledge can read the works of those who have spent years researching the topic. Here are some sample papers. Nonaka is perhaps the most well-known one in this space. Hadjimichael, D., and Tsoukas, H. 2019. “Toward a Better Understanding of Tacit Knowledge in Organizations: Taking Stock and Moving Forward,” Academy of Management Annals (13:2), pp. 672–703. (https://doi.org/10.5465/annals.2017.0084 https://doi.org/10.5465/annals.2017.0084). Huang, X., Hsieh, J. P.-A., and He, W. 2014. “Expertise Dissimilarity and Creativity: The Contingent Roles of Tacit and Explicit Knowledge Sharing,” Journal of Applied Psychology (99:5), pp. 816–830. Nonaka, I., and Von Krogh, G. 2009. “Perspective—Tacit Knowledge and Knowledge Conversion: Controversy and Advancement in Organizational Knowledge Creation Theory,” Organization Science (20:3), pp. 635–652. (https://doi.org/10.1287/orsc.1080.0412 https://doi.org/10.1287/orsc.1080.0412). Nonaka, I. 1994. “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science (5:1), pp. 14–37.
- er4hn 3y ago
  Thanks I appreciate this. I know I co-inflated different concepts. I should update my blog post once the comments here dry up and I can go through them.
vasco 3y ago
Public everything inside the company. No private rooms. Redirect questions in dms to rooms. Public docs for everything. Everyone with full access to Google drive. Now your "question to the other side of the world" becomes a slack search, or a docs search, and is even better than in person.
deleted 3y ago
[deleted]
BiteCode_dev 3y ago
Even if you could express all tacit knowledge, which yoy can't because you may not know you hold it or it's hollistic, sharing it takes and resources. And no projects have an infinite amount of those, so choices are made.
mmcgaha 3y ago
I used to work with a smart guy who had what I think is the real answer to this problem. All documentation is maintained by the newest member of the team. The new guys job is to solve all of his issues with the documentation and if he has to ask someone then his job is to update the documentation.
surgical_fire 3y ago
> You may really need to know about the whizbang service, but it’s been 4 years since anyone last worked on it and no-one remembers how it works. You’ve now fallen into the trap of tacit knowledge. This article is bad. What it describes - as others have pointed out - is not "tacit knowledge". It merely describes a problem with lack of documentation. "Whizbang service" can be documented. You can write a diagram laying out the main components, write a small readme on how to build and run locally on against some staging environment, perhaps even having some internal wiki with a internal runbook of what to do when the service goes tits up. None of this would touch on "tacit knowledge". Tacit knowledge is there when I get a stack trace, and I already sort of suspect what happened without having to spend hours digging too deep on why. Or when I see some latency metrics for my service, and my first instinct is checking on Slack for deployments on dependencies. You can try to document those things, but it is a fool's errand - you'll end up with a huge mess of text that will work against the purpose of documentation.
stillwithit 3y ago
There’s less knowledge needed to manage these systems than we want to believe. Tech is mired in hustle culture, which means it’s generating a lot of useless “knowledge” to role-play hustle. Over engineering re-engineering to justify business headcount, importance, and prestige is a bigger danger in tech than the one this article points out
mekoka 3y ago
Nice article and good points, but perhaps the author wasn't aware that "tacit knowledge" is a term already used for something else. https://commoncog.com/the-tacit-knowledge-series/ https://commoncog.com/the-tacit-knowledge-series/ Tacit knowledge is undocumentable because it's knowledge borne out of experience. It's tacit because articulating it would be too tedious, impractical, and most probably incomplete. Think learning to play a sport by simply watching videos or reading instructions. Michael Jordan famously explained that although all players are taught the same theory, there's a point in a veteran's career where they can read the game at a different level. Closer to programming, it's the reason we see more articles repudiating well packaged ideas, such as "Clean Code" (capitalization intended), as past beginners who bought into them, are becoming experienced enough to recognize them as leaky abstractions.
6gvONxR4sf7o 3y ago
I agree with this, but I also mourn the loss of "just talk to someone 20 ft away." The better the docs get, the worse the social ties get. And that's coming from someone who was nearly useless from distraction in an open office.
RadiozRadioz 3y ago
The place I've just joined has an extremely big problem with this. There's a lot of documentation, but it all relies on an immense amount of background knowledge to be useful. It's difficult to strike a balance between excessive detail in docs versus wide readership, but I'm inclined to prefer the former as it helps alleviate situations like this.
csours 3y ago
Please leave clues as close to the scene of the crime as possible. You can't fix everything, and some fixes are too big and take a long time, but please just leave me a clue.
dgunay 3y ago
Some tacit knowledge maybe is impossible to document, but in a lot of circles there is a distinct lack of ability by those who are skilled in some activity to describe how they do things. There is often a split between those who can execute at a world-class level, and those who aren't as good but can teach others effectively. I've seen this dynamic play out in competitive videogames, figure skating, musicianship, etc. Take figure skating for example. I was being taught how to do a basic two foot spin by someone I know who is/was a competitive figure skater. Not a complicated move. They completely failed to explain to me a critical part of how to do the spin effectively (namely, where on my blades I should keep my balance and how I should angle them). So did several instructors leading classes on figure skating. I floundered for a while until one day I managed to figure it out by random chance. I was quite annoyed, because to me it is a perfectly explainable thing that everyone was apparently either just figuring out through trial and error or just didn't think was worth explaining. But these kinds of pedagogical "blind spots" pervade nearly all human fields of study.
jiggawatts 3y ago
Speaking of tacit experience, I love watching YouTube videos made by professionals working in industries I’m just a rank amateur in. One thing that occurred to me is that I’ll observe these people casually and repeatedly applying “methods of the art” without a second thought, but then spend the entire episode talking about some specific obscure issue they’re trying to solve. In my mind these have equal difficulty — and in some sense they are equal! It’s just that professionals may have done basics so often they don’t even think about it any more. It’s become a habit, mere tacit knowledge. Some random examples: Correctly centering something in a lathe — done in incorrectly can lead to this: https://www.forbesadvocate.com.au/story/907281/faulty-oil-pipe-to-blame-for-qantas-incident-says-report/ https://www.forbesadvocate.com.au/story/907281/faulty-oil-pi... I can think of thousands of examples like that: tacit knowledge is the knowledge you gain when you do something many times a day. That doesn’t make it less important, less valuable, or more obvious to beginners.
parentheses 3y ago
I really dislike when companies represent their knowledge bases as a list of videos. I have seen it a few times and I look forward to videos becoming searchable more easily over time.
MrYellowP 3y ago
Intelligent people understand that knowledge can not ever be dangerous, because it's the human who makes things dangerous. Intelligent people understand that when lesser intelligent people call knowledge dangerous, they will eventually, but definitely inevitably, ask for the banning of said knowledge, because "the evil knowledge makes people do things they shouldn't", or a variation thereof.
koliber 3y ago
There is hard knowledge and there is tacit knowledge. It’s not black and white. It’s a continuum. Tacit knowledge documentation can take form of pro tips, best practices, anecdotes, postmortems, retrospectives, values, and philosophy statements. It’s possible to capture a bit of it in written form. It will never be fully documented. A little goes a long way though.

159 points by Wingy 3y ago

Does this mean tacit knowledge only exists within in-person teams? So projects like the Linux kernel don't have any tacit knowledge?

MarkusQ 3y ago

This looks like a really good use case for LLMs. When you're small and starting out in person, record everything the dev team does -- meetings, whiteboads, pairing sessions, etc. (yeah, creepy, but I'm in brainstorming mode) and then as you start to scale beyond the ability to "ask someone who knows" trail up an LLM to serve as the 24x7 lore master.

DaveSchmindel 3y ago
Ah, nice, like feeding a custom GPT everything that goes on at the company. That seems dangerous to me, and not in the typical LLM weariness way. Meetings can be messy, full of ambiguity, and "unsolved" at then end. If you feed a number of these experiences into an LLM, would its knowledge base be _that great_ at helping teach somebody about the company holding said meetings? I'd argue that in order for your LLM suggestion to be effective, the input to it would need to be human-written content. I.E: the knowledge that the OP is discussing. In that case, the human effort is still required up front.
- FeepingCreature 3y ago
  It would be interesting to see if you could train a LLM, given "<A> The foo is definitely xyfied" to exclusively answer "Well, at least two months ago, A thought that the foo was xyfied" rather than opine about foo directly.
haltist 3y ago
This is very much like my panoptic computronium cathedral™. I only need $80B to build it to achieve AGI. The AGI requires 24/7 surveillance for making optimal decisions because it needs access to as much information as possible. The second stage will require worshipers to ingest nanosensors so that even their bowel movements can be tracked and analyzed by the AGI. This is all for the benefit of those who are under constant surveillance in the cathedral.
- peteradio 3y ago
  Surely I wouldn't need to ingest anything to monitor my bowels, mightnt I simply insert a device up my ass?
  - haltist 3y ago
    Intriguing possibility.
  - thfuran 3y ago
    It's more robust to have multiple modalities, so you really ought to do both.
pavel_lishin 3y ago
A loremaster who will lie when they don't know the answer instead of saying, "I don't know".
- ycombinete 3y ago
  At which point it becomes the Dungeon Master
  - pavel_lishin 3y ago
    Funny joke and not inaccurate, but as a regular Dungeon Master, there have definitely been times where I'll say I don't know! For example: - "Sorry, I'm not sure right now how that class feature would work in this situation. For now, let's assume it works like X so we don't have to bog down the session to google the answers or scour the books, and I'll take the time to look it up later and make sure we do the correct thing going forward." - "You know what, I actually don't know what happens in this kingdom if the king is incapacitated, but still alive, I didn't think to prepare for that scenario! Um, roll me a history check, and if you get a 15 or higher, then you'll have heard of this happening before, and you tell us what happens!" - "Ok friends, I didn't expect you to just go north into the woods and build a raft to cross the river. I literally have nothing prepared for this scenario, so instead of me making up something bad, let's call the session for now, and I'll prepare something that I know will be fun for next time."
    - ycombinete 3y ago
      My dungeon master has done similar things in the past. I do love finding out, after a campaign, that a favourite npc or room was made up on the fly after we did something unexpected though! I especially like your second example. Rule of cool + added space for role play.

jmfldn 3y ago

Perhaps such products are in the works, but I would love a private company LLM that slurps all messages, docs, meetings, and becomes an oracle that can be relied upon. Perhaps it could even infer tacit knowledge even when it's not explicit in any docs, since it could abstract principles and concepts from the maze of data.

ericbarrett 3y ago
Such an oracle would be a devastating thing to lose to industrial espionage.
- jmfldn 3y ago
  Indeed it would. But then the source training data would be bad to lose too. That already exists. I understand it would be a higher level of damage to lose the model of course, but the benefits outweigh the risks, and these could be managed via a very security-hardened product.
  - ericbarrett 3y ago
    I think being able to steal a language model that can instruct you on things like the notes of every meeting, employee relationships, back-channel drama, security discussions, etc. and how these things relate to corporate and technical assets, all contained in a single artifact/tarball, really ups the ante for what kind of "security hardening" you'd need for this. Even exfiltration of API access for a few well-prompted queries could be really bad.
    - jmfldn 3y ago
      Yep for sure. Loads to consider here! My initial comment was just a brainstorm /bluesky thinking kind of idea. Clearly the implications are incredibly deep for security, data retention and a host of other concerns.
  - plugin-baby 3y ago
    Presumably threat actors can already feed stolen document dumps to LLMs to quickly find interesting data.

phkahler 3y ago

Sometimes it's best to get answers from the horses mouth - meaning the resident expert. This is ideally the person who created a thing, but can also be the person currently responsible. If no such person even exists for critical infrastructure, your company is IMO in trouble. Yes, documentation is important and should be kept up to date. People should consult documentation, and update it if it turn out to be old. But real, up to date, or deep understanding does not exist outside of human brains.

ChrisMarshallNY 3y ago

Well, as in all of these absolutist black/white, binary statements, "it depends." In my experience, tribal knowledge, which also includes cultural inculcation, can be the difference between success and failure. Sometimes, on the success side, and, sometimes, on the failure side. The main thing about "tribal knowledge," is that it relies on long-term association/employment, and that is not something we see much of, these days.

botalert 3y ago
Come now Chris, you know articles like these are cat nip for the HN circlejerk. Put up a straw man and then beat it down over and over again. PS. I loved the page you put up of your dad a few days ago and mentioned in the thread about diplomacy. Very interesting person.
vt100 3y ago
Surely there are tribes that transcend and cross corporations. That's why you can hire old colleagues and get a team up and running in a startup or new firm
- ChrisMarshallNY 3y ago
  That would be "association." But there is also a great deal of extremely mercenary behavior, in today's workplace (not just tech). I suspect that it would be hard to have contiguous relationships. I worked at my last company for 27 years. I knew many folks for decades. I believe that this kind of thing is ... uncommon ... these days.

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 ago
I 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 ago
  Thanks 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.

deleted 3y ago

[deleted]

datadrivenangel 3y ago

Scaling organizations requires work organizing the information about how things work. Tacit knowledge allows you to get stuff done with small groups without having to pay the extra cost of investing in organization.

tikhonj 3y ago

Tacit knowledge is inevitable... but it's also different from what this article is about. Tacit knowledge is the kind of knowledge (and skill!) that cannot be fully explained or taught in words—think mechanical skills you can only pick up through physical practice or very context-specific expertise you only get through experience. In programming good taste is crucial and entirely tacit: we can try to distill taste into words and write books about it, but it will never be enough. Tacit knowledge is not the same as explicit knowledge that just happens to not be documented. Tacit knowledge is not documented because it is undocumentable. You cannot avoid tacit knowledge. Human language fundamentally cannot express all the knowledge that experts develop through years of practice and experience. Even if an expert can express their experience, there are simply ideas and skills that people cannot learn exclusively from words. This is an important distinction. Trying to eliminate undocumented explicit knowledge is useful for teams. Trying to eliminate tacit knowledge is disastrous. I've seen attempts to make tacit knowledge legible to management—it is one of the most direct ways to sabotage your own experts because experts fundamentally cannot make all their knowledge explicit. Expertise is tacit knowledge and tacit knowledge is expertise. People generally understand that design by committee or design by regulation has awful results; one of the main reasons for this is that committees require decisions to be fully explicit and explainable—which hamstrings creative problem-solving and pushes for poor design decisions. Exclusively explicit processes get you lowest-common-denominator results: not the lowest common denominator of the expertise present, but the lowest common denominator of what people can explicitly communicate and understand, which is even lower! If you don't let experts be experts, you won't get expert-level work.

fidotron 3y ago
This. This article confuses tacit knowledge for the phenomenon most eloquently described by a former (superb) sysadmin colleague “documentation is the enemy of job security”.
- pheres 3y ago
  One should not look to be unreplaceable, but rather the opposite. Only when you become replaceable at a certain task (or able to delegate it) you can progress to do new (more interesting) things.

denial 3y ago

This is an odd definition for tacit knowledge. My understanding is that it's more caught up in the intuition of concepts/systems that's difficult to codify because it's very contextual. This "tribal knowledge" perspective seems more like processes and facts that aren't documented. Not because of the inherent difficulty but instead because of priorities. Not that there isn't some intersection between the two.

hoherd 3y ago

At a previous company where I had a lot of this "tacit knowledge", I had made a policy for myself. Whenever somebody asked me a question over IM or e-mail, I would look in the wiki. If the answer was not in the wiki, I would write a new wiki article or update an existing article with the answer, and I would respond with a link to the article, and a statement like "if this doesn't answer your question let me know what is missing or could be described better." The reasons for this were for me to dump my tribal knowledge out of my brain into something everybody could search and read, and to promote usage of the wiki as a place where people found answers. Unfortunately it did not appear to have another desired effect of getting everybody to contribute content. I think this was probably because people came to see the wiki as a place to find knowledge, not to put knowledge.

sonicanatidae 3y ago
How do you keep your wiki from evolving into a kludge of random-ish info? One example of tacit knowledge is knowing the Dell T420s Tower Servers have very poor cooling for the raid controllers and often, this can cook them over time, requiring replacement or, at least repasting the heatsink. Now imagine 100s of those little tidbits. Useful, but hard to categorize.
- jsty 3y ago
  Use an internal Q&A / Quora-style tool with good search. Trying to keep little snippets of info like that under useful MECE categories only ever ends in pain & frequent refactoring.
- lucidguppy 3y ago
  I don't want to get too much on the ai hype train - but it seems like this would be perfect for machine learning, trained on the wiki-snippets of the company and emails (initiator would have to set a flag saying this is going to be training data).
  - sonicanatidae 3y ago
    That would be a good use of LLM AI, imo. Good idea.

artemonster 3y ago

I only once saw proper „knowledge“ documentation working in a german company which had a strict waterfall methodology. When project started, we spent at least 1/3 of the time writing documentation and specification first, then code. Onboarding was a breeze and when corona hit - nothing has changed, we could operate as usual too. I also had to overtake a domain of another engineer who was leaving, the handover was minimal, as everything was written down.

matt3210 3y ago

I find that "figuring it out on my own" takes a bit longer, but I learn a LOT of answers to alot of other things I didn't know I needed. "If I walk into a bookstore and you help me find the book I'm looking for, then You've robbed me of the opportunity to find all the books I wasn't looking for" -- paraphrasing Neil Tyson

antoineMoPa 3y ago

One easy and very useful habit we have where I work is to post all questions (even the stupidest questions) in public slack channels. That's also where most technical conversations happen. This helps us to hide less information in private chats.

bookofjoe 3y ago

It can also be lucrative: witness Joe Flacco, who three weeks ago was sitting on his couch watching games on TV, now with a chance to lead the Cleveland Browns to the playoffs.

cloogshicer 3y ago

Tacit knowledge is inevitable. Some people, like Turing Award winner Peter Naur, claim that the knowledge in the programmer's head is actually the main "product" of programming. He calls this "Theory Building". There's an excellent paper on it, but it's pretty verbose, here's [1] a summary with some additional case studies. [1] https://hiringengineersbook.com/post/autonomy/ https://hiringengineersbook.com/post/autonomy/

rodrigosetti 3y ago

No knowledge can be fully explained in words

wslh 3y ago

I think it is good to start by defining the concept because I first hear about "tacit knowledge" in the context of knowledge management [1]. In that context tacit knowledge is inherent to social systems. It is something that exists and could not be prevented. At the end what the author should criticize is not the tacit knowledge but how the organization manages the knowledge. And that is, knowledge management. [1] https://en.wikipedia.org/wiki/Knowledge_management https://en.wikipedia.org/wiki/Knowledge_management

austin-cheney 3y ago

The US Army has formal training about this and provides an Advanced Skill Identifier (ASI) to those training to practice it. See: * Techniques for Effective Knowledge Management, ATP 6-01.1, https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/atp6_01x1.pdf https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/atp6_01... The Army technique follows the DIKW model. https://en.wikipedia.org/wiki/DIKW_pyramid https://en.wikipedia.org/wiki/DIKW_pyramid When I did that job as NCOIC for a major sustainment command in Afghanistan I learned how to mix documentation, automation, and empathy to create a shared vision amongst the 24 shops that comprised the unit. I never would have matured into this writing corporate software. Since being laid off this year I am choosing to regress and aggressively embrace tacit knowledge. In the past I used to publish things I had learned to GitHub and many people found those writing extremely beneficial. As a JavaScript developer, however, I have finally been beaten into submission by the neglectful immaturity of my profession and so many of my peers. I have grown tired of debasing myself when so many people are hostile to any concepts of helpful guidance. The name of the game is attain employment by writing the same framework glue over and over thereby pandering to the desires of the least competent and least employable of the workforce. Any deviation is met with hostility first and possibly curiosity later. As a result I abandoned that line of work until I found a career change and now keep my learning about automation, performance, and architecture to myself.

PakG1 3y ago

Per other comments here, this is not what tacit knowledge is. There is an entire body of research devoted to understanding tacit knowledge. Anyone interested in tacit knowledge can read the works of those who have spent years researching the topic. Here are some sample papers. Nonaka is perhaps the most well-known one in this space. Hadjimichael, D., and Tsoukas, H. 2019. “Toward a Better Understanding of Tacit Knowledge in Organizations: Taking Stock and Moving Forward,” Academy of Management Annals (13:2), pp. 672–703. (https://doi.org/10.5465/annals.2017.0084 https://doi.org/10.5465/annals.2017.0084). Huang, X., Hsieh, J. P.-A., and He, W. 2014. “Expertise Dissimilarity and Creativity: The Contingent Roles of Tacit and Explicit Knowledge Sharing,” Journal of Applied Psychology (99:5), pp. 816–830. Nonaka, I., and Von Krogh, G. 2009. “Perspective—Tacit Knowledge and Knowledge Conversion: Controversy and Advancement in Organizational Knowledge Creation Theory,” Organization Science (20:3), pp. 635–652. (https://doi.org/10.1287/orsc.1080.0412 https://doi.org/10.1287/orsc.1080.0412). Nonaka, I. 1994. “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science (5:1), pp. 14–37.

er4hn 3y ago
Thanks I appreciate this. I know I co-inflated different concepts. I should update my blog post once the comments here dry up and I can go through them.

vasco 3y ago

Public everything inside the company. No private rooms. Redirect questions in dms to rooms. Public docs for everything. Everyone with full access to Google drive. Now your "question to the other side of the world" becomes a slack search, or a docs search, and is even better than in person.

deleted 3y ago

[deleted]

BiteCode_dev 3y ago

Even if you could express all tacit knowledge, which yoy can't because you may not know you hold it or it's hollistic, sharing it takes and resources. And no projects have an infinite amount of those, so choices are made.

mmcgaha 3y ago

I used to work with a smart guy who had what I think is the real answer to this problem. All documentation is maintained by the newest member of the team. The new guys job is to solve all of his issues with the documentation and if he has to ask someone then his job is to update the documentation.

surgical_fire 3y ago

> You may really need to know about the whizbang service, but it’s been 4 years since anyone last worked on it and no-one remembers how it works. You’ve now fallen into the trap of tacit knowledge. This article is bad. What it describes - as others have pointed out - is not "tacit knowledge". It merely describes a problem with lack of documentation. "Whizbang service" can be documented. You can write a diagram laying out the main components, write a small readme on how to build and run locally on against some staging environment, perhaps even having some internal wiki with a internal runbook of what to do when the service goes tits up. None of this would touch on "tacit knowledge". Tacit knowledge is there when I get a stack trace, and I already sort of suspect what happened without having to spend hours digging too deep on why. Or when I see some latency metrics for my service, and my first instinct is checking on Slack for deployments on dependencies. You can try to document those things, but it is a fool's errand - you'll end up with a huge mess of text that will work against the purpose of documentation.

stillwithit 3y ago

There’s less knowledge needed to manage these systems than we want to believe. Tech is mired in hustle culture, which means it’s generating a lot of useless “knowledge” to role-play hustle. Over engineering re-engineering to justify business headcount, importance, and prestige is a bigger danger in tech than the one this article points out

mekoka 3y ago

Nice article and good points, but perhaps the author wasn't aware that "tacit knowledge" is a term already used for something else. https://commoncog.com/the-tacit-knowledge-series/ https://commoncog.com/the-tacit-knowledge-series/ Tacit knowledge is undocumentable because it's knowledge borne out of experience. It's tacit because articulating it would be too tedious, impractical, and most probably incomplete. Think learning to play a sport by simply watching videos or reading instructions. Michael Jordan famously explained that although all players are taught the same theory, there's a point in a veteran's career where they can read the game at a different level. Closer to programming, it's the reason we see more articles repudiating well packaged ideas, such as "Clean Code" (capitalization intended), as past beginners who bought into them, are becoming experienced enough to recognize them as leaky abstractions.

6gvONxR4sf7o 3y ago

I agree with this, but I also mourn the loss of "just talk to someone 20 ft away." The better the docs get, the worse the social ties get. And that's coming from someone who was nearly useless from distraction in an open office.

RadiozRadioz 3y ago

The place I've just joined has an extremely big problem with this. There's a lot of documentation, but it all relies on an immense amount of background knowledge to be useful. It's difficult to strike a balance between excessive detail in docs versus wide readership, but I'm inclined to prefer the former as it helps alleviate situations like this.

csours 3y ago

Please leave clues as close to the scene of the crime as possible. You can't fix everything, and some fixes are too big and take a long time, but please just leave me a clue.

dgunay 3y ago

Some tacit knowledge maybe is impossible to document, but in a lot of circles there is a distinct lack of ability by those who are skilled in some activity to describe how they do things. There is often a split between those who can execute at a world-class level, and those who aren't as good but can teach others effectively. I've seen this dynamic play out in competitive videogames, figure skating, musicianship, etc. Take figure skating for example. I was being taught how to do a basic two foot spin by someone I know who is/was a competitive figure skater. Not a complicated move. They completely failed to explain to me a critical part of how to do the spin effectively (namely, where on my blades I should keep my balance and how I should angle them). So did several instructors leading classes on figure skating. I floundered for a while until one day I managed to figure it out by random chance. I was quite annoyed, because to me it is a perfectly explainable thing that everyone was apparently either just figuring out through trial and error or just didn't think was worth explaining. But these kinds of pedagogical "blind spots" pervade nearly all human fields of study.

jiggawatts 3y ago

Speaking of tacit experience, I love watching YouTube videos made by professionals working in industries I’m just a rank amateur in. One thing that occurred to me is that I’ll observe these people casually and repeatedly applying “methods of the art” without a second thought, but then spend the entire episode talking about some specific obscure issue they’re trying to solve. In my mind these have equal difficulty — and in some sense they are equal! It’s just that professionals may have done basics so often they don’t even think about it any more. It’s become a habit, mere tacit knowledge. Some random examples: Correctly centering something in a lathe — done in incorrectly can lead to this: https://www.forbesadvocate.com.au/story/907281/faulty-oil-pipe-to-blame-for-qantas-incident-says-report/ https://www.forbesadvocate.com.au/story/907281/faulty-oil-pi... I can think of thousands of examples like that: tacit knowledge is the knowledge you gain when you do something many times a day. That doesn’t make it less important, less valuable, or more obvious to beginners.

parentheses 3y ago

I really dislike when companies represent their knowledge bases as a list of videos. I have seen it a few times and I look forward to videos becoming searchable more easily over time.

MrYellowP 3y ago

Intelligent people understand that knowledge can not ever be dangerous, because it's the human who makes things dangerous. Intelligent people understand that when lesser intelligent people call knowledge dangerous, they will eventually, but definitely inevitably, ask for the banning of said knowledge, because "the evil knowledge makes people do things they shouldn't", or a variation thereof.

koliber 3y ago

There is hard knowledge and there is tacit knowledge. It’s not black and white. It’s a continuum. Tacit knowledge documentation can take form of pro tips, best practices, anecdotes, postmortems, retrospectives, values, and philosophy statements. It’s possible to capture a bit of it in written form. It will never be fully documented. A little goes a long way though.