Skip to main content

What Git did for code, KnowledgeFund will do for organisations

· One min read

Git changed software by making change manageable.

Teams gained version history, branching, merging, and accountability. Not just storage, but disciplined evolution.

Organisations now face a similar gap with knowledge.

They have documents and tools, but often lack coherent change control for knowledge itself. That produces recurring pain:

  • conflicting truths
  • repeated rediscovery
  • fragile handoffs
  • hidden rationale

In low-velocity settings this is annoying. In AI-accelerated settings this is dangerous.

What organisations may need is Git-like discipline for knowledge change:

  • explicit versioning of key knowledge objects
  • visible history of edits and rationale
  • ownership and review pathways
  • links between knowledge and execution
  • structured reuse

This is not about copying Git literally. It is about adopting equivalent operational rigor for knowledge.

If done well, benefits compound:

  • faster onboarding
  • cleaner cross-team alignment
  • better AI context quality
  • less stale-knowledge rework

That is likely to become a structural differentiator.

From knowledge management to KnowledgeFund

· 2 min read

Classic knowledge management solved an important problem: capture.

It gave organisations repositories and control. But in fast AI-era operations, capture alone is not enough.

The harder problem is conversion. How does scattered information become usable, connected, and reusable organisational intelligence?

That transition is from knowledge management to KnowledgeFund.

KnowledgeFund is not just another storage layer. It is an operating model:

  • from static documents to living knowledge objects
  • from isolated records to connected context
  • from periodic updates to continuous refinement
  • from person-bound memory to system memory

This shifts governance too. The question is no longer only, "is it documented?" It is, "is it legible, current, and reusable under change?"

AI raises the stakes. Without coherent knowledge structure, AI scales ambiguity. With coherent structure, AI scales capability.

The transition starts practically. Pick high-friction knowledge zones, connect them to work and decisions, and build reuse pathways. Then expand.

That is how knowledge becomes compounding capital.

Why coherence is an organisational capability, not a communications side effect

· 5 min read

A lot of organisations talk about coherence as if it were something that should arise naturally if people just communicate a bit more.

Share more updates. Run more meetings. Improve collaboration. Publish clearer messages. Make leadership communication more regular.

Some of that helps. But it does not get to the root of the problem.

Coherence is not a side effect of communication. It is an organisational capability.

Communication can move signal without creating shared meaning

An organisation can be highly communicative and still remain confused.

Messages can move quickly. Updates can be frequent. Channels can be active. People can be responsive.

And yet the organisation can still suffer from:

  • inconsistent interpretation
  • fragmented local language
  • unclear ownership
  • duplicated effort
  • weak traceability
  • hidden dependency risk
  • repeated context reconstruction

That is because communication moves signal. Coherence depends on shared meaning.

Those are related, but they are not the same thing.

Coherence depends on structure underneath the conversations

For people to coordinate well, they need more than the ability to talk. They need some stable basis for understanding what they are talking about.

That usually means shared:

  • concepts
  • relationships
  • context
  • ownership boundaries
  • decision pathways
  • knowledge history
  • signals about what is current and what is not

Without those things, communication becomes expensive interpretation work. People keep translating, inferring, correcting, and privately filling gaps.

That may keep the organisation moving. It does not make it coherent.

This is why some organisations stay noisy and unclear at the same time

From the outside, it can look strange. There are constant meetings, documents, chats, escalations, and updates. Everyone is busy communicating.

But inside that noise, the same questions keep returning:

  • who owns this really
  • what does this term mean here
  • which process is current
  • why are these teams reporting different realities
  • where did this decision come from
  • what changed since last time

That is not mainly a communication-volume problem. It is a coherence-capability problem.

The organisation has not built enough shared structure for communication to land consistently.

Coherence is built through maintained shared reality

This is the heart of it.

A coherent organisation is not one where everybody says the same words. It is one where enough of the underlying reality is shared and maintainable.

People can still disagree. Teams can still have different perspectives. Roles can still need different experiences.

But those differences sit on top of enough common structure that the organisation does not dissolve into parallel private worlds.

That takes work. It has to be built and maintained.

A coherence capability needs more than messaging discipline

If coherence is a capability, then the organisation should expect to invest in it explicitly.

That means building things like:

  • better shared knowledge structures
  • clearer pathways from local work into common meaning
  • stronger traceability between work, decisions, and context
  • more usable role and dependency clarity
  • better ways to absorb learning back into the shared system
  • stronger signals for drift, contradiction, and staleness

These are not just communication improvements. They are part of the organisation's operating infrastructure.

This matters because incoherence has a compounding cost

Incoherence is rarely catastrophic in one moment. It leaks cost continuously.

It shows up as:

  • avoidable meetings
  • duplicated thinking
  • brittle handoffs
  • repeated explanation
  • unnecessary translator roles
  • slow change absorption
  • rising reliance on a few people who "know how it really works"

Those costs often become normal. But they are one reason organisations feel heavier and less adaptive than they should.

A stronger coherence capability reduces that tax.

Coherence also improves local autonomy

This is important.

Treating coherence as a real capability does not mean forcing uniformity. Often it enables better local autonomy.

When teams are working on top of stronger shared structure, they can adapt locally without creating as much hidden divergence. They can move faster without making themselves illegible to the rest of the organisation.

That is a much healthier form of autonomy than simple fragmentation.

This becomes even more important as machine-supported work grows

As organisations rely more on automation and AI-assisted work, coherence matters even more.

Machines can help process, route, summarise, and generate. But if the organisation's underlying reality is poorly connected, those systems will operate on unstable context.

That means the organisation can become faster without becoming clearer. And that is a dangerous combination.

A stronger coherence capability gives both people and machines a better basis for action.

The point

Communication matters. But organisations should stop expecting coherence to emerge from communication alone.

Coherence is something the organisation has to build. Maintain. Strengthen. Use.

That makes it a capability. Not a side effect.

Knowledge as a living network, not a document set

· 5 min read

A lot of organisations still treat knowledge as if it were mainly a filing problem.

Put the material somewhere sensible. Name it reasonably well. Add a taxonomy. Maybe improve search. Maybe improve templates. Maybe enforce publication and review.

All of that can help. But it still assumes the main unit of knowledge is the document.

That is the mistake.

Documents matter. Knowledge does not live as documents alone. It lives as a network.

A document is only one node in the knowledge reality

A useful document may contain policy, explanation, process, architecture, evidence, or instruction. That is valuable.

But what gives that document real meaning is not only its internal content. It is the surrounding network:

  • what problem it relates to
  • what decision led to it
  • what work depends on it
  • what evidence supports it
  • what systems it affects
  • what exceptions sit around it
  • what other documents or people interpret it
  • what changed before and after it

Without those surrounding connections, a document may still exist, but its knowledge value is thinner than organisations often assume.

Most document estates are structurally lonely

This is why so many knowledge bases feel disappointing.

The documents are there. The folders exist. The pages exist. The tags exist.

But the material still feels disconnected. People still have to reconstruct the story for themselves. They still need to ask:

  • is this current
  • what does this relate to
  • what else should I read with it
  • who actually uses this
  • does this reflect reality or just approval history
  • what happened that made this document necessary

That is what a lonely document estate feels like. It contains records without enough relationship structure to become a living knowledge system.

Knowledge becomes stronger when the connections matter as much as the pages

A network view changes the goal.

Instead of asking only whether a document exists, the organisation starts asking:

  • what is this connected to
  • where did this knowledge come from
  • what reuses it
  • what contradicts it
  • what depends on it
  • what work should update it
  • what signal should cause it to change

Those are much stronger questions. Because they treat knowledge as part of an active system rather than a passive library.

Real organisational knowledge is spread across different forms

Another reason the network idea matters is that useful knowledge does not arrive in one uniform shape.

Some of it lives in:

  • formal documents
  • issue histories
  • process steps
  • architecture models
  • work records
  • decisions
  • exceptions
  • metrics
  • warnings
  • human commentary
  • repeated patterns of use

If the organisation only honours one form, it usually loses too much context.

A network view allows these different forms to stay distinct while still being connected. That is often more realistic than trying to flatten everything into a single type of page.

This is how knowledge becomes easier to reuse

Reuse depends on more than search.

People do not reuse something just because they can find a file. They reuse it when they can understand whether it applies, what it means, what its quality is, and how it connects to their situation.

That becomes much easier when knowledge is embedded in a network of relationships.

Then the organisation can see:

  • where a pattern has already been used
  • what contexts it fits
  • what changed when it was applied
  • what other assets support it
  • who contributed to it
  • whether it remains healthy or stale

That is how knowledge starts compounding instead of being repeatedly rediscovered.

A network view also exposes gaps more honestly

A document set can create the illusion of completeness. If enough pages exist, the organisation can feel like the knowledge problem is mostly handled.

A network view is harsher, but more useful.

It shows broken links. Missing relationships. Isolated pages. Unowned concepts. Repeated contradictions. Knowledge that has no current path back into work.

That is uncomfortable. It is also much closer to the truth.

This matters for governance too

Governance gets better when knowledge is connected.

A governance decision should not sit as an isolated statement. It should connect to:

  • the structures it governs
  • the work it affects
  • the rationale behind it
  • the evidence around it
  • the risks or constraints it responds to
  • the places where exceptions are appearing

That is much easier to do when the organisation treats knowledge as a network instead of a set of detached files.

Why this matters even more with AI

AI makes the weakness of document-only thinking more obvious.

A model can summarise documents quickly. But if the surrounding knowledge network is weak, it will still operate on incomplete or contradictory context. It may produce fluent answers from badly connected material.

If the knowledge body is more networked, AI has a much better basis for interpretation. It can work with relationship structure, not just text fragments.

That does not solve everything. But it moves the organisation much closer to useful machine-supported reasoning.

The point

The organisation does not need fewer documents. It needs to stop imagining that documents are the whole knowledge system.

Knowledge becomes stronger when it is treated as a living network of connected meaning, evidence, work, decisions, and use.

That is what makes it easier to trust, easier to reuse, easier to evolve, and harder to lose.

Knowledge Management 4.0

· 6 min read

Knowledge management has been trying to solve a real problem for a long time.

Organisations forget. They repeat themselves. They lose context. They trap critical knowledge in roles, teams, documents, and people. They create records without creating understanding.

So the instinct behind knowledge management was never wrong.

The problem is that most knowledge management approaches captured only a thin and fragile version of what organisations actually know.

Traditional knowledge management was mostly about capture

In practice, knowledge management usually became a mix of:

  • document repositories
  • intranets and wikis
  • taxonomies and metadata
  • lessons learned registers
  • formal knowledge-owner roles
  • translation work between teams and functions

That helped to a point.

But most of it was still built on the same assumption:

if the organisation writes enough down, it will become knowable.

That is only partly true.

Writing things down matters. But capture is not the same as coherence. Storage is not the same as shared understanding. And documentation is not the same as living organisational knowledge.

The real problem was always fragmentation

Most organisations do not lack information. They lack connectedness.

Knowledge gets spread across:

  • policies
  • procedures
  • architecture diagrams
  • ticket systems
  • chats and emails
  • spreadsheets and slide decks
  • local workarounds
  • habits and unwritten rules
  • individual memory

That means the organisation often has the pieces, but not the whole.

One team knows why something exists. Another knows how to operate it. A third knows why it keeps failing. A fourth has already built a workaround. And none of that is held together cleanly.

This is why so many organisations end up document-rich but knowledge-poor.

Translation-heavy systems do not scale well

A lot of classic knowledge management depended on translation.

Someone had to gather context from one place, interpret it, reshape it, and publish it in a form someone else could use. That might be an architect, analyst, manager, process owner, or subject matter expert.

Sometimes that works. But it creates a bottleneck.

The organisation becomes dependent on a relatively small number of people to:

  • interpret what matters
  • clean up contradictions
  • fill in missing context
  • explain how pieces connect
  • keep knowledge current

That creates at least three problems.

First, it does not scale. As complexity rises, the translation load rises faster.

Second, it goes stale. By the time knowledge is translated, approved, and published, reality has often moved on.

Third, it becomes political. When too much knowledge depends on a few intermediaries, those intermediaries become bottlenecks, filters, and points of control.

A lot of the important knowledge never gets captured properly

Traditional knowledge systems also tend to favour the formal and visible layer.

They capture things like:

  • official process
  • approved policy
  • designed architecture
  • final decisions
  • published standards

What they often miss is the working layer:

  • why a decision was really made
  • what was tried and failed
  • which exceptions matter in practice
  • where the hidden dependencies sit
  • what local heuristics people rely on
  • which warnings experienced people carry around implicitly

That is often the knowledge that makes the difference between smooth execution and expensive confusion.

When it is not captured, the organisation keeps relying on human memory to bridge the gap. That makes continuity fragile and makes people harder to replace in knowledge terms.

Why this matters more now

These weaknesses were already expensive before AI.

AI just makes them harder to ignore.

If organisational knowledge is fragmented, stale, contradictory, or trapped in people’s heads, AI will not magically fix it. It will operate on the fragments it can see. It may summarise the wrong thing beautifully. It may scale ambiguity faster. It may make incoherence more productive.

That means the question is no longer just whether an organisation has knowledge assets.

The question is whether the organisation has a knowledge system that is legible enough for both people and AI to work with.

Knowledge Management 4.0 should be about formation, not just storage

The next stage of knowledge management should not just be a better library.

It should be a better organisational memory system.

That means shifting the goal from storing content to forming shared knowledge.

A stronger model should help the organisation:

  • capture knowledge closer to where it is created
  • preserve reasoning, not just outputs
  • connect documents, decisions, work, and evidence
  • expose contradictions and stale areas
  • reduce dependence on isolated human memory
  • make knowledge more reusable across teams
  • keep context alive as work changes

In other words, the aim is not just accumulation. It is intelligibility.

This is where AI changes the economics

Older knowledge management approaches struggled partly because the interpretation work was expensive.

Humans had to do most of the sorting, summarising, connecting, classifying, and cross-referencing by hand. So organisations cut corners. They documented the minimum. They centralised the burden. They tolerated drift.

AI changes that.

Not by removing the need for structure, but by making knowledge formation cheaper.

AI can help:

  • interpret raw material
  • suggest where knowledge belongs
  • connect related fragments
  • surface conflicting versions of reality
  • preserve rationale while context is still fresh
  • turn scattered evidence into more usable knowledge objects
  • keep the knowledge body more current over time

That does not remove the need for human judgment. But it does remove some of the old excuses.

From knowledge management to KnowledgeFund

This is why I think the next step has to move beyond classic knowledge management.

Knowledge management mostly treated knowledge as something to capture and administer.

KnowledgeFund should treat organisational knowledge as something to actively structure, connect, trace, and grow.

That means moving toward a system where knowledge is:

  • connected to purpose
  • connected to work
  • connected to decisions
  • connected to evidence
  • connected to gaps and risks
  • connected to contribution and reuse

That is a different ambition.

It is closer to building an organisational knowledge system than maintaining a document estate. It is closer to organisational memory than document management. It is closer to a living knowledge economy than a static archive.

The point is not more content

A mature knowledge approach is not about producing more pages.

It is about making the organisation more able to know what it knows, learn what it does not, and act with clearer shared context.

That is the real promise behind a better knowledge model.

Not just better storage. Better coherence. Better continuity. Better organisational learning.

That is the direction Knowledge Management 4.0 should point toward.

Why digital transformation keeps disappointing

· 5 min read

Digital transformation is one of those phrases that sounds ambitious and inevitable at the same time.

Organisations announce it with confidence. Programs are launched. Platforms are bought. Roadmaps are built. Teams are restructured. Dashboards are created. New delivery language arrives.

And yet the outcome is often underwhelming.

Not always a total failure.

Often something more frustrating than that.

A partial improvement. A nicer surface. A collection of expensive new systems. More reporting. More implementation activity. More architecture diagrams.

But not the kind of deep organisational shift that the original rhetoric implied.

So why does this keep happening?

Because technology is usually treated as the transformation

One of the most common mistakes is to confuse digital transformation with technology rollout.

A new platform is introduced and called transformation. A new process is automated and called transformation. A customer journey is digitised and called transformation. A reporting layer is modernised and called transformation.

Those changes may be useful, but they do not automatically transform the organisation.

They only transform the organisation if they change the way the organisation actually coordinates work, shares knowledge, makes decisions, and adapts.

If those deeper structures remain the same, then the organisation has often just added a new layer on top of old habits.

Because organisations keep trying to modernise the surface while preserving the old operating logic

Many digital programs are designed with an implicit contradiction.

They want new speed, new visibility, new flexibility, and new customer outcomes.

But they also want to preserve the existing incentives, the existing silos, the existing approval patterns, the existing knowledge bottlenecks, and the existing comfort zones of power.

That is not transformation.

That is modernisation without reorganisation.

And it tends to produce the same pattern repeatedly:

  • better tools
  • better interfaces
  • more integration work
  • more complexity underneath
  • very limited change in actual organisational behaviour

Because the hard problem is not delivery, it is coherence

Organisations are usually better at launching initiatives than integrating them.

They can fund projects. They can appoint owners. They can hire specialists. They can run transformation offices.

What they struggle with is coherence.

Coherence means the organisation can make parts move in a way that supports the whole.

That depends on things like:

  • shared context
  • aligned incentives
  • visible dependencies
  • usable organisational memory
  • real decision clarity
  • feedback that arrives early enough to matter

If those things are weak, digital transformation becomes a sequence of local improvements that do not add up.

Because knowledge stays fragmented

A lot of transformation effort is lost because organisations do not actually know themselves well enough.

Knowledge is spread across documents, systems, teams, habits, and individual people. Important context is often trapped in local workarounds, historical assumptions, or the heads of a few trusted operators.

That means every major change has to fight through ambiguity.

The organisation cannot clearly see:

  • what it already knows
  • what is duplicated
  • where work really happens
  • where decisions are actually made
  • where the bottlenecks are
  • what assumptions the current structure depends on

Without that visibility, transformation tends to become optimistic program management layered over fragmented organisational reality.

Because governance is often brought in too late or too narrowly

Governance is often treated as something that arrives after the real design decisions have already been made.

It becomes a control layer. A review layer. A sign-off layer. A reporting layer.

But if governance only appears at the end, then it is mostly supervising the consequences of earlier structural choices.

Used properly, governance should help shape:

  • how the organisation frames the change
  • how responsibility is distributed
  • how trade-offs are made
  • how adaptation is allowed
  • how knowledge is surfaced and maintained
  • how coordination happens across functions and time

That is a much deeper role than compliance theatre.

Because transformation is social before it is technical

Even highly technical transformations are still social transformations.

People need to interpret new systems. Teams need to change how they relate. Authority patterns get challenged. Local autonomy and central coherence come into tension. Legacy expertise can become either a bridge or a source of resistance.

When organisations ignore that, they often produce a strange outcome:

The new tools are live, but the old organisation is still in charge.

What would a better approach look like?

A better approach would start by treating transformation as structural work.

Not just software delivery. Not just architecture uplift. Not just process digitisation.

It would ask:

  • What kind of organisation are we trying to become?
  • What behaviours need to change, not just what systems?
  • Where is knowledge currently trapped?
  • What coordination patterns are preventing improvement?
  • What needs to become visible that currently is not?
  • What should governance do during change, not just after it?

That does not make transformation easier.

But it makes it more honest.

And honesty matters here, because the biggest cost in digital transformation is often not the technology itself. It is the repeated illusion that the next platform, the next delivery model, or the next operating rhythm will succeed without deeper organisational change.

The disappointment is a clue

If digital transformation keeps disappointing, that should not just be filed away as execution noise.

It is a signal.

It suggests that the real challenge is not simply digital capability. It is organisational coherence.

Until that becomes central, transformation programs will keep producing more movement than change.

The hidden cost of local optimisation between teams

· 5 min read

Most local optimisation does not begin as sabotage.

It begins as competence.

A team sees pressure, constraints, deadlines, dependencies, and performance expectations. It adapts its own work to survive. It creates local rules. It simplifies handoffs. It protects itself from uncertainty. It builds workflows that make sense from where it sits.

That is normal. Often it is necessary.

But when too many teams optimise locally without enough shared structure, the organisation starts paying hidden costs.

Local optimisation is rational from the inside

From inside a team, local optimisation often looks like good management.

The team is trying to:

  • reduce delay
  • remove friction
  • protect quality
  • manage risk
  • keep delivery moving
  • avoid unnecessary dependence on other groups

None of that is irrational.

The problem is that every team is solving from a partial view.

What makes one team's work easier may:

  • increase complexity downstream
  • create translation burden for another team
  • duplicate effort elsewhere
  • hide knowledge in local conventions
  • make system-wide traceability worse
  • shift risk into a place that is less visible

That is how rational local optimisation can still produce organisational incoherence.

Teams do not feel the whole-system cost equally

One reason this problem persists is that the costs are unevenly distributed.

The benefits of local optimisation are usually immediate and visible to the team doing it. The wider costs are often delayed, dispersed, or absorbed by someone else.

That means the organisation can end up with:

  • one team that feels efficient
  • another that becomes a translation buffer
  • another that keeps resolving recurring exceptions
  • another that loses visibility into why things are happening

From the inside, nobody feels entirely irrational. From the whole-system view, the organisation becomes harder to coordinate.

This is how silos become operational logic

A silo is not only a social problem. It is often the accumulated result of repeated local optimisation.

Each team builds the shortcuts, classifications, workarounds, and control habits that best fit its own world. Over time those local choices harden into different operational realities.

Now the organisation does not just have multiple teams. It has multiple overlapping systems of meaning.

The same term means different things in different places. The same status carries different implications. The same process step gets interpreted differently depending on who is involved.

That is when cross-team work starts becoming expensive. Not because people refuse to collaborate, but because they are no longer working from the same structure.

Hidden costs show up as friction, rework, and memory loss

The cost of local optimisation often does not appear as one obvious failure.

It appears as:

  • repeated clarification
  • duplicated analysis
  • inconsistent reporting
  • exceptions that keep resurfacing
  • extra coordination overhead
  • brittle handoffs
  • knowledge trapped in specific teams
  • slower adaptation when change crosses boundaries

These are easy costs to normalise. They become "just how things are".

But over time they add up to a serious drag on organisational performance.

Why local optimisation gets worse under pressure

Pressure usually makes this pattern stronger.

When deadlines tighten or change accelerates, teams become even more likely to protect local throughput first. They standardise locally. They minimise external dependencies. They keep more context inside the team. They narrow what they are willing to interpret from outside.

That can help in the short term.

But it often makes the whole organisation less adaptable in the medium term, because it reduces the amount of shared structure available across the system.

The issue is not local autonomy itself

This is important.

The answer is not to eliminate local judgment or force every team into one generic way of working.

Local context matters. Teams do need room to adapt.

The real issue is whether local optimisation happens on top of enough shared coherence.

That means enough shared:

  • language
  • traceability
  • knowledge structure
  • governance patterns
  • visibility into dependencies
  • mechanisms for resolving cross-boundary tension

Without those things, local autonomy becomes local divergence. With them, local adaptation can remain useful without dissolving the whole.

Strong organisations make cross-team cost visible

If an organisation wants to reduce the hidden cost of local optimisation, it has to get better at seeing the cross-boundary effects of local decisions.

That means being able to notice things like:

  • where one team's efficiency creates another team's recurring friction
  • where shared concepts have drifted apart
  • where translation roles are absorbing too much hidden complexity
  • where local workarounds have become shadow process
  • where important knowledge is no longer portable across teams

Those are governance and knowledge problems as much as they are delivery problems.

The goal is coordinated local intelligence

The best outcome is not central control or unbounded local freedom.

It is coordinated local intelligence.

Teams should be able to optimise locally while remaining legible to the rest of the organisation. They should be able to adapt without creating invisible system debt. They should be able to move fast without making cross-team coordination harder every month.

That requires stronger foundations underneath the teams.

The hidden cost becomes obvious later

Local optimisation often feels cheap at first.

The real bill arrives later, when the organisation tries to:

  • change direction quickly
  • scale a capability across teams
  • integrate a new technology
  • transfer work between groups
  • replace key people
  • understand where risk is really sitting

That is when the hidden cost becomes visible.

By then, what looked like healthy pragmatism can turn out to be accumulated incoherence.

That is why the issue matters.

The organisation does not just need productive teams. It needs teams whose local intelligence can still live inside a coherent whole.

Why most collaboration tools improve surfaces, not coherence

· 5 min read

Most collaboration tools arrive with a familiar promise.

They will make teams faster. They will improve visibility. They will reduce friction. They will connect people better.

And to be fair, many of them do improve something.

Messages move faster. Work becomes easier to track. Files become easier to share. Meetings become easier to schedule. Notifications become more immediate.

But organisations often mistake these surface gains for deeper coherence.

That is the mistake.

Better interaction is not the same as better alignment

A collaboration tool can make it easier for people to talk. That does not mean they share the same context.

It can make work more visible. That does not mean the work is better connected to purpose.

It can make discussion more fluid. That does not mean the organisation is learning more effectively.

Interaction quality and organisational coherence are related, but they are not the same thing.

Coherence depends on things like:

  • shared concepts
  • clear ownership
  • stable context
  • legible decision pathways
  • usable organisational memory
  • aligned incentives across teams

Most collaboration tools do not create those conditions. They operate on top of them.

A better surface can hide a weak structure

One reason collaboration tooling can be misleading is that it improves the visible layer.

People see:

  • cleaner interfaces
  • faster conversation
  • richer notifications
  • easier handoff mechanics
  • better search
  • nicer shared workspaces

Those improvements feel like modernisation. And sometimes they are.

But a better surface can make a weak structure feel temporarily healthier than it really is.

The organisation may still have:

  • fragmented knowledge
  • unclear decision rights
  • duplicated work across teams
  • local optimisation conflicts
  • stale operational memory
  • heavy dependence on informal human translators

If those conditions remain, the tool may help people move around the mess faster without resolving the mess itself.

Most collaboration tools optimise communication, not meaning

This is the deeper limitation.

Most collaboration tools are built to optimise communication events:

  • sending
  • receiving
  • tagging
  • sharing
  • responding
  • tracking

Those things matter.

But coherence is not just a communication problem. It is also a meaning problem.

Do people understand the same thing by the same term? Do they see how their work relates to adjacent work? Do they know which version of reality is current? Do they understand why a decision was made and what it changed? Do they share enough structure to interpret signals the same way?

A chat stream, work board, wiki, or meeting platform does not answer those questions by default.

Tool sprawl often makes the problem worse

There is another issue.

As organisations adopt more collaboration tools, they often create a new kind of fragmentation.

One conversation happens in chat. Another in email. Another in tickets. Another in docs. Another in meeting notes. Another in slide decks. Another in an unofficial team channel.

Now the organisation is not just dealing with missing coherence. It is dealing with distributed fragments of partial coherence.

People start spending more energy locating context than using it.

That is not a collaboration victory. It is an organisational tax.

Collaboration without shared memory becomes repetitive

When organisations lack strong shared memory, collaboration starts repeating itself.

The same questions get re-answered. The same context gets re-explained. The same decision history gets reconstructed. The same dependencies get rediscovered.

This is one reason teams can feel busy, responsive, and highly collaborative while still failing to build compounding organisational intelligence.

They are collaborating around gaps. Not resolving them structurally.

The real issue is underneath the tools

If an organisation wants stronger coherence, it has to work below the collaboration-tool layer.

It has to improve things like:

  • organisational memory
  • shared ontology and language
  • traceability of decisions and work
  • clearer ownership and role boundaries
  • cross-team visibility into dependencies
  • better pathways for updating shared knowledge

Collaboration tools may help express those structures. But they do not create them automatically.

A collaboration layer still matters

This is not an argument against collaboration tools.

They matter a lot. Poor tooling absolutely creates unnecessary friction. Bad search, bad handoff mechanics, bad notification design, and bad workspace design can make organisations slower and more painful than they need to be.

But the right way to think about collaboration tools is as an enabling layer, not a substitute for coherence.

They can make a coherent organisation work better. They can make an incoherent organisation move faster without understanding itself.

Those are very different outcomes.

The real goal is not more collaboration events

An organisation does not win by creating more messages, more meetings, more visibility, or more shared spaces.

It wins when people can coordinate with less guesswork. When context compounds instead of evaporating. When learning becomes reusable. When work stays connected to shared meaning.

That is coherence.

Most collaboration tools improve surfaces. If organisations want coherence, they have to build the structures underneath.

What a shared organisational model is actually for

· 6 min read

A lot of organisational models fail before they are even used properly.

Not because the diagrams are bad. Not because the concepts are useless. But because the organisation is not clear about what the model is actually for.

So the model becomes a vague asset. Part documentation, part architecture, part governance reference, part communication tool. Useful in theory. Underused in practice.

That is a waste.

A shared organisational model can do much more than describe structure. But only if its purpose is understood.

A shared model is not just a picture of the organisation

The most obvious use of a model is representational. It shows what exists and how things relate.

That matters. A model can make the organisation easier to discuss. It can provide common language. It can reduce some ambiguity. It can help people see dependencies that were previously hidden.

But if that is all the model does, it will often remain secondary to daily work. The organisation will admire it occasionally and bypass it continually.

A stronger model should not only picture the organisation. It should help the organisation function more coherently.

The model should reduce guesswork

One of the biggest hidden costs inside organisations is interpretation effort.

People keep having to work out:

  • what something really means here
  • who owns what
  • how one thing connects to another
  • which version of a concept is current
  • where a dependency actually sits
  • what has changed and why

That is expensive. Not always visibly expensive, but expensive all the same.

A shared organisational model should reduce that guesswork. It should help people find stable meaning faster and connect local work to wider structure with less private reconstruction.

It should support coordination across boundaries

A good model is especially useful at the boundaries of teams, roles, and systems.

Inside a single team, people can often compensate for weak structure through habit and familiarity. Across boundaries, that becomes much harder.

That is where confusion multiplies. The same term carries different assumptions. The same workflow status means different things. The same dependency is understood differently depending on who is speaking.

A shared model helps create enough common structure that cross-boundary work becomes less fragile.

It should help people answer questions like:

  • how does this team relate to that service
  • what capability does this work actually support
  • what other groups depend on this decision
  • where does this piece of information belong
  • what objects are we really talking about here

In that sense, the model is a coordination aid, not just a reference artefact.

It should help local experience stay connected to the whole

This is one of the most important jobs.

An organisation is always tempted to split into local realities. Each team develops its own shortcuts, language, heuristics, and internal map of the world. Some of that is necessary. Too much of it becomes fragmentation.

A shared model helps prevent local relevance from drifting into local truth. It creates a common structural core that local work can keep referring back to.

That does not mean every team must use the model in the same way. It means their local experience should still remain connected to the same underlying organisational meaning.

It should improve learning, not just description

Another weak pattern is treating the model as if it captures settled truth once and for all.

In reality, the organisation learns through use. It discovers ambiguity. It discovers unstable terms. It discovers missing relationships. It discovers that official categories do not always survive contact with real work.

A strong shared model should make that learning visible. It should help the organisation notice:

  • where concepts are overloaded
  • where structure is missing
  • where the same gap keeps reappearing
  • where local work is revealing something the wider model does not yet express

That makes the model part of organisational learning. Not just organisational description.

It should support governance without becoming governance theatre

A model can help governance in a useful way. It can make responsibilities clearer. It can expose dependencies. It can make decision pathways more legible. It can connect work, structure, risk, and ownership.

But if governance becomes the only or primary framing, the model can become remote and ceremonial. People start seeing it as something for reviewers, architects, or control functions rather than something that improves real work.

The better path is for the model to support governance by making the organisation more intelligible. When shared meaning improves, governance has something stronger to work with.

It should make change easier to absorb

Change becomes much harder when the organisation cannot see how its parts relate.

A new system arrives. A process changes. A capability moves. A team is restructured. A dependency shifts.

Without a shared model, each change creates more local interpretation burden. People have to reconstruct the implications manually. That slows adaptation and increases the risk of divergent understanding.

A better model gives the organisation a stronger basis for understanding what a change touches and how its meaning travels. That makes change easier to absorb without losing coherence.

It should be used through experience, not only inspection

A model becomes powerful when it is not only something people inspect occasionally, but something that quietly shapes how they encounter the organisation.

It should influence:

  • the way knowledge is navigated
  • the way work is classified
  • the way dependencies are surfaced
  • the way context is presented
  • the way signals connect back into shared structure

That is when the model stops being an abstract representation and starts becoming part of the organisational operating environment.

The real point

A shared organisational model is not just for architecture. And it is not just for documentation.

It is for helping the organisation become more legible to itself.

That means making shared meaning easier to find, coordination easier to sustain, learning easier to accumulate, and change easier to absorb.

If the model does not contribute to those outcomes, it may still be interesting. But it is not yet doing its most important work.

Documentation is not knowledge

· 6 min read

Documentation matters.

But organisations keep making a costly mistake.

They confuse documentation with knowledge.

That sounds harmless at first. After all, documentation is one of the main ways organisations try to capture what they know.

But the difference matters more than it appears.

When documentation is treated as if it is knowledge, organisations start believing that writing something down is the same as making it usable, meaningful, connected, and alive.

It is not.

Documentation is a record, not the whole reality

Documentation is usually a record of something.

A policy. A procedure. A decision. A requirement. A design. A lesson. A meeting outcome. A system configuration. A model.

That can be useful.

But the existence of a record does not mean the organisation actually possesses the knowledge in a usable form.

For knowledge to be real in practice, it has to be:

  • understood
  • interpreted in context
  • connected to other things
  • reachable when needed
  • maintained over time
  • usable by people other than the original author
  • capable of informing real decisions and action

A document on its own does none of that automatically.

Why organisations keep confusing the two

There are a few reasons this confusion is so persistent.

First, documentation is visible.

It creates the feeling that something has been captured. A file exists. A page exists. A repository exists. A knowledge base entry exists. Progress can be pointed at.

Second, documentation is easier to govern than knowledge.

You can require templates. You can require sign-off. You can require naming conventions, review cycles, and publishing rules.

All of that can improve discipline, but it can also create a dangerous illusion:

that structured documents equal organisational understanding.

Third, documentation lets organisations push interpretation work onto the reader.

Instead of maintaining living coherence, the organisation stores fragments and assumes the next person will know how to assemble them into meaning.

That is often where the real failure begins.

The real problem is fragmentation

Most organisations do not suffer from a total absence of documentation.

They suffer from fragmented, uneven, disconnected, poorly maintained documentation that has to stand in for a much richer body of knowledge.

That fragmentation shows up everywhere:

  • the same idea described differently across teams
  • old policies left beside newer practices
  • process documents that no longer match reality
  • architecture diagrams that explain structure but not behaviour
  • project documents that explain intent but not outcome
  • tribal knowledge that never made it into shared form
  • "final" documents that nobody trusts

Traditional documentation usually captures only a small formal subset of what people actually know. It records the visible surface: setup, usage, procedures, interfaces, policies. But much of the real working knowledge sits outside those documents:

  • why a decision was made
  • what was tried and failed
  • hidden constraints and edge cases
  • heuristics, warnings, and shortcuts
  • the informal connections between systems and people

That is why a knowledge page is not the same thing as documentation. Documentation explains how something works. A knowledge page should also preserve what has been learned, what matters, and what future contributors would otherwise have to rediscover.

When that does not happen, critical knowledge stays person-bound instead of system-bound. And when the people carrying that knowledge are overloaded, interrupted, or working with fragmented attention, even more of it stays trapped in their heads instead of becoming durable organisational memory.

When that happens, the organisation may be document-rich but knowledge-poor.

A document cannot carry all the context by itself

Knowledge is relational.

A person understands a concept not just because they read a sentence, but because they can place it within a wider network of meaning.

They know:

  • why it exists
  • what it depends on
  • what changed before it
  • what it affects after it
  • where it conflicts with something else
  • who uses it
  • what exceptions matter
  • where the real ambiguities are

Most documentation strips away much of that surrounding structure.

That is why two people can read the same document and come away with two different interpretations, while both feel they are following the documentation correctly.

Documentation often decays faster than organisations admit

Another reason the confusion is dangerous is that documentation ages badly.

It does not usually fail dramatically. It drifts.

A little outdated language here. A missing edge case there. An undocumented workaround. A renamed system. A changed approval path. A new dependency. A new exception. A silent role change.

Over time, the document remains while the organisational reality moves on.

If the organisation still treats the document as the knowledge, then drift becomes invisible.

People start operating inside a split reality:

  • official knowledge in the documents
  • practical knowledge in lived work

That split is one of the most expensive forms of organisational incoherence.

What real knowledge work requires

If documentation is not knowledge, then what should organisations do differently?

They should treat documentation as one layer in a broader knowledge system.

That means caring not only about whether something was documented, but whether the organisation can:

  • find the right material quickly
  • understand how pieces connect
  • see what is current and what is stale
  • identify conflicting interpretations
  • preserve reasoning, not just outputs
  • update shared knowledge as work evolves
  • reduce dependence on isolated human memory

In other words, the goal is not just to write things down.

The goal is to maintain organisational intelligibility.

Why this matters more over time

As organisations become more digital, more distributed, and more system-dependent, this distinction matters even more.

The larger and faster-moving the organisation, the less it can rely on informal correction to keep meaning aligned.

That means the old pattern, create documents and assume the organisation now knows, becomes more dangerous over time, not less.

And if organisations want to make better use of AI-supported work, this problem becomes even sharper.

AI can process documents.

But if the underlying knowledge body is fragmented, contradictory, stale, or politically distorted, AI will not magically fix that. It may simply make the incoherence scale faster.

The point is not less documentation

This is not an argument against documentation.

It is an argument against overestimating what documentation alone can do.

Organisations still need documentation. They need records. They need traceability. They need written structures.

But they also need humility.

A document is not the same as shared knowledge.

If an organisation wants stronger foundations, it has to move beyond the comfort of recorded fragments and toward the harder work of building knowledge that remains connected, interpretable, and alive.