Vol. III · Essays on work after AI
Saturday, October 3, 2026
evolving.work
Knowledge · Org Design · Essay № 004

Fine-Tune Your Organization

Your company spent millions on knowledge management. The return was a graveyard with excellent uptime. Here's what organizational fine-tuning looks like instead.

A company can spend millions on knowledge management and still leave people unable to find what they need. The result is a graveyard with excellent uptime.

I have seen this pattern repeatedly. The average large enterprise loses $47 million a year in productivity because the information people need either cannot be found or does not exist in any system. Knowledge workers burn 2.5 hours every day searching — and those searches succeed only half the time. The other half of those searches leaves them rebuilding what already existed somewhere in the archive, or guessing. And sometimes the guessing is indistinguishable from the finding, which tells you something about the archive.

Another vulnerability is that 42% of institutional knowledge lives exclusively inside individual employees’ heads. Not documented. Not shared. Not even hinted at in any system. When those people leave, the knowledge leaves with them — permanently. (This is the problem I explored in “The Expertise Cliff.” This article is about what to do about it.)

The Graveyard Tour

Every generation of knowledge management promised to fix this. The pattern is almost comically consistent.

Corporate communication departments used to distribute intelligence summaries by fax — curated, timely, useful. Then intranets launched with fanfare in the mid-1990s and became static link farms within months. Wikis democratized contribution. SharePoint centralized everything into a labyrinth that required its own training. Confluence made it collaborative. RSS promised to personalize the flow so people could stop reading things that did not apply to them — until publishers recoiled behind paywalls, and the feeds shrank to title-only teasers that nobody clicked. Reports, newsletters, all-hands decks, Slack channels with pinned messages nobody unpins.

Each tool solved a distribution problem. None touched the knowledge problem.

Twenty-one percent of the workday goes to searching for information. Another 14% goes to recreating information that could not be located. Over a third of knowledge worker time, consumed by the friction of systems that store documents and call it knowledge management. And the participation numbers tell the real story: only 10% of employees share content on corporate platforms, and 1% create 90% of what exists.

The documents were never the knowledge.

From Fax Summaries to Fine-Tuning

Two changes make a different approach possible: extracting knowledge during normal work and making it available in a form that models can use.

People were paid to do their work, while contributing to the wiki meant stopping to explain it, tag it, and hope someone would find it later. The effort of contributing exceeded the benefit of retrieval. That imbalance undermined each earlier approach. Now, AI extracts knowledge passively from the exhaust of normal work — meeting transcripts, Slack threads, code reviews, support tickets — without requiring anyone to stop and contribute. And LLMs can consume and synthesize atomic knowledge in ways that make captured information immediately useful, breaking the “nobody reads the wiki” problem that killed every predecessor.

Ikujiro Nonaka identified the real bottleneck thirty years ago: Externalization, the conversion of tacit knowledge into explicit, shareable forms. Every KM system since has attempted externalization at the document level. A thirty-page post-mortem. A recorded all-hands. A best-practices PDF that nobody opens after the first week.

The unit of storage has always been the document.

The Fine-Tuning Parallel

Model fine-tuning offers a useful comparison for how to prepare organizational knowledge.

When researchers fine-tune a language model, the quality of the output depends on the quality of the training data — not the volume. In one documented case, a 66-page user guide was condensed into 60 well-structured rows of curated data. Those 60 rows produced measurable model improvement. The massive unstructured document did not.

Sixty rows beat sixty-six pages. Not because minimalism is a philosophy worth adopting, but because curated, atomic, verified data changes a model’s default behavior in ways that bulk document dumps cannot. If you have ever watched an intern try to learn from a 200-page onboarding wiki, you have seen the human version of this failure.

Most enterprises are betting on RAG — Retrieval-Augmented Generation — which searches your existing documents and hopes the relevant passage surfaces. At enterprise scale, that hope degrades fast. RAG assumes coherent, well-organized source material. Enterprise knowledge exists in fragmented systems with domain-specific jargon that confuses retrieval mechanisms and multi-hop reasoning requirements that remain a fundamental weakness.

But the thesis here is not anti-RAG. It is about what you feed any retrieval system. Atomic knowledge curation is upstream of retrieval method: whether you use RAG, fine-tuning, or future hybrid approaches, the quality of your underlying knowledge determines the quality of your output. Better RAG over garbage documents still returns garbage with higher confidence.

The comparison has limits. Organizations are not loss functions. You cannot backpropagate through a management hierarchy — though I have seen people try. But the principle that curated, verified atomic data outperforms bulk document dumps holds in both domains. Fine-tuning changes a model’s default responses. Organizational fine-tuning — building verified atomic knowledge with quality gates — changes an organization’s default decisions.

That is the difference between a searchable wiki and genuine institutional capability.

What Organizational Fine-Tuning Looks Like

The comparison becomes useful when we look at how someone finds a reliable answer to a specific problem. Organizations have been doing this for decades without calling it fine-tuning.

Xerox Eureka is the clearest case. In the late 1990s, Xerox had over 25,000 field service engineers carrying thick diagnostic manuals that frequently failed them. The real solutions lived in individual engineers’ heads, scattered across continents. Instead of building another document repository, Xerox created a system for capturing atomic, verified solution tips — discrete problem-solution pairs, peer-validated before entry. A Brazilian engineer facing a potential $40,000 equipment replacement found that a Canadian colleague had entered the fix hours earlier. Cost of the actual repair: ninety cents.

Eureka grew to 35,000 validated tips, saved an estimated $100 million, and achieved a 19% engineer contribution rate — nearly double the typical enterprise KM participation rate. It worked because the unit of capture matched the unit of use.

Contribution remains a practical obstacle. People will not voluntarily feed yet another system — history has proven that conclusively. But Eureka succeeded through professional credit and peer validation that gave contributing engineers standing among colleagues. The AI-era version goes further: tools like Stack Internal now extract atomic Q&A pairs from existing work artifacts, with human-in-the-loop verification rather than mass voluntary participation. A small curation team processing the exhaust of normal work, not an all-hands mandate that everyone ignores.

Toyota demonstrates what this looks like sustained over decades. Job Instruction documents break every task into atomic “key points” with reasons — not steps, but the judgment calls that determine quality. Quality Circles meet weekly to analyze performance and produce verified countermeasures. When Toyota opens a new factory, 200-300 new employees spend months embedded in existing operations, absorbing tacit knowledge through direct practice. The knowledge transfer process typically produces operations matching existing factory quality within 12-18 months. Toyota does not dump manuals on new workers. It curates atomic knowledge, validates it through peer review, and internalizes it through repeated practice.

NASA’s Lessons Learned Information System proves the thesis by counterexample. After Challenger and Columbia, NASA mandated a centralized lessons-learned database. Aside from JPL, no NASA Center consistently contributed for six years. A meta-analysis of 112 mishap reports revealed the same root causes recurring across decades. The organization was storing lessons but not learning them. What actually worked at NASA was informal: knowledge-sharing workshops and mentor-apprentice relationships that transmitted atomic, contextual knowledge — “when you see X, the real problem is Y.” The human equivalent of fine-tuning. But it did not scale, and that is the central tension.

Across these cases, the useful knowledge reached someone facing a specific problem. Breaking it into claims or solution tips made it possible to check, share, and use. Storing the documents alone did not accomplish that.

The Atomic Enterprise: A Framework

Six steps. Each maps to the fine-tuning parallel. Steps 1-3 are process changes any team can implement this quarter. Steps 4-6 require integration with existing tools and workflows — they are where most implementations stall, and where executive sponsorship becomes non-negotiable.

1. Audit the Graveyard. Inventory your top five knowledge repositories. For each, measure the percentage accessed in the last 90 days and the percentage that influenced a documented decision. Then survey twenty frontline workers: “When you need to solve a problem, where do you actually go?” The delta between official repositories and actual behavior is the size of your graveyard. A 50,000-page SharePoint with a 3% access rate is a storage cost, not a knowledge asset.

2. Extract Atomic Claims. Decompose documents into discrete, verifiable assertions — each with a source, date, confidence level, and expiration trigger. “Enterprise customers in DACH require on-premise deployment for deals above 500K” is an atomic claim. “See the Q3 competitive analysis” is a document pointer masquerading as knowledge. Start with four domains: customer intelligence, operational expertise, competitive intelligence, and institutional knowledge worth preserving before its holders retire. Target 50 verified claims per domain in the first sprint. The fine-tuning research shows that 60 well-structured rows outperformed massive datasets. The same principle applies to your organizational memory.

3. Build Verification Loops. A curation team of three to five domain experts — not a committee, a working team. Every claim earns credibility through peer review rather than assuming authority. Unverified claims are worse than no claims because they manufacture false confidence. Score each claim on source quality, corroboration, and recency.

4. Structure for Combination. Connect claims in a knowledge graph: supports, contradicts, extends, supersedes. You cannot meaningfully link page 14 of one PDF to paragraph 3 of another. You can link atomic claims. Surface contradictions — “Claim A says X, Claim B says not-X” — because those are the highest-value findings. They expose where the organization holds conflicting beliefs and does not know it.

5. Activate Through Workflows. Push verified claims into decision moments rather than building a repository people must remember to visit. Surface customer claims during sales calls. Surface incident knowledge during triage. Surface competitive intelligence during product planning. If adoption requires people to change their behavior to consult a new system, the system will fail. Every previous KM generation died at this exact layer.

6. Measure and Retrain. Track coverage, freshness, and impact — not activity metrics. NASA’s LLIS had impressive login numbers while the same failure patterns repeated for decades. Judge the result by whether decisions improved, knowledge gaps closed, and the same mistakes stopped recurring. Those are the outcomes that matter.

One risk is that verified claims can calcify into false confidence when they go stale. A document is obviously dated — people discount a 2019 market analysis intuitively. But an atomic claim marked “verified” carries institutional authority even after it expires. The countermeasure is borrowed from ML practice: claim expiration dates, automated staleness flags, and periodic re-verification cycles. A discrete claim with a source, date, and confidence score is still easier to audit for staleness than a buried assertion on page 47 of a PDF that nobody remembers writing.

The Graveyard Stays Open

Ninety-five percent of enterprise AI pilots fail, and the primary reason is not the models — it is the lack of reliable, human-validated knowledge bases. Better AI does not fix worse knowledge. It amplifies it.

Meanwhile, 10,000 Baby Boomers retire every day, each carrying decades of tacit expertise that no document repository has captured. The window for extraction is closing, and organizations that wait for better retrieval technology to solve the problem are making a bet against a demographic clock that does not negotiate.

This requires a sustained organizational commitment. Organizational fine-tuning is not a technology deployment. It is a decision to treat knowledge curation as a core competency — with dedicated roles, executive sponsorship, and sustained investment. Without that commitment, the initiative dies at the first budget cut, and you have built one more graveyard with one more interface.

Pick a domain where people regularly need an answer they cannot find. This quarter, extract and verify a small set of claims, then put them into the decisions where they are needed. Judge the pilot by whether that work improves, before turning it into a platform evaluation or an RFP.

Your organization has been storing documents and calling it knowledge for thirty years. The AI era does not reward the organizations that stored the most. It rewards the ones that curated the best — and made it atomic enough for both humans and machines to reason over.

The colleague facing the next unfamiliar problem should be able to use what someone else has already learned. Whether that happens is the test of the pilot.


References

About the author
Héctor Reinoso writes about how organizations should be designed when intelligence becomes abundant. He works on enterprise AI adoption inside a large industrial organization, after 25 years as a strategy consultant and transformation executive across four continents. Harvard MBA, industrial engineer, and still writes the code he writes about. More →