HomeKnowledge CenterKnowledge Is the Fuel of Institutional Capability

Knowledge Is the Fuel of Institutional Capability

How knowledge turns from a silent archive into fuel for everyday decisions, and what makes a knowledge practice actually work instead of becoming a graveyard of pages.

25 Jun 2025RAISO Experts Team

Knowledge Is the Fuel of Institutional Capability

Picture a junior analyst in his third week facing a problem he has never seen: complaints suddenly rising and nobody knows why. In the next room sits an experienced colleague who saw this pattern three years ago and found the cause in ten minutes. But the colleague is in a meeting, and the analyst needs a decision today. This is where an organization is tested: does it know what it knows, and can it put that in the hands of whoever needs it at the moment they need it?

This article argues that knowledge in an organization works like fuel. It has no value sitting in a distant tank. Its value lies entirely in reaching the engine at the right time. Knowledge management is not archiving documents. It is arranging that arrival, so that today's decision benefits from yesterday's experience.

We will follow one case from start to finish: Hind, head of an analysis unit at a service company, and her new analyst Faisal, who met a rise in complaints without finding anything to help him. You will learn why most knowledge initiatives stall, which four traits make a practice work, and how to build them in five simple steps, with a short exercise after each.

“Hind, Faisal, their company and the figures in this article are a hypothetical case for illustration and do not refer to any real organization.”

— Hypothetical case

Faisal faces a diagnosis he has never made

Faisal is a new analyst in the analysis unit Hind runs. On Tuesday morning the services director asked him for an urgent report: why had complaints about delays risen sharply this week? He had three days, and he had never diagnosed anything like it.

He opened the company's internal portal and typed «rise in complaints» into the search box. Forty-one results came back. Some were quarterly reports four years old, some were slide decks with no explanation, and one was titled «Lessons Learned» without a single lesson inside. He spent four hours reading and came out with a list of generic causes that could be said of any organization: workload, understaffing, shifting demand.

That evening, as he was leaving, he caught sight of Abdullah picking up his bag. Abdullah is a senior adviser in the unit, twelve years with the company. Faisal described the problem briefly, and Abdullah stopped. «Complaints after a system update? Check the automatic notifications schedule. It happened twice before, and the cause was that the notification went out a full day late after the update.» Faisal opened it the next morning and found it exactly as Abdullah said.

“The knowledge that solved the problem had existed in the company for three years. It simply was not in the portal.”

— What the case reveals

Notice what happened. The company did not lack information; it had hundreds of documents. It did not lack clever people; it had Abdullah. What it lacked was the road between the two. Abdullah's grasp of the «complaints after the update» pattern lived in his head alone. Had he been absent that day, Faisal would have lost a week, and a wrong report might have gone to the services director.

What did this stroke of luck cost?

  • Time: four hours of a new analyst spent reading documents that did not help.
  • Quality: the first report would have carried generic causes that sound plausible and are wrong.
  • A decision: had the diagnosis slipped a week, customers would have kept complaining and management might have treated the wrong problem.
  • Dependence: solving the problem hung on Abdullah being in the room at the right moment.
The price of luck: the numbers in Faisal's story - The knowledge existed in the company. The path to it did not.
Illustrative numbers

Consider one more angle. Nobody asked Abdullah because nobody knew he held this knowledge. Faisal met him by chance. In an organization of hundreds, chance is not a plan. Had Faisal sat in another building, or had Abdullah left an hour earlier, the story would have ended differently.

“Think of the last time you solved a problem at work thanks to someone you happened to meet. Was the answer somewhere you could have reached without meeting anyone?”

— A question to reflect on

“Five minutes, now: write down one problem that recurs in your work, then the name of someone in your organization who solves it quickly, and where that knowledge is written down. If the answer is «I don't know» or «in their head», you have found your first missing knowledge asset.”

— A short experiment

Why did the portal not hold what Faisal needed?

Ask Hind how her company handled knowledge and she will say: «We invested.» That is true. Five years ago the company bought an internal portal, added a search engine, and ran a campaign urging staff to upload their reports and lessons. Thousands of files went up in the first year, and everyone applauded.

Then what usually happens, happened. Enthusiasm faded after a year, because nobody was asked to follow up. Uploading became an extra burden at the end of each project, done by tired people in a hurry. Files were titled generically, like «Final project report», and nobody said what the lesson was. Nobody checked whether a file was still right after the system changed. Five years on, nobody trusted what was in the portal, so people asked each other instead of searching.

The mistake most initiatives make

The mistake is starting from the tool. The company bought a container and asked people to fill it, without asking: which knowledge matters to us, for whom, who looks after it, and how does it stay correct? It is like building a fuel station in the desert and waiting for someone to bring the fuel.

The result is what people call a knowledge graveyard: old pages nobody trusts and nobody deletes, crowding out the good pages Faisal never found. The graveyard widens as uploads grow, because each new file without a keeper goes stale before anyone notices.

Start from the tool or the decision? - The order is the difference between a graveyard and working knowledge.

Three signs that you started from the tool:

  1. People ask each other instead of searching.

    Once the portal loses trust, staff return to the older method: who knows?

  2. Uploads grow while use does not.

    The organization counts files uploaded and never asks whether anyone used one in a decision.

  3. Nobody knows who updates this file.

    A file with no keeper is slowly dying, however good it was when uploaded.

If you see one of these, the answer is neither a better tool nor a bigger campaign. The answer is to start from somewhere else, which we explain next.

What do we mean by knowledge, and why call it fuel?

In this article, knowledge is whatever enables a person to take a decision or carry out work better than they would without it. That separates it from information. That complaints about delays rose this week is information. That a rise right after a system update usually points to late automatic notifications is knowledge, because it changes what Faisal will do the next day.

Knowledge has two faces. One is written, like a checklist, a guide or a template, and is easy to move. The other is tacit and lives in people's experience, like Abdullah's instinct when he heard the words «after the update». It is harder to move but more valuable. A good practice does not settle for either: it turns the tacit into the written whenever it can, and it gives the written a road to the person who needs it.

Why fuel?

Because fuel is worth something only when it moves something. A full tank beside a car that does not run makes no journey. In the same way an organization with thousands of files that has not changed a single decision with them has gained nothing. And fuel gets consumed: every trip needs new fuel. Knowledge is the same, it needs renewing, because systems change and customers change and old knowledge can turn wrong.

Five steps, four traits - Each step builds one trait of a practice that works.

This is why we measure institutional capability with a simple question: how much of the experience accumulated in the organization reaches today's decision? In an organization with high capability, a junior analyst gets what an expert got after ten years, because what the expert learned has moved from their head to a place the junior can reach.

“Knowledge that never reaches a decision is not institutional knowledge. It is the private property of whoever carries it.”

— The idea of this article

Four traits separate a practice that works from one that does not: clear ownership, capture inside the work, fast search, and review by effect. We will build each trait in a step, beginning with a step that comes before all of them: knowing which knowledge we want.

Which decisions deserve written knowledge? - Pick decisions that recur and are costly when wrong.
Simplified framework drawn from step one

Step one: start from the decision, not the tool

The problem this step solves is that the organization tries to keep everything, and the knowledge that matters gets lost among the rest. Not every piece of information can be fuel. What you need is to know which decisions recur in your organization, which are costly to get wrong, and which depend on a single expert.

Write a short list, five to seven decisions, each phrased as a question a real employee asks: «Why did complaints rise?», «Do we accept this exception?», «How long does this kind of contract take to install?» Then ask of each: what knowledge changes the answer? Where is it today? In a document? In a person's head? Nowhere?

That list is your map. One good asset tied to a recurring decision is worth a hundred files tied to none. And if you find a decision whose entire knowledge sits in one person's head, mark it red. That is where you start.

In the case now: Hind sat with Faisal, Abdullah and three others from the unit and they wrote six recurring decisions. One was «Why did complaints rise?», the decision that had depended on Abdullah. They found that the knowledge behind three of the six lived in just one person's head, and made those the priority.

“Apply it now: write five decisions that recur in your team, phrased as questions. Beside each, write where its knowledge lives today: a document, a person, or nowhere. Mark every decision whose answer is «a person».”

— Step one exercise

Step two: name a keeper for every knowledge asset

The first trait is ownership. The problem is that an asset with no keeper grows old. In Hind's company a «complaints report» file was uploaded every quarter and owned by nobody. When the system changed nobody edited it, so it went on describing a system that no longer existed.

The keeper is not necessarily the author. It is whoever gets asked: is this still right? When was it last reviewed? The keeper has three simple tasks. To define who needs this asset and for which decision. To review it on a fixed date, say every quarter. And to decide when it is deleted or merged into another. It is fine for the keeper to be the person who holds the knowledge in the first place, and Abdullah is the natural choice for the asset on diagnosing complaint rises.

Write the keeper's name and the date of the last review at the top of the asset itself. A reader who sees «Keeper: Abdullah, last reviewed: last month» trusts it more than a thousand pages that carry neither name nor date.

In the case now: Hind asked Abdullah to keep a single asset, «a guide to diagnosing a rise in complaints». He did not refuse, but he said: «My time is tight.» They agreed on one hour every three months for review, placed in his official schedule so it would not become an extra burden that gets forgotten.

“Apply it now: pick the asset tied to one of the decisions you marked. Write its keeper's name and its next review date at the top. If you cannot find anyone to take it on, the asset is not yet a priority.”

— Step two exercise

Step three: capture inside the work, not after it

The second trait is embedding in the workflow. The problem is that when capture is a separate step at the end of a project, it is done late and without enthusiasm. By the time an analyst finishes a report, memory is fading, energy is spent, and anything not demanded of them will slip.

The fix is to move the moment of capture inside the process itself, at the moment the knowledge is produced. When Faisal discovers that the cause was late notifications, that is the best moment to record the pattern, because the details are alive. Make it a small step inside the report template: a field that asks «What pattern did you find, how did you recognize it, and what might recur?», filled before the request is closed.

Keep the capture short. Three sentences beat a page. What matters is that the asset says three things: when this pattern occurs, what sign points to it, and what the first check is. Those three are exactly what Abdullah told Faisal in thirty seconds.

In the case now: Hind added a «pattern discovered» field with the three questions to the diagnosis report template. When Faisal wrote his late report, he filled it in himself from fresh experience, and Abdullah reviewed it in five minutes and added a point Faisal had missed. The company had its first real asset, and it cost fifteen minutes rather than a day.

“Apply it now: choose one template you use at work, a report, a request or minutes. Add a three-question field that captures what you learned this time. Use it on your next piece of work.”

— Step three exercise

Step four: make it findable in under a minute

The third trait is searchability and browsability. The problem is that knowledge, however good, if not found quickly, will be reproduced or ignored. Faisal spent four hours, and when he found nothing, luck rescued him, not search.

The rule we suggest is simple: a new analyst should find the right asset in under a minute, in their own words, not the author's. That takes three cheap things. First, a title that describes the problem the asset solves, not its subject: «Complaints rising after a system update», not «Lessons Learned 2022». Second, a few tags in the staff's own language. Third, a landing page built around the decisions you listed in step one, so an employee sees the decision and then the asset tied to it.

Test it as a user would. Ask a newcomer to look for the answer to a real question and time them. If it goes past a minute, rework the title or tags, not the asset itself.

In the case now: Hind renamed the asset and put it on a page titled «Questions that recur in analysis». Then she asked a new employee to search for «why did complaints rise?» and the guide came up in forty seconds. She did not delete the old files wholesale. She moved anything not reviewed in two years to an «Archive» folder outside the default search.

“Apply it now: ask a new colleague to find the answer to a question from your list using search alone, and time them. If it takes longer than a minute, change the title or tags until it takes less.”

— Step four exercise

Step five: review by effect, not by storage

The fourth trait is review on output. The problem is that most organizations measure the activity of knowledge: how many files were uploaded, how many pages visited. Those numbers reassure everyone, but they do not say whether anything changed. A file that is read and then affects no decision is a lost file.

Test your practice: is knowledge fuel for you?
#TraitQuestionMetPartly metNot met
Decision
1DecisionHave we written a short list of recurring decisions as questions?
2DecisionDo we know where each decision's knowledge sits: a document or a person?
Ownership
3OwnershipDoes every key asset have a named keeper and a last-review date?
4OwnershipIs review time part of the keeper's official work schedule?
Capture and search
5CaptureDo our work templates have a field that captures what we learned right then?
6SearchCan a new employee find the right asset in under a minute?
Review
7ReviewDo we ask: did this asset change a decision?
8ReviewDo we review quarterly and remove what is not used?

Answer each question honestly, then start with the weakest.

Ask instead: did this asset change a decision, and how do we know? Choose two simple measures for each important asset. The first is the number of times it was used in a real decision, and a short question at the close of a request is enough: «Did you use a guide from the knowledge base? Which?» The second is the time a decision of this kind took before the asset and after.

Review every quarter with two questions: which assets were used, so we develop them? And which were not, so we reconsider or delete them? Deletion is part of health, because knowledge nobody uses crowds out the knowledge people do.

In the case now: two months later a similar pattern appeared in late customer invoices. Another analyst diagnosed it with the guide and finished in one day instead of three. When Hind asked whether he used anything from the guide, he said he followed its first step and then added a new note about invoices. Abdullah added the note to the guide, and one asset grew where before there had been a dead file.

“Apply it now: at the end of the template you adjusted, write one question about the asset's effect on the decision. Collect answers for a month, then count how often the asset was actually used.”

— Step five exercise

Hind, three months later

At the end of the quarter Hind returned to the opening scene: a new analyst and a problem he had never seen. This time the newcomer was Sultan and the problem was an unexplained delay in processing requests. Sultan opened the page «Questions that recur in analysis», found an asset resembling his case, followed its steps and found the cause within two hours.

That day Abdullah was on leave. Nobody called him and the problem did not wait. When he returned a week later he found a note awaiting his review: Sultan had added a new pattern. Abdullah felt that his expertise was no longer tied to his presence and was growing without him, and he took pride in it rather than fearing for his place.

Hind did not buy a new tool. She rearranged the questions: from decision to asset, from asset to keeper, from keeper to review. That is what it means for knowledge to become fuel: not a stored quantity, but a steady flow from experience to decision.

What do you take with you?

Institutional knowledge is not an archive. It is the ability for what the organization knows to reach whoever needs it when they need it. It does not last through tools. It lasts through a practice that has a decision to serve, a keeper who looks after it, and a rhythm that renews it.

The five steps in brief:

  1. Start from the decision

    List the recurring decisions and find where each one's knowledge lives today.

  2. Name a keeper

    Every asset carries a name and a review date at the top.

  3. Capture inside the work

    A short field in the template, filled while memory is fresh.

  4. Make it findable in a minute

    A title in the language of the problem, a few tags, a landing page ordered by decisions.

  5. Review by effect

    Did the asset change a decision? What do we develop, and what do we delete?

Start this week with one asset only, tied to the decision that depends on the fewest people in your organization, and ask its expert: what would you tell a new analyst in thirty seconds? Write it down and put a keeper's name on it. And if you want to build a complete practice, RAISO's knowledge management practice courses guide you through these steps on a case from your own organization, with ready exercises and tools. Get in touch and we will help you choose the first asset to begin with.