11/1/2026 ☼ uncertainty ☼ organisation design ☼ work

tl;dr: The most important knowledge in any organisation—what makes your work distinctively yours—can’t be written down or taught through training programmes. It’s tacit knowledge that must be learned through direct experience. Most organisations try to solve this by writing better documentation, which fails. Organisations that successfully teach tacit knowledge embed learning into everyday work through three mechanisms: making work public and concrete, focusing feedback on outcomes rather than processes, and using concrete examples as anchors. This approach appears chaotic but produces faster, more reliable learning than conventional training.

You’ve finally poached a designer from another company widely reputed for the excellence of its industrial design. Three months in, she’s producing technically competent work that just doesn’t feel right. She keeps asking: “Can you be more specific?” Your team keeps saying: “It just doesn’t feel like us yet.”

This conversation happens thousands of times daily across organisations everywhere—MNCs, business units, startups, government agencies, nonprofits, military units. It’s clearest where work is obviously “creative,” but happens elsewhere too. The successful operations manager from a competitor whose methods don’t gel. The star law firm partner whose team makes little headway in new business.

These experiences are common, expensive, and demoralising. They reveal how organisations misunderstand how their people learn the things that matter most.

This problem affects any organisation with distinctive ways of working that make it effective. The procurement team that gets better terms than competitors. The sales team whose pitches consistently land. The operations group that takes disruptions in its stride. Each has developed tacit knowledge about how to do things well — and this tacit knowledge is what ends up being extraordinarily difficult to transfer to new members.

What organisations know which they cannot say

The most important knowledge in any organisation cannot be written down because this knowledge is impossible to articulate without destroying it.

Think about wine. Words like “horse blanket,” “mineral,” or “sous-bois” can’t capture the actual experience of drinking a particular wine. Someone who hasn’t tasted it can’t know how it tastes from pages of description. The direct experience is inherently tacit and can’t be fully expressed in words.

The knowledge driving any successful organisation’s distinctive work is inherently tacit—a cluster of hundreds or thousands of interacting characteristics that people know but cannot say. This is tacit knowledge: knowledge that resists articulation because breaking it down into components destroys what makes it work as a whole.

The conventional solution fails

Most organisations respond by trying harder to articulate the inarticulate: style guides, brand books, onboarding programmes, training sessions.

None of this works. New members can recite the style guide but still produce work that feels wrong. They understand values intellectually but can’t embody them practically. Training programmes give them words, not knowledge.

The error is treating tacit knowledge as explicit knowledge that hasn’t been documented yet. It isn’t. It’s fundamentally different. You can’t learn what distinctive wine tastes like by reading tasting notes or what distinctive work looks like by reading descriptions. You must experience it directly, repeatedly, in varied contexts.

What actually works

Some organisations successfully teach tacit knowledge quickly and reliably. They don’t do it through better documentation or more extensive training, but by embedding teaching and learning opportunities into the structure of everyday work itself. I wrote about these organisations and methods in part 5 of my book, the Uncertainty Mindset but I’ll go over the main ideas quickly below.

Organisations that are doing it right make every piece of work do triple duty: the work gets done (outcome 1), serves as a test of the employee’s understanding of some piece of tacit knowledge (outcome 2), and provides learning material and opportunity for others on the same team (outcome 3).

This happens through three mechanisms working together.

Mechanism 1: Design work to become concrete and public as early as possible.

Making team members work by defaulting to creating actual prototypes uncomfortably early in the process, and showing and talking about those prototypes “in public.”

Instead of defaulting to starting with hypothetical descriptions or detailed proposals, set the expectation that people should start with fast, rough, small, partial versions as long as they are real and can be directly experienced by others. A few rough slides to provide an overview of a longer presentation. A paper workflow to simulate part of a digital process. Prototypes should be shown and discussed in internal (or even external) group settings where many colleagues can experience them directly.

This matters because you can’t reliably judge whether work embodies any given piece of tacit knowledge by reading a description of it. Tacit knowledge must be instantiated — used to make an artifact — and then experienced to be evaluated. A mockup must be viewed. A draft of a briefing must be read. A strategy framework must be walked through.

Making work concrete and public allows team members to individually and collectively evaluate whether it feels right, without having to articulate what “right” is. When a team of chefs tastes a prototype dish, they don’t need to break down the hundreds of factors that make the dish work. They taste the dish directly and can say whether it matches their understanding of whether or not it feels “right.”

The public nature of this evaluation is critical. When multiple team members participate in evaluating prototypes, they’re simultaneously teaching each other by revealing their own understanding of what the organisation knows but cannot write down. Each piece of feedback is a data point. Over time, these data points accumulate into a detailed, validated understanding of what that tacit knowledge actually is—an understanding more precise and flexible than any written description of it could be.

Mechanism 2: Focus feedback on outcomes, not processes

Setting and reinforcing strong norms around giving feedback that describes what the outcomes should be like, not how to achieve those outcomes.

Leaders create a culture of being mindful about the type of feedback team members give — specifically, continually reminding team members to give declarative, not procedural feedback. Experienced team members often instinctively give feedback by explaining how they would do something to achieve a desired outcome (process-focused) instead of describing how they would recognise desired outcomes (outcome-focused). The outcome-focused, declarative form of feedback is better at supporting tacit knowledge learning in teams because it creates generative ambiguity about process without sacrificing critical clarity about outcome.

Not:

Outcome-focused, declarative feedback (✅)	Process-focused, procedural feedback (❌)
“Make the dashboard feel straightforward like the one you made for the CFO last quarter.”	“Use the metrics from this spreadsheet to build the dashboard.”
“The flow from business model to investable proposition should feel as inevitable as the investor deck we did for the Series A roadshow.”	“Use this template to structure the slide deck.”
“Make the texture lighter, like the gazpacho you made last week.”	“Reduce the cream in the recipe by 50% and replace with milk.”

With outcome-focused feedback, the recipient knows what outcome to aim for but has freedom to figure out their own path there. This freedom is essential: it motivates exploration and enables the recipient to develop their own understanding of what processes lead to desired outcomes.

When a chef developing a new soup recipe receives declarative feedback that “the texture needs to be lighter, like the gazpacho you made last week,” they’re free to pursue multiple strategies to make the soup lighter. They might change the ratio of ingredients, alter the cooking temperature, separate components that were previously blended together.

The intentional ambiguity about process but clarity about desired outcomes provides space to try different approaches, which accelerates learning about what does and doesn’t work within the framework of organisational tacit knowledge.

Mechanism 3: Using concrete examples as anchors

Setting and reinforcing strong norms around giving feedback anchored in shared and concrete exemplars instead of abstractions.

“Make the soup lighter” is feedback anchored in abstraction (“lightness” of texture), while “make the soup so it has the same texture as last week’s gazpacho” is feedback anchored in a concrete exemplar (the texture of last week’s gazpacho). Both communicate that the soup’s current texture doesn’t work, but they differ fundamentally in precision and usefulness.

Abstract feedback is less helpful for learning tacit knowledge because it contains too broad a range of possible interpretations to be clear without more context. For instance, “lighter” texture could mean dozens of different things—less dense, more aerated, thinner, less creamy, more watery.

Feedback anchored in concrete exemplars circumvents this imprecision problem. The concrete exemplar (last week’s gazpacho) is at the same level of complexity as the prototype being evaluated (this week’s soup). When someone tastes a spoonful of soup, they perceive the texture as texture—not as the hundreds of underlying factors that create it. To understand the right texture for the current soup, the recipient can recall how last week’s gazpacho felt and identifies the specific ways the current prototype diverges from it.

This matters for organisational tacit knowledge because it is inherently complex and inarticulate. Trying to describe desired outcomes using abstract concepts forces an impossible translation: breaking down something complex and holistic (tacit knowledge) into simplified verbal descriptions that inevitably lose critical nuance. Concrete exemplars preserve complexity without requiring articulation.

Concrete examples accumulate across projects. Each completed piece of work becomes a potential reference point. A new team member working on their fifth project can draw on exemplars from the previous four, building an internal database of what organisational tacit knowledge looks like across varied contexts: this texture worked in that dish, this level of formality worked in that presentation, this degree of directness worked in that client negotiation.

This database becomes increasingly reliable as a guide for creating new work. The consultant who has reviewed and discussed dozens of strategy documents develops intuitive understanding of what will and won’t match the firm’s approach. The designer who has critiqued dozens of mockups develops intuitive understanding of what will and won’t embody the organisation’s aesthetic.

In this way, tacit knowledge learning happens obliquely, embedded in routine work. Each prototype tests the creator’s current understanding of organisational tacit knowledge. Each prototype feedback session anchored in concrete exemplars reveals more about what that tacit knowledge actually is — not through abstract description but through direct comparison.

An inherently pragmatic approach

This approach sounds inefficient and ineffective. Managers and employees recoil instinctively from the idea of making every piece of work into a teaching moment, of making everything happen in public, and of encouraging repeated iteration instead of trying to get it right the first time.

Yet organisations that work this way report that the overhead from these approaches is minimal because it blends into everyday work, and new members learn organisational tacit knowledge faster than (and thus become highly productive more quickly than) in organisations with elaborate training programmes based on attempts to explicate tacit knowledge into long and convoluted SOPs.

What looks like inefficiency is in fact elegant economy.

The work would be done anyway. Making it public and using it for teaching costs almost nothing extra. The iterations happen faster because concrete feedback is clearer than abstract feedback. And the 3 mechanisms highlighted above produce team members who have acquired organisational tacit knowledge which they can and have used, instead of acquired the ability to recite incomplete descriptions of such tacit knowledge.

Consider the alternative. A new chef spends weeks learning “philosophy” and studying recipes. When they finally cook, their first dish is evaluated privately by the head chef, who lists specific process changes. They follow instructions. The dish improves but the chef hasn’t learned anything transferable—just how to follow instructions.

The public, iterative approach seems messier but produces faster, deeper learning. After one week of making prototypes and receiving concrete feedback in group tastings, the new chef has accumulated dozens of data points, seen how colleagues evaluate work, heard how prototypes succeed or fail, and begun building the internal database needed to create dishes that feel right.

Four difficult things

Using these mechanisms also seems difficult because it requires organisations to do four difficult things:

1. Be tolerant of messiness. Work is continually shown before it’s “ready.” Team members see each other’s failures. There’s no pretense that work emerges fully formed.
2. Be comfortable with ambiguity. No detailed process instructions. People must figure out their own paths to desired outcomes. This feels uncomfortable, especially for new members accustomed to clear directions.
3. Be willing to iterate publicly. Everyone sees everyone’s failed attempts. This requires psychological safety and a shared understanding that failure is information, not incompetence.
4. Invest upfront in iteration and evaluation. Many iterations on each piece of work. Multiple team members participating in evaluation. This seems expensive compared to just telling someone what to do.

Most organisations find these just too difficult; they never develop work processes that allow employees to learn this valuable strategic knowledge that can’t be written down.

And an organisation that can’t teach its tacit knowledge eventually ends up relying on a few irreplaceable people who figured it out on their own, or being forced to accept increasingly inconsistent and mediocre work. The first option is fragile, and the second is eventually fatal.

What this means for you

If your organisation does work where distinctive approach matters (product design, strategy consulting, content creation, software development) your continued success depends on managing tacit knowledge well whether you acknowledge it or not. The question isn’t whether to teach it. The question is whether you’ll teach it effectively or ineffectively.

The conventional approach (documentation plus training programmes) appears neat and organised but doesn’t actually work. New members learn words but not understanding. They can describe style but can’t embody it. They remain dependent on detailed instructions rather than developing their own judgment.

The alternative approach I’ve described above appears chaotic but produces reliable results. New members accumulate direct experience quickly. They build their own understanding rather than memorizing descriptions. They develop judgment rather than dependence.

The choice is between comfortable failure and uncomfortable success. Most organisations choose comfortable failure without realising it, writing another style guide, creating another training module, wondering why new hires don’t “get it.”

Organisations that successfully teach tacit knowledge have accepted the discomfort of public work, the awkwardness of outcome-focused feedback, the apparent inefficiency of iteration. They’ve recognised that learning what cannot be said requires direct, repeated experience in the context of actual work.

Making the change

Redesigning how your organisation works to make it able to learn vital tacit knowledge is hard but doable.

The three mechanisms—concrete work done in public, outcome-focused feedback, concrete examples—are conceptually simple. The difficulty is fundamentally a cultural one. Most organisations have evolved norms that make these mechanisms feel uncomfortable or impossible: work is shown only when polished, feedback focuses on following established processes, ambiguity about next steps feels irresponsible.

Shifting these norms requires sustained leadership attention to what might seem like inconceivably trivial details. How are prototype reviews structured? Who participates? What kind of feedback do people give? How is iteration framed—as waste or as learning? These myriad decisions accumulate into culture. Changing them changes what becomes possible.

The organisations I’ve studied that successfully teach tacit knowledge didn’t implement these mechanisms all at once through a grand reorganisation. They started small. One team making their prototyping more public. One manager shifting from process-focused to outcome-focused feedback. One project using previous work as concrete reference points. These small changes compound.

What often helps is an outside perspective—someone who can see what insiders take for granted, who can ask the questions that would be impossible for insiders to ask, who can notice where current practices inadvertently prevent the learning that everyone wants to happen. This is what amorphous consulting is ideally suited to do: starting with apparently aimless conversations to understand an organisation’s native language and internal patterns, then revealing otherwise invisible problems and opportunities, then figuring out what actually needs to change.

If you think your organisation struggles to teach what matters most—if new hires take too long to become productive, if quality is inconsistent, if knowledge seems trapped in a few irreplaceable people—the problem might not be inadequate documentation. It might be that you’re trying to teach tacit knowledge using methods designed for explicit knowledge.

I’ve spent the last 15 years investigating how organisations can succeed in uncertain times. The Uncertainty Mindset is my book about how to design organisations that thrive in uncertainty and can clearly distinguish it from risk.. Part 5 of my book contains a more detailed description of pragmatic ways to design organisations to be better at managing strategically valuable tacit knowledge.