The Filing Cabinet Was Never the Point

There is a form of institutional intelligence that development programmes run on but rarely write down: the ASHA worker who knows which households will resist a new health campaign before the outreach team reaches the door; the district coordinator who changes logistics because the lane behind the market floods every July; the facilitator who knows that women in a specific block will speak candidly only after the men have left the room.

None of this appears in a quarterly report. It rarely travels beyond the person who holds it. When that person moves on, or the project ends, or the reporting format changes, the knowledge leaves with them. The loss is unmeasured. Often, it is not even noticed.

This is what knowledge management is supposed to prevent. In too many development programmes, it still does not.

What we got wrong about what KM is for

For much of my career, I have watched organisations treat KM as a documentation function. Count the knowledge products. Fill the repository. Run the end-of-project lessons-learned review. Tick the box in the M&E framework.

Those things have their place. But they measure production, not learning. Over time, we have aligned KM more with compliance than with programme intelligence. Repositories become places where reports are uploaded once the donor requirement has been met. The file is stored. The learning is assumed.

The problem was not that we lacked a system. It was that we mistook the system for the point.

A well-indexed server cannot tell a programme manager in Odisha whether a method piloted in Rajasthan will work under different social, political, or operational conditions. It cannot tell a state team whether a field observation is a minor variation or an early warning signal. That requires judgment. It also requires KM to sit inside programme decision-making, not outside it as a documentation service.

KM belongs in the theory of change, not the annexure

The structural problem is simple: KM is often brought in after the real work has happened. Documentation begins once implementation is already underway. Reflection happens when there is finally time, which often means when the team is tired and the project is close to ending.

This is backwards.

If a programme is going to learn, the conditions for learning have to be designed from the start. Where are we likely to encounter things we did not expect? Who is allowed to call for a course correction? What does that correction look like in practice? How does a field signal reach a decision-maker while there is still time to act?

Adaptive management is a phrase the sector has adopted with enthusiasm. But adaptation requires information arriving at the right moment, not six months after the decision point has passed. A lessons-learned review conducted after a project closes is useful. It is not adaptation. The distinction matters, and programmes that blur it are not adaptive. They are retrospective. If KM is not mapped to the programme's decision points, review meetings, and course-correction gates, it is not operational infrastructure. It is an annexure.

The silo problem is a design problem

I have worked inside organisations running several programme verticals: health, nutrition, education, social and behaviour change, WASH, and child protection. The teams share a logo. They share an annual report. They often share very little knowledge.

Each vertical generates learning. Field observations, mid-term corrections, adaptations that worked, dead ends that cost the team months. Yet much of that learning remains inside the section that produced it.

The result is familiar. A WASH team learns that community mobilisation works better when it is co-facilitated with the health team. Three years later, the nutrition team reaches the same conclusion after its own round of trial and error. Nobody connected the two moments. Nobody was clearly responsible for doing so.

This is not a personal failure. It is what happens when organisations are designed to move outputs upward to donors, but not knowledge sideways across teams.

The missing link is rarely goodwill. It is structure. If programme targets reward vertical reporting but not lateral learning, teams will do what the system asks of them. They will prioritise the report due tomorrow over the lesson another team may need next month.

Fixing this requires more than a shared folder. It requires knowledge-sharing to become part of how the programme is managed. The KM lead should not be chasing teams at the end of a quarter, trying to reconstruct learning from meeting notes and memory. The KM lead should be close enough to the work to help teams capture the lesson while it is still alive.

This is where AI can help, if used carefully. Meeting notes can be captured and indexed. Field reports can be searched across themes. A colleague in one vertical can find a relevant discussion from another vertical without asking five people where it was stored. The barrier was not always reluctance. Often, it was time.

What AI can and cannot do here

KM professionals often respond to AI in one of two ways: quiet scepticism or easy enthusiasm. Neither is enough.

Some of what AI can do for KM is real. It can speed up work that has always been slow: synthesising field reports, finding repeated themes across large document sets, translating material across languages, and making meeting knowledge easier to retrieve. Used carefully, these tools can free KM professionals for the work that actually requires judgment.

But the risk is also real. AI is good at producing outputs that sound complete. A summary of fifty field reports may look coherent and well organised. It may also smooth away the edge cases, the precise anomalies that carry the most important insight. The Tuesday morning detail. The flooded lane. The twelve years of field experience behind one sentence in a supervisor's note.

Those details may not look like data to the system. To a programme team, they may be the difference between a good decision and a poor one.

AI does not decide what matters. That is still a human call, and it must stay that way.

The better question is: which KM processes are not happening because they take too long, or because the team does not have the time or skills to do them well? Start there. Use AI to remove those bottlenecks. Do not use it to replace the judgment function, because KM is not mainly about producing more material. It is about knowing which knowledge deserves attention, where it should travel, and what decision it should inform.

Context is the other issue. India does not function as a single development setting. A programme design that works in Kerala or Tamil Nadu may not work in the same way in Uttar Pradesh or Bihar. The point is not to rank states. The point is that context changes what knowledge is relevant.

AI can process more local material, faster. But if the categories are wrong, the synthesis will still be wrong. A system that flattens field variation into a neat national summary may look efficient while quietly removing the very knowledge a programme needs. Human practitioners must define the questions, check the assumptions, and decide which local differences matter.

Counting the wrong things

Ask many organisations what KM delivers, and you will hear about documents. The number of resources in the repository. The number of people at the lessons-learned session. The number of knowledge products disseminated.

These numbers are not meaningless. But they are activity counts. They do not tell us whether knowledge moved, or whether it changed a decision.

A better measurement frame would ask different questions:

• Instead of counting how many toolkits were uploaded, track whether a toolkit was used in a later programme decision.
• Instead of counting attendance at a learning session, track which recommendation from that session was applied within the next review cycle.
• Instead of counting the number of field reports submitted, track how many course corrections can be traced to field-level observations.

These questions are harder. They are also closer to the real value of KM.

KM's most important work is often the least visible: the lateral connection, the captured context, the bridge between what the field knows and what decision-makers hear.

It is not invisible because it does not matter. It is invisible because the sector has not built good enough ways to name it. Until KM professionals explain the value of this work more clearly, others will keep measuring the documents and missing the learning.

Where to actually start

None of this requires a new toolkit. It requires a different posture toward knowledge at the beginning of a programme cycle, not at the end.

At design stage, the questions are practical. Where is this programme most likely to encounter something it did not expect? Who already holds knowledge we need before we begin? What does a real course correction look like? Who has the authority to make it? How will the knowledge held by a frontline worker in month six still inform decisions in year three?

KM is not a function to call when the programme needs documentation. It is a way of working that is either built into how the programme operates, or it is not built at all.

The role of the KM practitioner is changing too. A KM professional who spends most of their time curating repositories and chasing end-of-quarter inputs is being kept too far from the real work. The role needs to move closer to programme design. It is about understanding where knowledge will be generated, who holds it, and what structure is needed to move it.

AI tools will take over more of the production work. That is not a threat if KM professionals use the space well. It gives us a chance to return to the work that needs a human being in the room: judgment, context, trust, and the ability to notice what the system might miss.

The communities this sector works with deserve programmes designed to learn from them, not just report about them. That is what KM, at its best, has always been about. The filing cabinet was never the point.

The team also made this

Radhika Also Got a Theme Song

We couldn't resist writing her one: 'Sense-Making Queen,' a full Bollywood number. Track and the story behind it live on KairoPact Labs.

Listen on Labs →