Tacit Knowledge Is Dangerous

Original Article ↗ Hacker News Discussion ↗

Tacit or “tribal” knowledge in software teams raises questions about what can realistically be documented versus what can only be learned through experience and mentorship. Commenters criticize conflating undocumented process quirks with true tacit knowledge (like design taste or debugging intuition), warning that trying to fully formalize the latter can backfire and undermine experts. Others explore how practices like better documentation, public internal channels, and even company-specific LLM “oracles” might surface hidden knowledge, while noting the security, liability, and maintenance costs of capturing everything.

Definition of Tacit vs Tribal/Undocumented Knowledge

  • Many argue the article misuses “tacit knowledge,” conflating it with “tribal” or simply undocumented knowledge.
  • In the thread, tacit knowledge is described as:
    • Skill/intuition that can’t be fully captured in documents (e.g., riding a bike, code “taste,” debugging instincts, physical craft skills).
    • Knowledge that emerges from experience and context, not just from reading specs.
  • Undocumented explicit facts (e.g., “internal account must be created before external account”) are seen as documentable and distinct from tacit knowledge.

Role and Limits of Documentation

  • Documentation is crucial for scaling, onboarding, and reducing “bus factor,” but is costly to create and maintain and often goes stale.
  • Over-documentation and attempts to “micro-document” everything can demotivate experts and slow organizations.
  • Some see documentation as a career positive (“make yourself replaceable to grow”); others note cultures where sharing makes you expendable.
  • Multiple examples: wikis that become cluttered, need constant gardening, and tend to be written by a small minority.

Tacit Knowledge, Expertise, and Learning

  • Tacit knowledge is seen as inevitable and central to expertise; trying to eliminate it is viewed as harmful.
  • True expertise includes knowing which rule of thumb applies in which context; this mapping is hard to write down.
  • Many skills (math, music, design, debugging, figure skating, etc.) are said to require practice and mentoring beyond docs.

LLMs and Knowledge Oracles

  • Some propose LLM-powered “company loremasters” trained on chats, docs, and meeting transcripts.
  • Others are skeptical:
    • LLMs hallucinate and don’t reliably say “I don’t know.”
    • Raw meeting logs are noisy; high-quality human-written content is still required.
  • Security and liability concerns are significant: a single stolen model or API access could expose meeting notes, internal politics, and security details, and models are hard to “forget” sensitive events.

Organizational Practices and Incentives

  • Suggested practices: public Slack channels, “newest member maintains docs,” runbooks tied to operations, and open internal information by default.
  • Some point to formal knowledge management frameworks (e.g., DIKW) and military practices that blend documentation, automation, and shared vision.
  • Overall sentiment: manage undocumented explicit knowledge aggressively; accept that deep expertise will always be partly tacit.