Skip to main content

From local workflow to shared ontology

· 6 min read

One reason organisational modelling struggles is that it often feels too large to begin.

The enterprise is too complex. The terminology is unstable. The systems do not line up. The teams use different language. The documentation is incomplete. The real work contains too many exceptions.

So the organisation postpones the harder structural work. Or it launches a giant modelling exercise that becomes abstract before it becomes useful.

Both responses are understandable. Neither is very good.

A better path is to grow shared structure from local workflow outward.

Organisations do not need to model everything up front​

A lot of modelling efforts fail because they aim for totality too early.

They try to define the whole organisation in one pass. Every capability. Every process. Every relationship. Every object. Every term.

That creates a heavy burden before value is visible. It also creates pressure to settle concepts that the organisation has not yet learned how to use consistently.

In practice, this often leads to two outcomes:

  • a large abstract model with weak operational adoption
  • a stalled effort that never becomes part of real work

Neither outcome helps much.

The more useful path is gradual structural learning​

An organisation can build a stronger model by starting where knowledge is already being exercised.

That usually means local workflow. The places where work is already happening, decisions are already being made, handoffs are already occurring, and ambiguity is already producing friction.

Those local points are not a distraction from the enterprise model. They are one of the best starting points for building it.

They show:

  • which concepts actually matter
  • which relationships are operationally important
  • where terminology breaks down
  • where dependency knowledge is missing
  • where the same patterns recur across teams

This is valuable because it turns modelling into learning instead of speculative completeness.

Local workflow is where organisational truth shows itself​

Official documents tell part of the story. Local workflow often reveals the rest.

It shows what people actually need to know to get work done. It shows where formal structure is sufficient and where it is not. It shows which categories are real enough to support coordination and which ones collapse under use.

If an organisation pays attention to that layer, it can start turning local working knowledge into shared structure.

That is how ontology becomes grounded instead of ornamental.

Shared ontology does not have to begin as a grand taxonomy​

The word ontology can sound heavier than it needs to.

At a practical level, it means building shared understanding of the things the organisation needs to reason about, and the relationships between them.

That can start simply.

For example:

  • what counts as a service
  • how a capability differs from a team
  • what a dependency really is
  • what states matter in a workflow
  • how work, decision, risk, evidence, and ownership connect

These are not just modelling questions. They are coordination questions.

When the organisation gets them clearer, local work becomes easier to connect. When it does not, every team ends up reinventing its own private ontology.

The bridge is contribution, not central declaration​

A lot of organisations assume shared structure must arrive through central definition first. Sometimes that is necessary. But if it becomes the only path, progress slows down and adoption weakens.

A stronger pattern is contribution.

Local workflow surfaces contribute useful structural learning back into a shared model. The shared model then improves later local experiences. That creates a feedback loop.

In that loop:

  • local work informs shared structure
  • shared structure improves local work
  • repeated use sharpens concepts over time

This is more realistic than expecting a central group to define the whole ontology in isolation.

Gradual growth also makes disagreement more usable​

Another advantage of growing a shared ontology gradually is that disagreement becomes informative instead of fatal.

When teams use different language or categories, that does not have to block progress completely. It can help reveal:

  • where concepts are unstable
  • where the organisation has hidden variation
  • where shared terms are overloaded
  • where local differences are real and where they are accidental

That gives the organisation a better basis for deciding what truly needs to be common and what can remain contextual.

This approach supports coherence without demanding perfection first​

Many organisations delay structural work because they think the model has to be clean before it can be useful.

That is backwards.

A useful model often becomes cleaner because it is used. Because gaps are exposed. Because conflicts become visible. Because recurring workflow pressure reveals what the organisation actually needs to stabilise.

That is one reason I think of this as a path from local workflow to shared ontology. The point is not to avoid structure. The point is to let structure emerge through meaningful organisational use.

Why this matters for knowledge and governance​

When local workflow can feed a shared structure, the organisation gets more than a better model. It gets a better foundation for governance and knowledge reuse.

It becomes easier to:

  • trace where a concept is used
  • compare patterns across teams
  • detect recurring gaps or contradictions
  • preserve useful reasoning near the point of work
  • reduce duplicated interpretation effort
  • build experiences that stay locally relevant while remaining structurally connected

This is part of how an organisation becomes more legible to itself.

The point​

An organisation does not need to choose between local pragmatism and enterprise structure.

It can use local workflow as the path into enterprise structure.

That is often the more honest route anyway. Because local workflow is where the organisation reveals what its concepts, relationships, and gaps actually are.

If that learning is captured, connected, and reused, the organisation can gradually grow from scattered local knowledge toward a more shared ontology.

Not all at once. Not as a giant abstract exercise. But as a living structural accumulation of what the organisation learns through work.

Why diagramming the enterprise is not enough

· 5 min read

Diagramming matters.

A good model can clarify relationships. It can expose missing structure. It can make complexity more discussable. It can help people reason about systems that would otherwise remain vague.

That is valuable.

But many organisations make too much of it. They act as if creating the model is close to creating coherence. It is not.

Diagramming the enterprise is useful. It is just not enough.

A diagram can show structure without creating understanding​

One of the strengths of a diagram is compression. It can put a lot of structure into one visible frame.

People can see:

  • domains
  • relationships
  • flows
  • dependencies
  • categories
  • hierarchy
  • boundaries

That is powerful.

But seeing structure is not the same as living inside shared meaning. A diagram may show that two things are related without helping people understand how that relationship matters in real work. It may show the official shape of the organisation while ignoring how the organisation is actually experienced.

Most enterprise diagrams stop at the representational layer​

This is the core limit.

A lot of enterprise modelling work focuses on representation. How do we map the business? How do we classify the systems? How do we show the capabilities, services, applications, data, infrastructure, and dependencies?

Those are fair questions.

But the organisation does not run only as a represented system. It runs as an experienced system. People encounter it through:

  • workflows
  • handoffs
  • permissions
  • delays
  • exceptions
  • coordination burdens
  • local interpretation
  • incomplete context

A model that does not connect to those lived realities will often remain conceptually impressive and operationally weak.

Representation without use becomes decorative truth​

This is what happens surprisingly often.

An organisation invests in diagrams, maps, taxonomies, or architecture views. They are reviewed. They are approved. They are maybe even admired.

And then daily work continues somewhere else.

The model becomes a kind of decorative truth. It is not exactly wrong. It is simply not shaping enough of the organisation's real coordination.

That gap matters. Because if the model does not influence experience, interpretation, and action, then it cannot do the harder work of improving coherence.

A model needs paths into lived work​

If diagramming is going to matter, the model has to connect to use.

That means people need practical ways to move from structure into experience. They need to be able to see not only what the model contains, but how it helps them:

  • understand the work in front of them
  • navigate dependencies
  • interpret responsibilities
  • find the right context
  • connect local work to shared structure
  • surface missing knowledge and contradictions

Without those paths, the model stays above the organisation instead of within it.

Organisations do not need only visibility, they need intelligibility​

This is the distinction I keep coming back to.

Visibility means the organisation has managed to make something observable. Intelligibility means people can use that visibility to understand, coordinate, and act with less guesswork.

A diagram gives visibility. It may or may not give intelligibility.

That depends on whether the diagram is part of a wider system of shared concepts, contextual views, traceability, and organisational learning.

Static diagrams struggle with change​

There is another problem.

Organisations change continuously. Roles move. Processes drift. Exceptions multiply. Technology shifts. New dependencies appear. Old diagrams remain.

If the model is mainly a static artefact, it will often lag reality. Once that happens, trust in the model declines. People stop using it as a serious aid to understanding and start treating it as formal documentation with uncertain currency.

That is a familiar fate.

The real question is what the model is for​

A lot of enterprise modelling becomes weaker than it should because this question is not answered clearly.

Is the model for:

  • documentation,
  • governance,
  • communication,
  • design,
  • analysis,
  • onboarding,
  • knowledge reuse,
  • operational coordination,
  • decision support?

Often the answer is a vague mixture of all of them. That is understandable, but it makes the model easier to admire than to use.

A stronger approach is to treat the model as part of a wider organisational knowledge and experience system. Then the goal is not just to describe the enterprise. It is to make the enterprise more legible to itself.

This is where experience becomes essential​

A good organisational model should support different viewpoints and levels of detail. But more than that, it should support different experiences built on top of the same shared core.

That is how the model becomes useful beyond the architecture room.

A delivery team should be able to encounter the model differently from an executive. A service owner differently from an analyst. A project lead differently from a governance function.

The underlying structure may stay common. The experienced surface should become more relevant.

That is when a model starts becoming operational rather than merely descriptive.

Diagramming still matters​

This is not an argument against diagrams. Quite the opposite.

Diagramming can be one of the most useful ways to:

  • make complexity discussable
  • expose missing structure
  • create a scaffold for shared language
  • organise thinking before building systems around it

But we should be honest about its limits.

A diagram does not automatically create alignment. It does not guarantee shared interpretation. It does not preserve lived context by itself. It does not make governance usable.

Those things require more than representation. They require connection between shared structure and real organisational experience.

The point​

Diagramming the enterprise is worth doing.

It just should not be mistaken for the whole job.

The deeper task is not merely to map the organisation. It is to help the organisation become more understandable, usable, and coherent to the people inside it.

That is a bigger ambition than diagramming alone can satisfy.

Organisational listening as infrastructure

· 5 min read

A lot of organisations say they want feedback.

They say they want transparency, learning, participation, improvement, and collaboration. They say they want people to raise issues early and share what is really happening.

But wanting signal is not the same as being built to receive it.

That is why I think organisational listening should be treated as infrastructure. Not just as culture. Not just as leadership style. Not just as a communication value.

Infrastructure.

Most organisations are better at issuing than absorbing​

Many organisations are built to send.

They publish strategy. They publish plans. They publish standards. They send updates. They announce changes. They assign work. They escalate down formal channels.

But they are much weaker at absorbing what comes back from lived work.

Important signal gets trapped in:

  • frontline observations
  • recurring exceptions
  • workaround patterns
  • delivery friction
  • repeated misunderstandings
  • hidden dependencies
  • knowledge held by the people closest to the problem

When the organisation cannot absorb those signals well, it becomes noisy on the surface and deaf underneath.

Listening is not just about hearing complaints​

This is where people often narrow the idea too much.

Organisational listening is not only about surveys, grievances, or morale. It is about whether the organisation can detect and use meaningful signal from its own operation.

That includes signal about:

  • where knowledge is missing
  • where process is breaking down
  • where governance is being bypassed
  • where the same confusion keeps recurring
  • where local workarounds are becoming shadow systems
  • where the organisation's official model no longer matches reality

That is not a soft extra. That is core operating intelligence.

Without listening, governance becomes delayed and theatrical​

If an organisation cannot hear itself properly, governance becomes reactive.

Problems become visible late. Decisions happen on partial information. Control measures increase after failure instead of learning earlier from weak signals. Committees discuss symptoms that have been obvious to working teams for months.

Then governance starts to feel theatrical. It performs seriousness after the system has already drifted.

That is one reason organisations often feel over-controlled and under-aware at the same time.

Listening needs structure, not just good intentions​

It is easy to say "leaders should listen more". Sometimes that is true. But personal attentiveness does not scale into organisational capability by itself.

Real listening needs structure.

The organisation needs ways to:

  • capture signal close to where it appears
  • preserve context instead of stripping it out too early
  • connect signal to shared concepts and structures
  • route it to places where it can matter
  • compare repeated patterns across time and teams
  • reflect useful learning back into work, guidance, and decision-making

Without those mechanisms, listening remains intermittent and personality-dependent.

A listening organisation reduces translation loss​

One of the biggest problems in large organisations is translation loss.

Something real happens in one part of the system. It gets described informally. Then summarised. Then escalated. Then reframed. Then turned into a management issue, a delivery issue, a compliance issue, or a tooling issue.

By the time it reaches a place where it could influence wider action, much of the meaning has been flattened or lost.

A better listening capability reduces that loss. It helps the organisation preserve more of the original signal while still making it reusable at higher levels.

That is not just a communications improvement. It is a knowledge and governance improvement.

Listening also makes the organisation more teachable​

An organisation that listens well becomes easier to improve because it learns from its own operation.

It becomes more able to notice:

  • where people are improvising around missing structure
  • where systems create unnecessary friction
  • where knowledge is trapped instead of shared
  • where teams are solving the same problem separately
  • where standards are too abstract to be usable

Those are exactly the kinds of signals that should shape better organisational design.

If they are not heard, improvement depends too much on accidents, heroic individuals, or visible failure.

This is part of what a better platform should do​

A governance and knowledge platform should not only publish guidance. It should also help the organisation listen.

That means helping it:

  • connect local contribution into shared structure
  • surface recurring friction instead of hiding it
  • preserve reasoning and context around signal
  • make cross-team patterns more visible
  • support feedback loops that change real work, not just reporting

In that sense, listening is not separate from governance. It is one of the conditions that make governance intelligent rather than ceremonial.

Why this matters even more later​

The more complex, distributed, and technology-dependent an organisation becomes, the more expensive bad listening gets.

The organisation cannot rely on hallway correction. It cannot rely on a few experienced people intuiting everything. It cannot rely on periodic review alone.

If it wants to adapt well, it has to get better at hearing the system while the system is running.

That is why I think organisational listening should be treated as infrastructure.

Not because it sounds progressive. Because without it, coherence decays faster than the organisation can understand.

Why Frameworks Fail?

· 6 min read

Frameworks often arrive with a promise.

They will create clarity. They will improve consistency. They will make good practice portable. They will reduce guesswork. They will help the organisation mature faster.

Sometimes they do help.

But many frameworks that look intelligent, well-structured, and battle-tested on paper still fail in practice.

That failure is often misunderstood. It gets blamed on poor rollout, weak training, bad tooling, or resistant people.

Those things can matter.

But they are not the whole story.

Frameworks often fail because they are dropped into living organisations as if they were neutral upgrades, when in reality they are entering systems with their own history, incentives, language, tensions, and knowledge structure.

A framework is an iceberg of compressed knowledge​

A framework is not just a checklist.

It is packaged judgment. It carries assumptions. It reflects tradeoffs. It contains a way of seeing problems, organising action, and deciding what matters.

In that sense, a framework is a compressed knowledge structure.

It represents:

  • accumulated lessons
  • embedded concepts
  • hidden assumptions
  • preferred patterns
  • views about coordination and control
  • expectations about roles, timing, and behaviour

That is why frameworks can be powerful.

But it is also why they can fail.

When people import a framework, they are not just importing a process. They are importing a whole way of interpreting organisational reality.

Organisations are also knowledge icebergs​

The problem is that organisations are not blank surfaces waiting to receive a better pattern.

They are already full of structure.

An organisation carries its own:

  • history
  • politics
  • incentives
  • language
  • local habits
  • system dependencies
  • power arrangements
  • institutional memory
  • missing memory
  • workarounds and exceptions

A lot of that structure is visible. A lot of it is not.

That is why I think it helps to treat organisations as knowledge icebergs too.

What is written down is only part of the picture. A much larger part sits below the visible line, in habits, social expectations, unwritten constraints, and fragmented local understanding.

When a framework meets an organisation, it is really one knowledge iceberg colliding with another.

Framework failure is often an alignment failure​

Framework advocates often talk as if good practice should transfer cleanly.

But even a strong framework can fail if it does not align with:

  • how the organisation actually makes decisions
  • what incentives people are operating under
  • what knowledge is shared versus trapped
  • how much local variation already exists
  • how much translation the system can sustain
  • what kind of social change the framework is really asking for

This is why framework adoption is never only technical.

A framework may specify a workflow, a role model, a planning cycle, a governance method, or a way to classify work. But underneath that, it is also asking people to:

  • reinterpret their work
  • trust a new structure
  • change local habits
  • accept new tradeoffs
  • expose hidden ambiguity
  • surrender some familiar autonomy
  • learn a new language for coordination

That is a much bigger ask than many implementation plans admit.

Social rejection is real, even when nobody says it out loud​

One of the hardest things about framework failure is that rejection is often quiet.

People do not always openly oppose a framework. They route around it. They half-adopt it. They comply in visible places and ignore it in real work. They keep local spreadsheets, local rules, local workarounds, and local interpretations.

From a distance, the framework looks present.

In reality, the organisation is slowly absorbing only the pieces it can tolerate and shedding the rest.

That is why passive rejection is so common. It does not look dramatic. It looks like drift.

A little inconsistency here. A local exception there. A role that never quite behaves as intended. A review step that becomes theatre. A standard that nobody trusts enough to rely on.

Over time, the framework remains as surface structure while the organisation continues to run on older logics underneath.

Translation burden kills a lot of frameworks​

Many frameworks also assume the organisation can sustain a lot of interpretation work.

Someone has to:

  • explain the framework
  • translate it into local context
  • resolve conflicts between it and existing practice
  • keep guidance current
  • answer edge cases
  • maintain quality of interpretation across teams

That work usually falls onto a small number of people. Architects. Analysts. Managers. Transformation leads. Coaches. Governance specialists.

That creates a fragile dependence on translators.

If the framework only works when a few people continually interpret it for everyone else, then the framework has not really become part of the organisation. It has become a side-hustle held together by intermediaries.

That does not scale well. And it becomes even harder as the organisation grows more complex.

Frameworks fail when they are treated as uploads​

A lot of failed adoption efforts share one bad assumption:

that framework knowledge can simply be uploaded into the organisation.

As if the organisation were just waiting for a better operating system.

But organisations do not change like software patches. They change through social integration. Through interpretation. Through tension. Through adaptation. Through repeated encounters between existing structure and new structure.

That means the question is not just:

Is this framework good?

It is also:

What kind of organisational change is this framework actually demanding?

If the answer is not understood, the framework will often fail regardless of its quality.

AI will not magically solve this​

It might be tempting to think AI will make framework adoption easier.

In some ways it will help. AI can explain frameworks, summarise guidance, compare practices, and reduce some translation overhead.

But AI does not remove the underlying alignment problem.

If the organisation is fragmented, politically distorted, weakly connected, or dependent on tacit local knowledge, AI will not make framework adoption automatically coherent. It may simply scale the interpretation problem faster.

The deeper challenge remains the same. A framework has to be absorbed by a living system.

The real lesson​

Frameworks do not fail only because they are badly designed.

They fail because organisations are living, uneven, historically shaped systems that cannot be remade by importing a neat pattern and expecting clean compliance.

That does not mean frameworks are useless.

It means they should be treated with more realism.

A framework is not a shortcut around organisational complexity. It is another structured knowledge body entering that complexity.

If it is going to help, it has to align with the organisation, adapt to it, and become socially and operationally integrated into real work.

Otherwise it will survive only as surface structure. And surface structure is where a lot of failed frameworks go to live.

Shared core, tailored experience

· 5 min read

One of the hardest organisational design problems is this:

how do you keep a shared whole without forcing everyone into the same local experience?

A lot of governance and architecture work answers that badly.

Some organisations over-centralise. They try to impose one model, one view, one workflow, one structure of interaction on everyone. That usually creates distance from real work.

Others go the other way. They let every team build its own language, its own conventions, its own local tools, and its own operating logic. That usually creates fragmentation.

Neither answer is strong enough.

What organisations really need is a shared core with tailored experience.

The shared core is what lets the organisation stay one organisation​

A healthy organisation needs some things to remain common.

Not identical in presentation, but common in underlying meaning.

That shared core includes things like:

  • core concepts
  • key relationships
  • decision records
  • organisational structures
  • standards and policies
  • service definitions
  • role responsibilities
  • cross-team dependencies
  • traceability between change, work, and outcome

Without that shared core, each team gradually builds a partial private version of the organisation. That is how silos harden. That is how translation burden rises. That is how meaning drifts.

The shared core is what makes it possible for different parts of the organisation to remain legible to one another.

But the organisation cannot be consumed through one generic view​

The existence of a shared core does not mean everyone should interact with the organisation in the same way.

A frontline worker, a delivery lead, an architect, an executive, a service owner, and an analyst do not need the same view at the same moment. They do not need the same depth. They do not need the same controls. They do not need the same path into the knowledge.

If the organisation forces one generic experience on all of them, it creates a different kind of failure.

The structure may be shared, but it becomes hard to use. People start bypassing it because it does not meet them where they work.

Then the shared core becomes nominally correct but practically weak.

Tailored experience is how shared structure becomes usable​

Tailoring is not cosmetic. It is the mechanism that makes common structure operable in local context.

A tailored experience should help a person or team see:

  • what matters here
  • what applies now
  • what this work depends on
  • what responsibilities exist in this situation
  • what actions are available
  • what risks, standards, or constraints are relevant
  • how local work connects back to the wider system

That is what makes a shared structure usable instead of merely documented.

The wrong version of tailoring produces fragmentation​

Of course, tailoring can also go wrong.

If every local experience starts inventing its own concepts, its own truth, and its own hidden logic, then the organisation no longer has tailoring. It has divergence.

That is why the distinction matters.

Good tailoring:

  • changes presentation
  • changes emphasis
  • changes navigation
  • changes workflow support
  • changes level of detail

Bad tailoring:

  • changes meaning
  • changes core relationships
  • changes organisational truth by accident
  • hides critical cross-boundary dependencies

The first kind strengthens coherence. The second dissolves it.

A lot of organisational pain comes from getting this balance wrong​

When organisations do not hold this balance well, they tend to fall into one of two traps.

Trap one: abstract centralism​

This is where a central group defines the official model, but the model is too detached from local use. People are expected to adapt to it without enough support, relevance, or translation.

The result is predictable:

  • low trust in the central structure
  • local shadow systems
  • high dependence on a few interpreters
  • governance as overhead instead of support

Trap two: unmanaged localism​

This is where each team solves for itself and gradually builds its own operating reality.

The result is also predictable:

  • duplicated knowledge
  • harder cross-team coordination
  • inconsistent language
  • hidden dependency risk
  • rising cost of change

Shared core with tailored experience is the way out of both traps.

This is a design problem, not just a policy problem​

Many organisations try to solve this problem through documentation alone. They publish better standards, better process maps, better architecture diagrams, better guidance.

That helps, but it is not enough.

The deeper problem is design. How does the organisation actually present itself to people through tools, workflows, and knowledge surfaces? How does shared meaning show up in context? How does local work remain connected to the wider structure?

Those are experience questions as much as governance questions.

Why this matters for organisational learning​

A shared core with tailored experience does more than improve usability. It also improves learning.

When local work is connected back to common structure, the organisation becomes better able to:

  • compare patterns across teams
  • spot repeated failures or gaps
  • reuse knowledge more effectively
  • surface dependencies earlier
  • absorb learning from the edge into the shared system

Without that connection, local learning stays local. And organisations end up rediscovering the same lessons in parallel.

The point is coherence without flattening​

That is the real goal.

Not central control. Not perfect standardisation. Not pure local freedom.

Coherence without flattening.

An organisation should be able to present relevant, contextual, role-appropriate experiences while still holding onto a common structural core.

When it can do that, governance becomes more usable. Knowledge becomes more reusable. Coordination becomes less fragile. And change becomes easier to absorb without losing the whole.

Why shared governance fails without shared experience

· 5 min read

Many organisations believe they have shared governance because they have shared documents.

A policy exists. A framework exists. A process exists. A committee exists. A set of approved terms exists.

From a distance, that can look like alignment.

But shared governance does not really exist when people still experience the organisation through fragmented local realities.

That is where a lot of governance failure begins.

Governance often exists officially, not experientially​

An organisation may say it has one strategy, one set of priorities, one way of making decisions, one set of rules.

But what people actually experience can be very different.

One team experiences urgency. Another experiences delay. One experiences heavy control. Another works through informal exception. One sees clear ownership. Another sees negotiation and ambiguity.

The organisation looks shared on paper while remaining divided in practice.

That means the real issue is not whether governance has been declared. It is whether governance is being encountered in a shared enough way to shape behaviour coherently.

Shared documents do not create shared meaning​

This is a common mistake.

Organisations often assume that once something has been written down and published, it has become shared. But publication is not the same as interpretation. And interpretation is not the same as lived experience.

People still meet governance through:

  • their workflow
  • their team habits
  • their system permissions
  • their escalation paths
  • the incentives around them
  • the quality of local translation
  • what gets rewarded or ignored

If those experiences vary too much, the organisation does not really have shared governance. It has shared artefacts sitting above divergent realities.

Governance breaks where local reality takes over​

Local adaptation is not the problem by itself. Every team needs some ability to work in context.

The problem appears when local reality becomes the main operating logic because the shared layer is too abstract, too distant, or too hard to use.

That is when organisations start seeing familiar symptoms:

  • the same rule interpreted differently across teams
  • cross-boundary work slowed down by translation
  • local workarounds becoming the real process
  • standards that are acknowledged publicly but bypassed privately
  • governance forums spending most of their time resolving confusion that should not exist in the first place

At that point, governance is no longer functioning as a shared organising force. It is functioning as a weak reference layer.

Shared governance needs shared experience at the point of work​

If governance is meant to shape real behaviour, it cannot live only in documents and escalation structures. It has to become part of how people encounter work.

That means governance has to become visible through experience.

People need to encounter shared structure through things like:

  • the way information is presented
  • the way work is classified
  • the way dependencies are shown
  • the way decisions are traced
  • the way exceptions are handled
  • the way risks and responsibilities appear in context

In other words, governance has to stop being only an abstract control layer. It has to become part of the organisation's lived operating surface.

This is why experience matters​

The word experience can sound soft, but the issue is structural.

Organisations do not run on theory alone. They run on repeated encounters with systems, roles, signals, constraints, and choices. Those repeated encounters teach people what the organisation really is.

If the lived experience says:

  • local interpretation matters more than shared structure
  • finding context is everyone's private problem
  • governance is something you deal with later
  • coordination depends on who you know rather than what is legible

then that is the organisation people will learn.

No amount of polished governance language will fully compensate for that.

A shared experience does not mean a uniform experience​

This distinction matters.

Shared governance does not require everyone to see exactly the same thing. Different roles need different context. Different teams need different detail. Different decisions need different views.

What matters is that these experiences are built on top of a common structure.

That means people can work from different vantage points without drifting into different realities. They can stay locally effective while remaining part of the same organisational system.

That is much closer to what good governance should do.

Why this matters more as organisations grow​

The larger and more complex the organisation, the less it can rely on informal correction.

In a small group, people can compensate for missing structure through conversation, memory, and trust. At scale, that stops working. The organisation needs stronger ways to make shared meaning usable.

Otherwise fragmentation becomes normal. And once fragmentation becomes normal, governance becomes increasingly reactive. It shows up to repair divergence after it has already become expensive.

The real challenge​

The challenge is not just to define governance well.

It is to make governance usable enough, visible enough, and connected enough that people can actually experience the organisation as a coherent whole while doing local work.

That is the deeper reason shared governance fails so often.

It is not always because the organisation lacks rules. It is because it lacks shared experience.

Governance Experience Platform

· 6 min read

Most organisations do not fail because nobody cares.

They fail because shared intent breaks apart on the way to lived work.

Leadership says one thing. Teams hear different things. Systems enforce something else. Local habits fill the gaps. And the organisation slowly drifts into a patchwork of partial understandings.

That is not just a communication problem. It is a governance problem.

And it points to something most organisations still do not have:

a practical way to turn shared governance into usable day-to-day experience.

Governance usually arrives too late​

In many organisations, governance shows up as:

  • policy documents
  • review gates
  • committees
  • escalations
  • controls
  • compliance checks
  • post-incident corrections

Some of that is necessary.

But it is mostly after-the-fact governance. It reacts once misalignment, risk, or drift has already become visible.

That means the organisation is often trying to correct behaviour downstream instead of shaping experience upstream.

By the time governance appears, teams have already improvised their own ways of working. The result is familiar:

  • rules that feel detached from reality
  • local workarounds that quietly become standard practice
  • fragmented interpretation between teams
  • slow coordination across boundaries
  • recurring confusion about purpose, ownership, and priority

The real breakdown is in lived organisational experience​

Organisations are socio-technical systems.

People do not experience them as diagrams. They experience them as work. As tools. As process. As permissions. As friction. As signals. As incentives. As what gets noticed, rewarded, blocked, escalated, and ignored.

That is why governance cannot stay abstract.

If governance is supposed to shape behaviour, coordination, and adaptation, it has to become something people can actually experience in context.

Not just something written down somewhere else.

Most organisations are full of misaligned local realities​

At scale, every team develops its own local view of the system.

That is understandable. People optimise for the work in front of them. They simplify complexity to stay productive. They rely on local language, local priorities, and local workarounds.

But over time that creates an organisational split.

The official organisation says it has one purpose, one set of standards, one set of decisions, one operating model. The lived organisation behaves as a federation of partially connected realities.

That fragmentation shows up in basic organisational failures:

  • communication without shared meaning
  • collaboration without shared context
  • cooperation without mutual trust
  • coordination without stable alignment

The organisation does not just need more messages. It needs better shared experience.

A Governance Experience Platform should make governance usable​

This is where the idea of a Governance Experience Platform matters.

A GXP should not be understood as a dashboard, portal, or software category first.

It is a way of organising governance so that shared structures become usable through local experience.

In plain terms, it should help an organisation do something hard:

maintain a common knowledge and governance core while presenting relevant, contextual, actionable experiences to different people and teams.

That means a GXP should help turn governance into something people can actually work with.

Not just read about.

Shared core, tailored experience​

This is the crucial pattern.

A healthy organisation needs both:

  • a shared core
  • tailored experience

The shared core provides common structure:

  • purpose
  • concepts
  • standards
  • decisions
  • dependencies
  • traceability
  • knowledge relationships
  • governance patterns

The tailored experience provides local usability:

  • what this team needs to know now
  • what this role is responsible for
  • what matters for this workflow
  • what options, constraints, and signals apply here
  • what actions make sense in this context

If an organisation only has the shared core, it becomes abstract and hard to use. If it only has local tailoring, it fragments into silos.

A GXP should hold both together.

This is really about organisational listening​

One of the deepest problems in large organisations is that they do not listen well.

Not because nobody speaks. Because too much signal gets lost, filtered, translated late, or drowned out by noise.

Important knowledge sits in:

  • frontline observations
  • local delivery pain
  • repeated workaround patterns
  • recurring exceptions
  • near misses
  • hidden dependencies
  • good ideas that never get connected upward

Most organisations do not have a good way to absorb all of that and turn it into shared learning.

That creates what I think of as organisational deafness.

A Governance Experience Platform should improve organisational listening by making it easier to:

  • capture meaningful signals closer to where they arise
  • connect them to shared structures
  • route them into useful context
  • reflect them back as better guidance, decisions, and experiences

That is one reason GXP matters. It is not just about publishing governance. It is about helping governance learn.

Why this matters even more with AI​

AI increases the value of this kind of platform because AI works best when the surrounding organisation is legible.

If knowledge is fragmented, if context is trapped, if teams are operating from incompatible local realities, AI will not create coherence. It will amplify whatever structure already exists.

That means an organisation that wants useful AI support needs more than model access. It needs a way to connect:

  • knowledge
  • work
  • roles
  • decisions
  • signals
  • constraints
  • feedback

A Governance Experience Platform can help provide that connective layer.

It can make shared governance more operationally visible and more locally usable.

And once that happens, AI has something better to work with than disconnected fragments.

GXP is not centralised control​

This matters.

The point is not to create a giant command console where one part of the organisation dictates every other part.

That would just create a different kind of brittleness.

The point is to create stronger coherence without erasing local context.

A good GXP should help an organisation:

  • keep shared purpose visible
  • make dependencies easier to understand
  • reduce translation burdens
  • support cross-team alignment
  • preserve contribution visibility
  • make governance more participatory and less theatrical

It should strengthen coordination without flattening everything into one generic experience.

Toward organisational experiences that reinforce the whole​

This is why I think the word experience matters.

Governance becomes real when it is encountered through meaningful interactions. Not just through policy statements.

A team experience. A delivery experience. A decision experience. A contribution experience. A risk experience. A learning experience.

If those experiences are built on top of a shared knowledge and governance core, the organisation becomes more coherent over time.

If they are not, the organisation becomes harder to understand, harder to align, and harder to improve.

That is the real role of a Governance Experience Platform.

Not to decorate governance. To operationalise it through experiences that help the organisation hold together while it changes.

A case for Governance Framework

· 5 min read

One of the most common mistakes in governance work is to assume that a pattern that worked somewhere else can simply be transplanted here.

A committee model, a delivery method, a risk structure, a control pattern, a maturity framework, a decision process.

The reasoning is always understandable.

If another organisation solved a similar problem, why not copy what worked?

Because governance patterns are not plug-ins.

They are the visible expression of a much deeper organisational history.

Copy-paste governance does not transfer cleanly​

When people talk about adopting a governance model, they often talk as if the model exists independently of the organisation that produced it.

But most governance patterns are evolutionary.

They are not just designed. They are accumulated. They emerge through years of:

  • tradeoffs
  • failures
  • adaptations
  • local incentives
  • historical constraints
  • technical realities
  • social compromise

That means a governance pattern is never just a method. It is also a record of the conditions that shaped it.

If those conditions are not present in the organisation trying to adopt it, the pattern will not behave the same way.

Governance is shaped by organisational maturity​

Every organisation has its own maturity path.

Not just in a generic scorecard sense, but in the more practical sense of what it can currently absorb.

An organisation’s governance pattern reflects things like:

  • how decisions are made
  • how authority is distributed
  • how much trust exists between groups
  • how much shared language exists
  • how much operational discipline is already present
  • how well information moves through the system
  • how adaptable the social and technical layers are

That is why governance cannot be separated from the maturity of the organisation carrying it.

A pattern that works in one place may depend on capabilities, norms, or shared structures that do not exist somewhere else yet.

If you import the surface pattern without the underlying conditions, you usually get ceremony without effect.

Oversight-heavy governance is often a symptom of the older model​

Across many industries, governance is still treated mainly as oversight.

Something that intervenes after the fact. Something that checks, reviews, escalates, approves, or corrects once events have already unfolded.

That approach can work in simpler environments or when experienced central authority can still keep up with complexity.

But as organisations become more socio-technical, more distributed, and more interdependent, reactive oversight stops scaling well.

The organisation becomes too complex for central correction alone to keep it coherent.

That is one reason so many governance models feel heavy but still fail to prevent drift.

They are trying to solve structural problems too late in the process.

What organisations need is scaffolding, not imitation​

This is why I think the better approach is not to copy a finished governance pattern.

It is to provide a stronger governance foundation.

A governance foundation is closer to scaffolding than a rigid template.

It gives the organisation:

  • concepts it can use to understand itself
  • distinctions that clarify what actually needs governing
  • reference models that can be adapted rather than copied
  • a shared area for knowledge and contribution
  • a way to grow governance as the organisation matures

That is a very different ambition from handing over a fixed model.

The point is not to force an organisation through someone else’s history. The point is to help it build its own more deliberately.

A useful framework should unlock selectively, not impose all at once​

A mature governance approach should not assume that every part of the model needs to appear on day one.

Different organisations need different levels of structure at different stages.

Some need clearer language and shared concepts first. Some need better decision traceability. Some need stronger cross-team coordination. Some need more legible risk and control structure.

That means a useful governance framework should act more like progressive scaffolding.

As the organisation develops, it should be able to unlock and use the parts that match its actual maturity and needs.

That is far more realistic than expecting wholesale adoption of an externally conceived pattern.

Shared knowledge matters here too​

Another reason imitation fails is that governance depends on knowledge flow.

If governance knowledge is fragmented, trapped in specialists, or poorly shared, then even a sensible model will become brittle.

A stronger governance foundation should help create:

  • a shared knowledge area
  • clearer visibility into patterns and rationale
  • better contribution pathways
  • less dependence on a small number of intermediaries

That matters because governance is not just structure. It is also an organisational learning problem.

The real case for Governance Foundation​

So the case is not really for another generic governance framework.

It is for a governance foundation that helps organisations develop governance that fits their own structure, maturity, and trajectory.

That means moving away from copy-paste governance and toward something more adaptive.

Something that:

  • supports growth without pretending every organisation starts in the same place
  • helps people share and evolve governance knowledge
  • reduces unnecessary deviation without crushing local context
  • provides common reference points without forcing mechanical imitation

That is the real value.

Not importing governance as a finished product. But helping organisations build stronger governance from foundations that can actually live inside them.

Why Governance Foundation?

· 3 min read

Governance Foundation exists because too much work that matters gets built on weak foundations.

Organisations create strategy, policy, projects, systems, controls, and frameworks all the time. But they often do so without a clear shared understanding of what governance is actually for.

The result is familiar.

Governance gets treated as bureaucracy. Frameworks get treated as paperwork. Controls get treated as friction. Transformation gets treated as a delivery exercise. And the deeper structural questions, how an organisation holds together, makes decisions, coordinates action, moves knowledge, and adapts over time, are left underexplored.

This site exists to work on those deeper questions.

Governance is not just oversight​

Governance is often reduced to boards, compliance, review gates, or formal authority.

Those things matter. But they are not the whole story.

Governance is also about the forces, structures, relationships, and mechanisms that shape how an entity behaves in its environment.

That means governance is not only something an organisation writes down after the fact. It is something an organisation lives through every day.

It shows up in:

  • how decisions are made
  • how work is coordinated
  • how responsibilities are distributed
  • how change is controlled or allowed
  • how knowledge moves or gets trapped
  • how incentives shape behaviour
  • how systems reinforce or undermine intended direction

If these things are weak, unclear, or contradictory, no amount of polished documentation will save the organisation from drift.

Why a foundation matters​

The word foundation matters here.

A framework can be useful, but frameworks are often applied too early and too mechanically. People reach for a template before they understand the conditions it is meant to address.

A foundation is different.

A foundation is the body of concepts, distinctions, models, questions, and reference points that help us understand what governance needs to do before we decide how to formalise it.

That includes questions like:

  • What is being governed?
  • In what environment?
  • Toward what purpose?
  • With what constraints?
  • Through what structures?
  • By whom?
  • With what information?
  • At what level of adaptability?

Without that foundation, governance easily becomes theatre.

Why this site exists​

This site is intended to bring together material that helps build a better foundation for governance work.

That includes:

  • foundational governance concepts
  • governance paradigms and perspectives
  • governance-related frameworks
  • structural models such as GXP
  • thinking about knowledge, organisations, and system behaviour
  • practical ideas that can later inform better methods

The goal is not to collect material for its own sake.

The goal is to make it easier to reason clearly about governance in a way that is useful, structural, and alive.

A longer direction​

Over time, this work should move beyond simply reviewing existing governance ideas.

It should also help develop new ones.

That means exploring governance not just as a static body of institutional practice, but as something that interacts with organisational structure, knowledge systems, collaboration, technology, and eventually AI-supported ways of working.

That broader direction will take time. But it needs a place to start.

Governance Foundation is that starting point.

Welcome to the work​

So this is not just a welcome post.

It is a statement of intent.

Governance deserves to be treated as foundational work, not as an afterthought once the real decisions have already been made.

If this site does its job, it will help make that foundation stronger.