Something happens to organizations in the Summer and most of us feel it without naming it.

The building runs on a smaller crew. Half the people who normally answer within the hour are somewhere with their phone face down and quite a lot of what the organisation knows is away with them.
‍

This is when you find out what your organisation actually knows, as opposed to what a few individuals happen to remember.

For most of the year, the gap is invisible. When everyone is present, missing reasoning gets patched in real time. You don't understand why a process works the way it does, so you ask the person who designed it, and they explain it from memory in thirty seconds. The knowledge was never written down, but it was never missed either, because the carrier was at the next desk.

Summer removes the carrier. The person who could explain in thirty seconds is on a beach, and the same question now takes a colleague half a day of digging or worse, produces a confident guess that turns out wrong.

None of this is a crisis. It is mildly inconvenient, and it resolves itself in September. But it is a useful, low-stakes preview of a much larger problem, because the holiday gap and the permanent gap are the same gap.

When someone goes on leave, their knowledge becomes temporarily inaccessible. When someone leaves for good, or moves roles, or retires, that same knowledge becomes permanently inaccessible and there is no September to look forward to. The reasoning behind a decision they made three years ago doesn't come back from holiday. It is simply gone, and the record that remains confirms that the decision was made without explaining why.

Summer just makes the mechanism briefly visible.

So it is worth paying attention to what the quiet weeks reveal. Which questions can't be answered while a particular person is away? Which processes only really make sense to one individual? Where does the covering colleague say "I'll check when they're back" — and what would happen if they never came back?

Those are not summer problems. They are the year-round problems, wearing a lighter outfit.

The organisations that handle August well are usually the ones that already do the unglamorous work: capturing why things are done the way they are, not only how; keeping the reasoning behind decisions accessible to people who weren't there when they were made. For them, a colleague going on leave is a scheduling matter, not a knowledge outage.

For everyone else, summer is a two-month reminder that quite a lot of what the organisation knows is actually just what specific people remember.

The good news is that it's a gentle reminder. Nothing important usually breaks in August. But it's worth noticing what goes quiet while people are away, because the same silence arrives permanently, eventually, and with far less warning.

For now, though, if you're one of the people currently away-enjoy it. The reasoning will keep until September.

And if you're holding the fort: make a quiet note of every question you couldn't answer this month. That list is more valuable than it looks.

The views expressed in this article are my own and do not represent the position of my employer or any institution I am associated with.

_________________________________________________

  A lot of internal knowledge problems look small until
  they start slowing people down. A new hire cannot
  find the current onboarding guide. A manager keeps
  explaining the same approval process. A team follows
  an old workflow because the updated version sits in a
  private document. Training exists, but people still
  complete the same task in four different ways.

For KM teams, that is the real work. The goal is not to keep adding pages to a knowledge base. The goal is to make knowledge easier to collect, easier to trust, and easier to use when someone is trying to get work done.

That takes more than tidy folders. It takes a working system for turning scattered expertise into clear documentation, useful training, and internal processes people can actually follow.

Start by collecting better source material

Weak documentation usually starts before the writing begins.

If the source material is thin, rushed, or scattered across messages, the finished guide will feel the same way. It may explain the basic steps but miss the exceptions. It may describe what happens, but not who owns each part. It may sound clear to the subject matter expert and still leave a new employee guessing.

KM teams can avoid a lot of rework by treating knowledge capture as a separate stage.

Instead of asking someone to "send over the process," ask for the pieces that make the process usable. A good intake should pull out the trigger, owner, tools, approvals, common mistakes, exceptions, and update cycle.

A simple capture brief might ask questions like these.

• What starts this process?
• Who owns the decision or final approval?
• What tools, files, forms, or templates are involved?
• Where do people usually get stuck?
• What changes when the case is unusual?
• How often does the workflow need review?

That kind of structure helps experts share what they know without dumping a messy document into the KM team's lap.

A tool like Content Snare can fit here when teams need a cleaner way to collect documents, answers, and internal inputs from different people. For KM work, the benefit is less about gathering files and more about reducing the loose, forgettable back and forth that makes documentation harder than it needs to be.

Write for the person using the process

Many internal documents are written from the expert's point of view. That is why they often feel accurate but hard to use. The person reading the guide may not know the system, the team language, or the reason behind each step. They may be under time pressure. They may be trying to complete the task for the first time while a customer, manager, or colleague waits for an answer.

That changes how the document should be written.

A useful process page should explain what the person is trying to do, when the process applies, what needs to happen first, and what a good result looks like. The writing should be plain enough for someone outside the team to follow, but not so shallow that experienced employees have to chase missing details.

Good KM documentation often works in layers. The first layer gives the quick path. The next layer explains the steps. A deeper layer covers exceptions, edge cases, and ownership.

That structure keeps the page readable. It also respects the fact that not every reader needs the same depth at the same moment.

Connect documentation with training

Training and documentation often live in separate systems. One team owns the knowledge base. Another owns courses. Another owns the process itself.

Employees do not care about those boundaries. They just need to learn the task and do it correctly.

KM teams can help by building documentation that is easy to reuse in training. A clear process overview can become part of onboarding. A checklist can become a practice exercise. A set of common mistakes can become a short refresher lesson after the first month on the job.

This matters for recurring training needs such as compliance updates, system rollouts, customer handoffs, quality checks, and manager onboarding. If the source documentation is clean, the training team is not rebuilding the same material from scratch every time.

For organizations running structured learning programs, training administration software can help manage the operational side of that work. Sessions still need scheduling. Participants need tracking. Reminders need to go out. Certificates, attendance, and completion records need a reliable home.

KM teams may not run those systems directly, but their content feeds them. When the knowledge base is current and written in reusable pieces, training becomes much easier to maintain.

Make processes easier to follow in the moment

A process can be documented and trained, then still fail in daily use.

That often happens because the guidance is too far away from the work. Someone learns a workflow during onboarding, then needs it again three weeks later inside a tool they barely remember. If the guide is long or hard to find, they may ask a coworker, guess, or build their own shortcut.

For software based workflows, written instructions are useful, but screenshots and interactive guidance can remove a lot of friction. People often need to see the action, not just read the step.

That is where Supademo can support internal process adoption. KM or enablement teams can create walkthroughs that show employees how to complete common workflows inside the tools they already use.

This works well for approval requests, CRM updates, reporting steps, customer handoffs, account setup, or any task where the screen matters. The best walkthroughs stay narrow. One task. One user need. One clear outcome.

A broad tour of an entire system rarely helps much. A short walkthrough that shows exactly how to submit a request or update a record is far more useful.

Keep ownership visible

Knowledge gets stale when nobody is clearly responsible for it.

A process changes, but the guide stays the same. A form gets replaced, but the old link remains live. A team adjusts its workflow, but the training still shows last year's version.

KM teams can reduce this by making ownership part of every major knowledge asset. Each process page should have a named owner, a review date, and a simple way for employees to flag a problem.

The owner does not always need to be the KM team. Often, the subject matter expert should own accuracy, while the KM team owns structure, publishing standards, and clarity.

That split works well. Experts keep the details honest. KM teams make sure the knowledge stays readable, findable, and consistent.

Review timing should match risk. A compliance workflow may need a quarterly check. A low risk reference page may only need review twice a year. A tool walkthrough should be checked whenever the software changes.

Watch how people actually use the knowledge

Publishing a page is not the end of the work. KM teams need to know whether the guidance is helping. Page views can offer clues, but they can also mislead. A heavily viewed page might be useful. It might also be so confusing that people keep coming back because they cannot get what they need the first time.

Better signals come from daily friction. Repeated questions. Slow onboarding. Missed steps. Search terms that lead nowhere. Training completion with the same mistakes still showing up afterward.

Those signals tell the KM team where the system needs attention. Maybe the answer exists but uses the wrong language. Maybe the process is documented but not connected to training. Maybe the guide is clear, but the workflow itself has too many awkward handoffs.

The strongest KM teams treat these signals as feedback, not failure.

Build the loop, then keep it moving

Good KM work has a rhythm. Teams collect knowledge from the people closest to the work. They turn it into clear documentation. They reuse it in training. They support adoption with guidance people can follow during real tasks. Then they refine the system based on questions, errors, and feedback.

That loop is what keeps internal knowledge alive.

For KM teams, the opportunity is practical. Help people find the right answer faster. Help new employees learn without drowning in scattered documents. Help process owners keep guidance current. Help the business stop relearning the same lessons every quarter.

A knowledge base can store information. A strong KM system helps people use it.

____________________

You probably remember someone like him: Tom, the senior policy expert who spent two decades at the institution. Tom remembered which decisions had been revisited three times before reaching their final form. Tom carried in his head the assumptions behind frameworks that now looked obvious but had been genuinely contested when they were designed.

Tom is "The Organisational Memory" :)

When he retired, the organisation held a warm farewell.Three months later, his former team faced a decision that depended on understanding why a key position had been taken eight years earlier. They found the approval. The minutes. The final document.They could not find the reasoning.It had retired with him.

‍The gap existing frameworks do not close
In a previous article, I introduced Structured Decision Continuity through the story of Sophia: every senior expert whose absence only becomes visible when the system that replaced her produces an answer that looks correct and is not.

The diagnosis is this: organisations do not fail because they lack knowledge. They fail because the continuity between their knowledge and their decisions is not governed.

SDC names that gap. At the centre of SDC sits the Control Layer, a practical model that examines whether the path from knowledge to decision is strong enough to survive over time.
‍

The Four Conditions
The Control Layer has four conditions. Each addresses a failure that senior professionals recognise but few organisations name explicitly

‍Validation
Was the knowledge behind this decision reliable and valid in context?

Validation ensures that information, analysis and expertise were sufficiently checked; not just accurate in isolation, but appropriate for the specific decision being made.

The failure mode is familiar: a recommendation sound in theory but built on data that no longer reflected organisational reality. Before closing any significant decision, one question is worth asking: what are we taking for granted that we have not actually tested.

‍Context
Will someone encountering this decision in three years understand the conditions that shaped it.

Context is the set of circumstances and constraints that existed at the moment a decision was made. It is why the decision made sense then; even if it looks different now.

Context is the component most commonly lost. It lives informally in the people who were present. When those people retire or move on, the context goes with them unless it has been deliberately preserved.‍

Alignment
Was this decision coherent with strategy and governance and is that coherence still visible?

The failure mode here is subtle. A decision can be fully aligned at the moment it is made and look disconnected two years later, not because it was wrong, but because the strategy moved and no one recorded what the decision was originally aligned to.‍

Traceability
Can someone follow the path from knowledge to decision and from decision to consequence?

This is the expert's failure. The decision was defended procedurally. But the reasoning left with the person who held it. Traceability ensures that reasoning does not have to leave when the expert does.‍

Four Questions Worth Asking

For any decision that will carry long-term consequences, four questions are enough:
- Was the knowledge behind this decision sufficiently checked?
- Is the context preserved?
- Is the alignment with governance and strategy visible?
- Can the path from knowledge to decision be followed later?

If the honest answer to any of these is uncertain, something is worth capturing before the people who hold the answer have moved on.‍

A Closing Thought

The expert who retired took something with him that no record system was designed to preserve. Not his knowledge; much of that existed in documents. What left with him was the reasoning that connected that knowledge to the decisions that had shaped the institution.

The SDC Control Layer does not prevent people from leaving. It ensures that when they do, the reasoning behind their most important decisions does not leave with them.

Structured Decision Continuity is a developing professional concept examining how organisations preserve the reasoning behind important decisions over time. This is the fourth article in a series contributed exclusively to the Knowledge Management Institute.

The views expressed in this article are my own and do not represent the position of my employer or any institution I am associated with.

_______________________

Every year, organizations invest millions of dollars in evaluations, research, monitoring systems, lessons learned exercises, and knowledge management platforms. Yet many continue to face implementation challenges that were clearly identified years earlier.

The problem is not a lack of knowledge.

The problem is the inability to consistently transform knowledge into action.

Over the past two decades, NGOs, governments, and development agencies have generated unprecedented volumes of information through evaluations, research, monitoring systems, operational reviews, and partnerships. Knowledge management systems have improved the way this information is collected, organized, and shared.

Yet access to knowledge alone does not guarantee better decisions or stronger results.

Beyond Knowledge Management

Knowledge management focuses on collecting, organizing, and sharing information. Organizational intelligence goes a step further. It is the ability to transform evidence, experience, and learning into decisions, adaptations, and actions that improve performance and results over time.

Many organizations measure success through knowledge production: evaluations completed, reports published, lessons learned documented, or knowledge products shared. However, knowledge accumulation is not the same as learning. An organization may know something because it has documented it. Learning occurs only when that knowledge influences future decisions and behaviors.

The issue is rarely a lack of evidence. Most institutions already possess more evaluations, research findings, and lessons learned than they effectively use. The real challenge is transforming available evidence into action.

What Evaluation Can Teach Us

Evaluation provides a useful illustration of this challenge.

Across sectors and organizations, evaluations frequently identify similar issues: weak stakeholder engagement, unrealistic assumptions, insufficient risk management, limited local ownership, weak coordination, or sustainability concerns.

Consider a project where an evaluation identifies weak adoption of agricultural practices because market access constraints were overlooked during project design. Three years later, another project encounters the same challenge despite similar lessons having been documented previously.

The lesson existed. The organization simply failed to apply it.

This raises an important question:

If organizations continue to identify the same lessons year after year, are they truly learning?

In many cases, evaluations reveal less about project performance than about an organization’s ability to absorb and apply knowledge over time. Organizational intelligence extends the value of evaluation by ensuring that evidence informs future decisions before similar problems occur.

From Knowledge to Organizational Intelligence

Organizational intelligence is not a new department or software platform. It is a way of using knowledge more effectively.

In practice, it involves systematically reviewing previous evaluations during project design, integrating external evidence into decision-making, identifying recurring patterns across projects, tracking whether recommendations are implemented, and monitoring how evidence influences strategic choices.

Organizations that make this shift move:

·      From lessons identified to lessons applied.

·      From information access to evidence-informed decisions.

·      From reporting results to improving results.

·      From knowledge production to knowledge utilization.

They are also better positioned to preserve institutional memory. Staff turnover, organizational restructuring, and fragmented systems often disconnect lessons from future decision-making, causing organizations to relearn what they already know.

Looking Beyond Internal Knowledge

Organizational intelligence also requires looking beyond internal knowledge.

Valuable lessons often exist in partner organizations, academic research, government data, professional networks, and previous interventions. Organizations that combine internal experience with external evidence are generally better equipped to challenge assumptions, identify risks, and strengthen decision-making.

The Role of AI

Artificial intelligence may accelerate this transformation.

While much attention focuses on AI’s ability to generate content, its greatest value may be helping organizations connect and synthesize knowledge that already exists but remains scattered across evaluations, reports, databases, research papers, and individual experiences.

AI can support literature reviews, evaluation synthesis, evidence discovery, and pattern recognition across large volumes of information. However, technology alone cannot create organizational intelligence. The greatest barriers to learning are often organizational behavior, incentives, leadership commitment, and culture rather than information availability.

From Information to Impact

Knowledge management remains essential, but the ultimate objective is not knowledge management itself.

The ultimate objective is evidence-informed impact.

Organizational intelligence serves as the bridge between information and impact, helping transform evidence into decisions, decisions into action, and action into improved outcomes.

Organizations must move beyond asking:

“What knowledge did we produce?”

and begin asking:

“What decisions, adaptations, and improvements were influenced by the knowledge we produced?”

In the end, organizational impact may depend less on how much knowledge institutions generate and more on whether they are willing and able to change because of what they know.

______________________________________

Executive Functioning as the Cognitive Core of Knowledge Work

Knowledge work in defense contracting is built on the foundation of human executive functioning. Every controlled document update, chain‑of‑custody action, and compliance‑driven workflow requires the coordinated use of working memory, inhibitory control, cognitive flexibility, planning, and sustained follow‑through.

These cognitive processes form the unseen architecture of daily performance, yet they are rarely acknowledged in the design of Knowledge Management systems. In environments where precision is mandatory and errors carry contractual, operational, or security consequences, the cognitive load placed on employees is substantial. A well‑designed KM system can serve as a cognitive scaffold, reducing friction and supporting the mental processes required for reliable, repeatable, and compliant work. When KM systems ignore these cognitive realities, they inadvertently increase the likelihood of mistakes, rework, and resistance to change.

Locus of Control as the Psychological Variable Behind KM Adoption

Julian Rotter’s theory of locus of control (Rotter, 1966) provides a powerful psychological lens for understanding why some employees embrace KM systems while others resist them. Individuals with an internal locus of control believe their actions meaningfully influence outcomes; they tend to engage with KM tools, follow workflows, and take ownership of documentation. Those with an external locus of control perceive outcomes as determined by external forces, such as leadership, IT, government customers, or “the system.” Defense contracting environments, with their rigid compliance requirements and shifting government direction, often push employees toward an external locus of control simply because so many variables feel outside their influence.

When KM systems are opaque, overly complex, or inconsistently applied, they reinforce this external orientation and create a sense of learned helplessness. Conversely, when KM systems are transparent, predictable, and cognitively supportive, they strengthen the internal locus of control by helping employees feel capable, informed, and in command of their work. This psychological shift is not trivial; it directly predicts whether employees will adopt new processes, maintain accuracy, and sustain engagement over time. (Albrecht et al., 2023)

Viktor Frankl and Meaning as a Driver of KM Engagement

Viktor Frankl’s work adds a deeper dimension by emphasizing that meaning is a psychological resource essential for human motivation. Frankl argued that people can endure almost any “how” if they understand the “why,” and this principle applies directly to KM adoption (Frankl, 1946). Employees do not engage with documentation, workflows, or repositories simply because they exist; they engage when they understand why these structures matter. In defense contracting, the “why” is profound: KM protects mission integrity, ensures audit readiness, preserves chain‑of‑custody accuracy, and safeguards national security.

When KM leaders communicate this meaning clearly, employees shift from passive compliance to active stewardship. Frankl’s insights remind us that meaning reduces ambiguity, strengthens an internal locus of control, and supports executive functioning by giving employees a coherent narrative for their actions. (Gillette, 2024) In this sense, meaning is not philosophical; it is operational. It is the psychological anchor that transforms KM from a bureaucratic requirement into a mission‑aligned practice.

The Interaction of Locus of Control and Meaning in Defense Contracting

The relationship between locus of control and meaning is especially important in defense contracting, where employees often feel constrained by external requirements. When individuals perceive that they have no influence over outcomes, their motivation declines, their cognitive engagement narrows, and their willingness to adopt new systems diminishes. (Chipperfield et al., 2016) Frankl’s emphasis on meaning provides a counterweight to this dynamic.

When employees understand the purpose behind KM processes, they begin to reclaim a sense of agency even within a highly regulated environment. Meaning reframes compliance from something imposed to something chosen. It shifts the external locus of control to an internal one by showing employees how their actions contribute to mission success (Spector, 1982, pp. 482-497). This psychological shift is essential for sustaining high‑quality documentation, accurate workflows, and consistent adherence to contract requirements.

KM Design That Supports Executive Functioning in Defense Contracting

Designing KM to support executive functioning requires intentionality and an understanding of cognitive architecture. (Designing a Knowledge Management System for Distributed Activities: A Human Centered Approach, 2005, pp. 355-380). Defense contracting environments are cognitively demanding, and KM must function as a cognitive exoskeleton that reduces load rather than adding to it (Bequette et al., 2020). This means structuring information in ways that align with working memory limits, reducing task switching by integrating tools, providing retrieval cues through consistent naming conventions and metadata, and offering visual structure through dashboards and status indicators. These design choices directly support the brain’s executive functions, making it easier for employees to initiate tasks, maintain accuracy, and complete workflows without unnecessary strain. (Langer et al., 2020) When KM systems are designed with cognitive architecture in mind, they transform from repositories into enablers of reliable performance.

KM Design That Strengthens Internal Locus of Control

Equally important is designing KM to strengthen the internal locus of control. Employees must feel that they can influence their outcomes, even within the constraints of government contracting. KM systems can foster this sense of agency by offering transparent workflows, allowing personalization of dashboards or views, involving users in the creation of taxonomies or SOP updates, and providing immediate feedback that confirms successful actions. When employees understand the rationale behind processes and see how their contributions improve accuracy, compliance, or mission readiness, they experience a shift from “I have to do this” to “I can do this.” (Spector, 1982, pp. 482-497) This psychological shift is essential for adoption, accuracy, and long‑term engagement. In this way, KM becomes not just a technical system but a psychological intervention that strengthens autonomy, competence, and ownership.

Final Thoughts: KM as a Cognitive‑Behavioral System

All these points show that KM is not just about technical processes; it shapes how people think, act, and feel about their work. Frankl teaches that people work harder when they know why their effort matters. Rotter’s work shows that people use systems more when they feel they have some control. If KM systems help people remember steps and show that their actions matter, employees will use them more, make fewer errors, and be more willing to try new things. In defense contracting, where accuracy is essential, using KM systems designed with psychology in mind directly supports better work and improves employees' job satisfaction.

References

(2005). Designing a Knowledge Management System for Distributed Activities: A Human Centered Approach. International Journal of Human-Computer Studies 62(3), pp. 355-380. https://doi.org/10.1016/j.ijhcs.2004.11.001

Albrecht, S. L., Furlong, S. & Leiter, M. P. (2023). The psychological conditions for employee engagement in organizational change: Test of a change engagement model. Frontiers in Psychology 14. https://doi.org/10.3389/fpsyg.2023.1071924

Bequette, B., Norton, A., Jones, E. & Stirling, L. (2020). Physical and Cognitive Load Effects Due to a Powered Lower-Body Exoskeleton. Human Factors 62(3). https://doi.org/10.1177/0018720820907450

Chipperfield, J. G., Perry, R. P., Pekrun, R., Barchfeld, P., Lang, F. R. & Hamm, J. M. (2016). The Paradoxical Role of Perceived Control in Late Life Health Behavior. PLOS ONE 11(3). https://doi.org/10.1371/journal.pone.0148921

Frankl, V. E. (1946). Experiences in a Concentration Camp. International Journal of Psycho-Analysis, 27, 57–60.

Gillette, H. (2024). Logotherapy: Finding Meaning in the Face of Extreme Distress. Healthline. https://www.healthline.com/health/logotherapy

Langer, M., König, C. J. & Busch, V. (2020). Changing the means of managerial work: effects of automated decision support systems on personnel selection tasks. Journal of Business and Psychology 36. https://doi.org/10.1007/s10869-020-09711-6

Rotter, J. B. (1966). Generalized expectancies for internal versus external control of reinforcement. Psychological Monographs: General and Applied, 80(1), 1–28. https://doi.org/10.1037/h0092976

Spector, P. E. (1982). Behavior in Organizations as a Function of Employee Locus of Control. Psychological Bulletin 91(3), pp. 482-497. https://doi.org/10.1037/0033-2909.91.3.482

______________________________________________