Why you keep losing information when your team grows
I spent three years building an internal knowledge base for a software team that had just doubled in size. Everything looked perfect on paper. The documentation was organized, the wikis were linked, people were updating their tickets. Six months later, the new hires were still asking the same five questions that senior engineers had answered dozens of times. The problem wasn't that the knowledge didn't exist. It was that the wrong os tipos de conhecimento was being captured, stored, and expected to travel between people. Most teams try to solve this by writing things down. They treat all knowledge as if it were the same kind of thing you can put in a Google Doc and expect someone else to use. That assumption is the reason the system fails. You need to know which type you're dealing with before you try to preserve it.
os tipos de conhecimento: what actually matters in practice
The classical framework breaks knowledge into procedural, propositional, and acquaintance types. In a workplace, that translates roughly to know-how, factual understanding, and direct familiarity with a system. But the real distinction that determines whether information survives a handoff is between explicit and tacit knowledge. This comes from Michael Polanyi's work in the 1960s and it's not a fancy philosophical point. It's the difference between something you can write in a README and something you only have because you've been doing the work for two years. Explicit knowledge is declarative. It can be codified, stored, searched, and transmitted through language or symbols. A database schema, an API endpoint description, a list of common error codes and their meanings. All of that is explicit. It travels easily. The trap is assuming that explicit knowledge alone is sufficient for competence. It isn't. The gap between reading a guide and actually using it correctly is where tacit knowledge lives.
Tacit knowledge is the opposite. It's the pattern recognition you develop from repeated exposure. It's knowing which part of the codebase tends to break when the load spikes, without being able to point to a single log line that proves it. It's the sense of timing when you deploy to production on a Friday afternoon. You can't write that down directly. You can only transfer it through shared practice, observation, and guided experience.
How each type behaves under pressure
When I was running the knowledge base project, we had a specific incident that exposed this clearly. A senior engineer left the company. His documentation was thorough. Every deployment checklist, every runbook, every postmortem was archived in the wiki. Two weeks later, a critical outage hit. The new on-call engineer followed the runbook exactly. It didn't help. The issue was a cascading failure in the caching layer that only manifested under a specific combination of traffic patterns and database lock contention. The runbook covered the individual symptoms but never explained the underlying dependency chain. What was missing wasn't explicit knowledge. It was conditional knowledge, a subtype of propositional knowledge that encodes why something works a certain way under specific circumstances. The senior engineer understood this conditionally because he'd been there when the cache started failing during the Black Friday migration eighteen months earlier. He knew the pattern. He never wrote it down because writing it down would have required explaining a chain of reasoning that itself depended on experience. That's the core limitation of explicit capture. You can document facts. You cannot document the context that made those facts meaningful.
Propositional knowledge is the "that" knowledge. It's knowledge that can be expressed as true or false statements. The database is PostgreSQL version 14. The API returns a 429 error when the rate limit is exceeded. These are straightforward. The bottleneck appears when propositional knowledge gets mistaken for conditional knowledge. Teams treat a checklist like it's wisdom. A checklist is not wisdom. A checklist is a collection of propositions that worked once, in one context, with one team. Procedural knowledge sits somewhere between explicit and tacit. Some of it can be codified as step-by-step instructions. Most of it can't, because the steps depend on judgment calls that only make sense in practice. You can write "check the logs before restarting the service," but you can't write the implicit heuristic that tells you which log file matters most when three services are writing to the same stdout stream. That becomes explicit only after someone has spent enough time staring at those logs to recognize the signal.
👉 Clique no botão abaixo para saber mais sobre o assunto!
What happens when you get the types wrong
The most common failure mode I've seen is treating tacit knowledge as if it were explicit. You force people to document things they can't articulate clearly. The result is shallow documentation that sounds useful but collapses the moment conditions change. I've read runbooks that listed exact commands to execute but provided no reasoning for why those commands were ordered the way they were. When the environment shifted slightly, the runbook became actively misleading because it gave false confidence. The reverse failure is also common. Teams over-invest in tacit knowledge transfer through mentorship and pair programming without building any explicit safety net. This creates single points of failure. When the senior person is sick, on vacation, or gone, the institutional knowledge walks out the door with them. There's no alternative but to recreate the learning curve from scratch for the next person.
Acquaintance knowledge, which is knowing something through direct interaction rather than description, is the most fragile type. It's entirely dependent on continued exposure. If you stop maintaining the system, you lose the acquaintance knowledge. This is why teams that inherit a legacy codebase and don't invest in active exploration eventually reach a state where only one or two people understand how it works, and even they're partially guessing. The knowledge hasn't disappeared. It's just become private and unstated.
A practical approach that actually works
Start by classifying what you have before you try to store it. When someone asks you to document something, ask yourself whether what they're describing is a fact, a procedure, a condition, or a pattern recognized through experience. Facts go in a database or a wiki. Procedures that are truly repeatable go in a runbook with clear preconditions. Conditions that depend on context go in a decision tree or a set of scenarios. Patterns recognized through experience belong in a discussion thread, a recorded session, or a live walkthrough, not a static document. For the incident I described earlier, the fix wasn't better documentation. It was creating a living decision model that mapped specific failure modes to the conditions that produced them. We built a simple table with columns for symptom, likely cause, conditions that trigger it, and historical examples. The table grew slowly as incidents occurred. It was never complete, and it never would be, but it captured the conditional knowledge that the runbooks had missed. Engineers used it during incidents because it was searchable and updated in real time.
The tradeoff is that this approach requires continuous maintenance. Conditional knowledge decays quickly if conditions change. A pattern that was valid last year might not be valid this year if the infrastructure shifted. The decision model needs a designated owner who reviews it quarterly and marks entries as stale or obsolete. Without that discipline, it becomes another graveyard of outdated information that people stop trusting. Another technique that works better than you'd expect is the "debug diary." When someone investigates a non-trivial issue, they write a brief entry describing not just the solution but the path they took to find it. Which hypotheses they tried first, which ones failed, and why they ruled them out. This captures the procedural and conditional knowledge that normally evaporates after the fact. It's more valuable than the final answer because the final answer is context-dependent, but the reasoning path generalizes to similar problems.
When this framework breaks down
Not everything fits neatly into these categories. Some knowledge is cultural. It lives in the shared assumptions of a team rather than in any document or individual mind. You can't capture it explicitly without stripping it of meaning, and you can't transfer it through formal training because it requires participation in the culture itself. New members absorb it indirectly over months of working alongside the team. There's no workaround for this except time and immersion. The classification system also doesn't help when the volume of knowledge exceeds what any team can maintain. In large organizations with dozens of services, the explicit knowledge base becomes enormous and nearly impossible to navigate. The signal-to-noise ratio drops until the documentation is functionally useless. In those cases, the practical solution is usually to reduce the scope of what needs to be documented rather than to improve the documentation system. Focus on the knowledge that prevents the most costly mistakes. Everything else is noise.
There's also a limit to how much tacit knowledge can be transferred regardless of effort. Some skills require a minimum threshold of hands-on experience that can't be shortcut. No amount of reading, pair programming, or walkthroughs replaces the actual repetition needed to develop pattern recognition. If you're trying to onboard someone quickly, you're fighting against a hard constraint of human cognition. The best you can do is accelerate the exposure through deliberate, varied practice rather than hoping documentation will fill the gap.
