The Organisational Conditions That Turn Knowledge Into Consistent Performance
Organisations spend a great deal of effort trying to build capability. They hire experienced people, send employees on training programmes, introduce new systems, write procedures, establish competency frameworks and invest in leadership development. Much of this is sensible. Yet a striking number of these investments leave the organisation doing very much what it was doing before.
People attend the training and return to the same working habits. Experienced employees carry on solving the difficult problems themselves rather than teaching others how to solve them. A new system arrives without changing how decisions are actually made. People hold the knowledge required to act and still wait for approval, because nobody has told them they are allowed to use their own judgement.
The result is familiar to anyone who has worked in a large organisation. There are knowledgeable people everywhere, and capability remains uneven.
Article 3 argued that capability can be recognised long before it is formally measured. It is visible in how problems get solved, how knowledge moves between people, how teams coordinate, how heavily the organisation leans on a handful of experts, and whether experience actually turns into learning. But recognising capability and building it are different tasks. The more demanding question is what conditions allow capability to develop in the first place.
The short answer is that capability is not built by giving people more knowledge. It develops when people have the opportunity, authority, relationships, practice, and support required to turn what they know into consistent action. The rest of this article looks at what those conditions are and why each of them is harder to create than it first appears.
Knowledge Needs Somewhere to Go
An organisation can employ highly knowledgeable people and still remain dependent on individuals.
Someone knows exactly how to resolve a difficult customer problem. Another person understands a complex production process better than anyone else in the building. A manager has spent years handling situations that resist documentation. All of that is real knowledge, and all of it is valuable. But when the knowledge stays with the individual, the organisation has more or less borrowed it rather than acquired it.
The first condition for building capability is therefore the movement of knowledge between people. This sounds obvious, and it is routinely underestimated. Knowledge moves when experienced people work alongside less experienced colleagues. It moves through conversations, demonstrations, coaching, joint problem solving, project reviews and the ordinary interactions of working life. It moves when people have the chance to ask questions and to watch how an experienced practitioner reaches a decision, including the reasoning that never makes it into the written procedure.
It does not move simply because the organisation has bought a knowledge management system. A database stores information, a procedure documents a process while a training programme creates an opportunity to develop knowledge and skills. Each of these has value, and none of them is the same as capability. Capability develops when people can use what they have learned and see how it applies to the work in front of them.
This explains why some organisations retain capability after experienced employees leave while others lose it almost overnight. The difference is rarely the volume of documentation. It is whether the knowledge had already become part of how other people work.
People Need Room to Exercise Judgement
Knowledge cannot become capability if people are never allowed to use it. This is one of the less obvious conditions, and one of the most frequently violated.
An employee knows how to solve a problem but escalates it anyway, because every decision of that kind requires approval. A manager has the experience to make a judgement but avoids making it, because a previous mistake was punished rather than examined. A team has been trained on a new process yet continues to wait for instructions, because the surrounding system rewards compliance far more generously than initiative. In each case, the knowledge exists, but the opportunity to apply it does not.
Capability therefore depends in part on decision rights. People need to know not only what they are expected to do but also what they are authorised to decide. This is not an argument for unrestricted freedom. Some decisions belong at senior levels because they carry serious financial, legal, operational or strategic consequences, and pushing them downward would be reckless rather than empowering. The question is a narrower one: are decisions being made at the level where the relevant knowledge actually sits?
When people hold appropriate authority, they get to test their judgement against real situations. They see the consequences. Their confidence grows, and their knowledge becomes more practical because it has been used. When authority is consistently withheld, that development simply stops. People become skilled at asking for permission rather than at making decisions. An organisation run this way may achieve a satisfying degree of control but will, however, not achieve capability.
Practice Has to Be Part of the Work
Training matters, but training is not capability. A person can complete a course, pass the assessment, understand the procedure in detail and still come apart when a real situation arrives with its own complications and its own time pressure.
What closes that gap is practice. Capability develops through repeated application. Someone tries something, receives feedback, adjusts and tries again. The activity becomes more familiar, and more importantly, the judgement underneath it becomes better. This is why learning works best when it sits close to the actual work rather than in a room down the corridor.
An experienced employee does not only explain how something is done; they let another person take part. A manager does not only describe how to handle a difficult conversation; they let the person have the conversation while staying available in case it goes badly. A team does not only read the new procedure; it uses it, finds where it does not fit, and improves its practice accordingly.
Capability is developed through use. When people are trained and then never given the chance to apply what they learned, the organisation may have delivered learning without building organisational capability.
People Need to Be Able to Learn From Mistakes
Practice produces mistakes. That is not a flaw in the method; it is the method working. This raises a condition organisations tend to overlook until it has already done its damage.
If every mistake is treated as proof that the person should never have been trusted with the decision, people draw the obvious conclusion. They escalate more, take fewer risks and stop admitting uncertainty. They become more interested in protecting themselves than in improving the work. Capability is very difficult to build in such an environment, and it tends to erode quietly.
None of this means organisations should wave mistakes through. Some result from negligence, from poor judgement, or from ignoring requirements that existed for good reasons. Accountability remains necessary, but accountability and punishment are not the same thing. Organisations that confuse the two end up paying for the confusion over time.
When a reasonable decision produces an unexpected outcome, the organisation can ask what happened, what was known at the time, what might have been done differently and what should change as a result. That conversation turns experience into learning. The alternative is to close the matter quickly, find someone to blame and move on. It is faster, and more comfortable, and costs the organisation the only useful thing the failure had to offer.
Leadership Has to Resist Taking the Work Back
There is a particular pattern that appears whenever organisations set out to build capability, and it usually comes from good intentions.
A leader gives someone responsibility and then quietly takes it back. An employee is asked to handle a problem. A reasonable decision is made, but the outcome is not quite what the manager had in mind. The manager steps in, takes control and settles the matter personally. Nobody says anything unkind, and nobody needs to. The message has already been delivered: you are responsible when things go well, and I will take over when they become difficult.
People learn that lesson quickly, and they act on it. They escalate. The leader becomes the person everyone depends on, and the organisation acquires the appearance of strong leadership while becoming steadily less able to function without it.
Building capability asks something harder of leaders. They have to let people exercise judgement while giving enough support for that judgement to succeed. In practice, this means asking questions instead of taking over, letting people solve the problems they are capable of solving, and accepting that development sometimes requires someone to sit with the consequences of their own decision. The point is not to remove leadership from the organisation. It is to make leadership unnecessary for the problems that others should eventually be able to handle on their own.
Relationships Matter More Than the Organisational Chart Suggests
Capability is also built through relationships, which is why so many structural remedies disappoint.
Organisations facing coordination problems tend to reach for structure. They redraw reporting lines, create committees, write new procedures or reorganise teams. Sometimes that is exactly the right response. But many coordination problems stem from something else entirely. People do not know one another well enough. They do not understand the pressures the other team is working under, nor do they quite trust information that arrives from elsewhere in the business. They have learned, often for sound historical reasons, to protect their own function rather than to solve problems across the boundary. Redrawing the chart does very little to any of that.
Coordination improves when people build shared understanding through repeated interaction. A procurement team that understands the pressures operations is facing makes different decisions from one that treats operations as just another internal customer. A finance team that understands how a business process actually runs will read a request differently from one that sees only the numbers on the spreadsheet.
Relationships create context, context makes knowledge usable, and repeated interaction allows that understanding to settle into how people work together rather than remaining a matter of individual goodwill.
What Works Has to Become Organisational
The final condition may be the most consequential. Capability becomes durable when effective ways of working stop belonging to particular individuals and become part of the organisation itself.
An experienced engineer finds a better way of handling a recurring fault. A customer service manager works out an effective approach to a difficult category of complaint. A project team develops a better method of moving knowledge between functions. In each case something genuinely valuable has been created. What happens next determines whether it lasts.
If the knowledge stays with the person or the team that produced it, the organisation has gained an improvement and remains one resignation away from losing it. If the learning is shared, tested, adapted and worked into routines, the improvement becomes part of organisational capability and outlives whoever discovered it.
This is where organisational memory earns its importance. Organisations remember through people, but they also remember through routines, relationships, systems, practices and shared expectations. The objective is not to document everything, which is neither possible nor useful. It is to ensure that knowledge the organisation depends on does not walk out of the door with the person who happens to be holding it. That is the difference between an organisation that has been through something and an organisation that has learned from it.
Capability Is Built in Ordinary Moments
None of these conditions requires a large capability programme, and that is perhaps the most useful thing to take from them. Capability is built in ordinary organisational moments.
A manager deciding whether to let an employee handle a difficult customer. An experienced employee taking the time to explain how a decision was reached rather than just announcing it. A team sitting down to work out why a project went wrong. Two departments solving a problem between them without waiting for senior management. A leader allowing someone else to make a decision they could have made themselves in half the time. A new employee being given enough exposure to experienced colleagues to become genuinely effective.
None of these moments will appear on a capability dashboard. They accumulate anyway. Over time they decide whether knowledge stays individual or becomes organisational, learning turns into practice, people develop judgement, and whether the organisation grows less dependent on particular individuals. That is how capability is built. Not through a single intervention, but through repeated organisational choices, most of them small enough to pass unnoticed at the time.
Looking Ahead
Capability does not develop because an organisation announces that it values knowledge, learning, empowerment or collaboration. Those commitments have to become visible in how the work is actually organised.
People need knowledge they can use, and opportunities to practise using it. They need enough authority to exercise judgement, and relationships through which knowledge can travel. They need leaders who support their development without reclaiming every difficult problem. And they need an organisation prepared to learn from experience and turn what it learns into shared practice.
These conditions do not guarantee capability. Without them, however, capability is difficult to build and considerably harder to keep.
This leads to the next question. Once capability has been built, what makes it last? How does it become embedded deeply enough to survive changes in people, leadership, technology, and structure? That question takes us from building capability to the conditions that allow it to endure.