Author: Marcel

Over the years, I have had the opportunity to return to several organizations after long periods away. In three cases, the gap was around ten years. These were large, established organizations. They had existed long before I first worked with them and would presumably continue to exist long after I left. When I returned, I therefore expected a certain degree of familiarity. I was, after all, returning to the same organization.

And in some ways I was. The company name was the same. A few familiar people were still there. Some things were immediately recognizable. But the organization itself felt remarkably different.

Ten Years of Ordinary Change

There was nothing mysterious about this. People had left and new people had arrived. Leadership had changed. Teams had been reorganized. Products and systems had evolved. Priorities had shifted. New initiatives had appeared and old ones had disappeared. None of this required a dramatic transformation. It was simply what happens when an organization continues operating for ten years.

From inside the organization, those changes probably happened gradually. One person left. Another was hired. A team was reorganized. A system changed. A new manager arrived. A different priority emerged. Each change became part of normal organizational life.

Returning after ten years was different because I encountered the accumulated result all at once. The company was still there. The organization I remembered largely was not.

The Same Company?

This made me wonder what we actually mean when we talk about the same company. Institutionally, there is little difficulty. The company has a name, a history and a legal identity that persist over time. We can talk quite comfortably about a company that has existed for fifty, a hundred or even several hundred years.

But the organization that people actually experience is much less permanent. Imagine taking a snapshot of an organization today: its people, leadership, teams, products, systems, priorities, responsibilities and ways of working.

Then take another snapshot ten years later. Even in a very large and relatively slow-moving organization, how much would still be the same? Probably much less than the continued use of the same company name suggests.

An Organizational Generation

There is another way of looking at those ten years. When we talk about generations of people, we usually think in terms of several decades. Thirty years is a reasonable approximation.

An organizational generation may be considerably shorter. Ten years can be enough for much of the leadership to change, large numbers of employees to leave, new people to arrive, organizational structures to evolve, systems to change and priorities to shift.

In that sense, returning after ten years may mean returning not merely to an older version of the organization, but to another organizational generation. The interesting part is that there is no clear boundary between those generations.

One organizational generation does not leave on Friday so that another can arrive on Monday. People overlap. Systems span generations. New structures inherit parts of old structures. Some practices continue while others disappear. New people learn from people who themselves learned from an earlier generation.

The replacement is gradual. There is no handover ceremony between one organization and the next. The company simply continues.

The Ship of Theseus at Work

There is something of the Ship of Theseus in this. If the parts of a ship are gradually replaced until none of the original parts remain, in what sense is it still the same ship?

Organizations make the question even more complicated because they replace far more than their physical parts. They replace people, structures, technologies, products, priorities and ways of working, while continuing to operate under the same institutional identity.

A company that has existed for a hundred years may therefore have passed through many organizational generations.

And yet we still experience continuity. Customers continue dealing with the company. Employees inherit responsibilities from people who came before them. Products continue developing. Decisions made by one generation affect another. Commitments survive the people who originally made them. Somehow, the organization crosses those generational boundaries.

Reflection

Returning after ten years made something visible that is much harder to notice while working inside an organization. Organizations change continuously, and the cumulative change can be enormous.

The company I returned to was unquestionably the same company. Yet in many practical respects, it was a different organization from the one I had left. Perhaps that is entirely normal. Perhaps even the largest and slowest-moving organizations have generations measured not in decades, but in years.

That leaves me with a question rather than a conclusion. If an organization may exist for fifty, a hundred or several hundred years, while an organizational generation may last less than ten, how is continuity preserved across those generations?

I do not think returning to the same organizations answered that question. It simply made the question much harder to ignore.

Organizations often describe major change by naming the framework, technology or theme associated with it.

“We are doing a SAFe transformation.”

“We are becoming agile.”

“We are doing an AI transformation.”

“We need a quality transformation.”

The language suggests that the organization is implementing something. A framework is introduced. New roles appear. New ceremonies are scheduled. Governance changes. Tools are deployed. Training begins.

But that raises a more basic question: what, exactly, is being transformed?

The Framework Is Not the Subject

Consider a SAFe transformation. The visible changes may include portfolio structures, planning events, Product Management, Product Ownership, architecture, release mechanisms, governance, team structures and new artifacts.

It is easy to describe progress in terms of those visible arrangements. Roles have been appointed. Events are happening. Backlogs exist. Governance forums have been established. Yet none of those things, by themselves, demonstrate that the organization has become better at what the transformation was supposed to improve.

The deeper change may concern the organization’s ability to manage portfolios, translate strategy into product direction, coordinate architecture, define requirements, engineer products, test them, release them, learn from operation and make decisions across organizational boundaries. Those are capabilities.

The framework provides one possible set of structures, roles and practices through which those capabilities may be realized. It is not itself the capability. That distinction matters because an organization can become increasingly faithful to a framework without becoming increasingly capable.

Transformation Changes Several Capabilities at Once

Large transformations rarely concern one organizational ability in isolation. An agile transformation may influence portfolio management, Product Management, planning, requirements, engineering, testing, release management, leadership and collaboration. An AI transformation may influence software engineering, customer service, analysis, decision-making, knowledge work, governance, security and Product Management. A quality transformation may affect product definition, architecture, engineering, assessment, testing, operations, governance and learning.

These capabilities may begin at different levels of strength, respond differently to intervention and evolve at different speeds. One may improve rapidly while another remains weak. That matters because the value created by one capability often depends on another.

A stronger testing capability cannot fully compensate for weak requirements if important expectations remain unclear. Better Product Management cannot create the intended effects if engineering cannot reliably realize product decisions. Strong architecture may have limited impact if portfolio decisions repeatedly undermine architectural direction.

Transformation is therefore not simply a collection of independent improvement initiatives. The capabilities form a system.

Uneven Capability Development

This may explain a familiar transformation experience. Some parts of the organization seem to change quickly. New planning practices are adopted. Teams learn new techniques. Tools are introduced. One discipline develops strong leadership and a clear operating model.

Elsewhere, progress is much slower. A neighboring capability remains weak and gradually becomes a constraint on the rest of the transformation. The program may still report progress because many planned interventions have been completed, while the organization continues to struggle with the effects the transformation was meant to create.

This exposes an important difference between implementing change and developing capability. An intervention can be completed. A capability must actually become stronger. And because capabilities depend on one another, the slowest or weakest capability may limit the value produced by improvements elsewhere.

Transformation is therefore not only a sequencing problem. It is also a dependency problem.

From Framework Adoption to Capability Evolution

Seen this way, the transformation question changes. Instead of asking primarily whether the framework has been implemented, we can ask which organizational capabilities we are trying to strengthen.

That immediately leads to more useful questions. What should those capabilities enable? Why do they matter to the organization’s strategic objectives? Which capabilities depend on one another? Where are the current constraints? Which interventions are intended to strengthen which capability? What evidence would show that the capability has actually improved?

The framework may still be useful. It may provide proven structures, terminology, roles and practices that make development easier. But its value becomes instrumental.

It is one possible means of developing the capabilities the organization actually needs.

The Portfolio Becomes the Subject

Once several capabilities are being changed together, another subject appears. The transformation is no longer concerned only with individual capabilities. It is concerned with their composition and relationships.

The organization may strengthen several capabilities while leaving one strategically important gap untouched. Two capabilities may duplicate responsibility. One may have expanded because another remained weak. A capability may depend critically on another that is receiving little attention. Investment may be concentrated in areas where maturity is already sufficient while more important weaknesses persist elsewhere.

These are portfolio questions. The subject of a major transformation may therefore be understood as a portfolio of organizational capabilities.

That suggests a broader definition:

Transformation is the intentional evolution of a portfolio of organizational capabilities in pursuit of strategic objectives.

Strategy Provides the Reference

If transformation is capability portfolio evolution, the organization also needs some basis for deciding what that portfolio should become.

It is not enough to say that every capability should improve. Some capabilities may already be sufficient. Others may require significant development. New strategic objectives may demand capabilities that barely exist today. Some capabilities may become less important, while others need to work together differently.

The reference therefore comes from the future the organization is trying to create. Strategy creates demands on organizational ability. Those demands can be translated into the capabilities the organization needs, the relationships between them and the relative importance of developing each one.

That provides a stronger basis for transformation than framework completeness. A framework may suggest components. Strategy should determine which capabilities matter.

Measuring the Wrong Thing

This perspective also changes how transformation progress should be assessed.

If success is measured mainly through implementation, progress may be reported through adoption indicators.

How many teams use the new method?

How many roles have been appointed?

How many planning events have taken place?

How many people completed training?

Those measures may be useful evidence that interventions occurred, but they are not necessarily evidence of improved capability.

The stronger question is whether the organization can now achieve something it previously could not achieve, or achieve it more reliably, efficiently or sustainably. That requires capability assessment. And because the capabilities interact, it may also require assessment of the portfolio as a whole.

A transformation can contain many locally successful changes while still producing a weak overall result. The parts may improve without the system becoming sufficiently capable.

The Temporary Program and the Permanent Organization

There is another consequence. Transformation programs are temporary. Capabilities are not.

The program may establish new structures, introduce practices, create communities, launch training and coordinate changes across organizational boundaries. For a time, the transformation organization itself provides much of the attention needed to keep those developments moving.

Eventually the program ends. At that point, the capabilities remain. If nobody has become responsible for their continuing management, some of the new arrangements may gradually weaken. People leave. Priorities change. Practices drift. Dependencies shift. The organization learns new things, but nobody incorporates those lessons into the capability.

A transformation can therefore succeed as a program and still fail as continuity if the project changed the organization and nobody remained responsible for managing the ability it created.

From Transformation to Capability Management

This is where transformation connects naturally to Capability Management. Transformation provides concentrated, temporary development. Capability Management provides ongoing stewardship.

A transformation may accelerate the evolution of several capabilities at once. Capability Management ensures that each strategically important capability continues evolving after the temporary intervention ends.

At portfolio level, the same distinction applies.

Capability Portfolio Management would maintain the larger view: which capabilities the organization needs, how they depend on one another, where investment is required and how the portfolio should evolve as strategy changes.

Transformation then becomes a period of deliberate acceleration within that longer lifecycle. Not a temporary departure from normal management but part of it.

Reflection

Perhaps one reason transformations disappoint is that we describe them by the thing we are introducing.

SAFe.

Agile.

AI.

Quality.

That makes implementation highly visible. But implementation is not necessarily transformation.

The deeper question is whether the organization’s abilities have changed. Can it now make better portfolio decisions? Can it translate intent into products more reliably? Can it coordinate architecture more effectively? Can it release safely and learn faster? Can it manage quality with greater confidence?

If the answer is no, the transformation may have changed a great many visible things without changing enough of what actually mattered.

Perhaps that is the better way to think about transformation. Not as the implementation of a framework.

But as the intentional evolution of the capabilities the organization needs to become something different.

Organizations constantly invest in improving capabilities. Testing becomes inconsistent, so an improvement initiative is launched. Requirements quality declines, so new templates, training and governance are introduced. Architecture loses direction, so a maturity program begins. Security, DevOps, business analysis and many other disciplines follow the same pattern.

The sequence is familiar. A problem is identified, an assessment is performed, interventions are designed, people are trained, practices are changed, tools are introduced and new ways of working are established.

Eventually the initiative ends. The consultants leave. The project team dissolves. The transformation roadmap is closed. Everyone returns to normal work.

A few years later, the same capability is often under discussion again. Testing has become inconsistent. Requirements quality has deteriorated. Architectural direction has weakened. Another maturity initiative is needed.

This raises a simple question. Perhaps capability improvement is not the same thing as capability management.

Improvement Has an End Date

Improvement initiatives are temporary by design. They exist because the organization has identified a gap between its current ability and the ability it believes it needs. Their purpose is to create change.

That makes them valuable, but it also gives them a natural ending. Once the new practices have been introduced, the training delivered and the immediate objectives achieved, the initiative can reasonably be considered complete.

The capability, however, is not complete. The environment continues to change. New technologies appear. People leave. New people join. Products evolve. Business priorities shift. Practices that once worked well become less appropriate. Dependencies on neighboring capabilities change. Lessons accumulate. Organizational ability therefore continues to evolve long after the improvement project has ended.

Improvement projects change organizations.

Capability Management sustains organizational ability.

Those are different responsibilities.

What Happens After Improvement?

Organizations often recognize this problem informally. When testing becomes a recurring concern, someone eventually hears:

“You are now responsible for testing.”

The intention is sensible. Somebody should make sure the organization does not lose what it has just improved. But the statement hides a difficult question. What exactly has that person become responsible for? The testing process? Testing tools? Competence development? Communities of practice? Governance? Quality assurance? Hiring? Methodology?

Trying to answer the question by listing artifacts and activities quickly becomes problematic, because none of them is the capability itself. A capability is the organizational ability that those arrangements collectively enable.

The more useful responsibility may therefore be neither ownership of a process nor control of every specialist activity. It may be stewardship of the organizational ability.

Managing the Capability, Not Its Realization

A capability can be realized in many different ways. Practices can change. Tools can change. Organizational structures can change. Governance can become more or less formal. Responsibilities can move between teams. New technologies may make previously important activities unnecessary. If a Capability Management becomes attached too strongly to one of those realizations, it risks preserving the current solution rather than the underlying ability.

The responsibility should instead remain connected to the capability itself. What organizational ability do we need? Why do we need it? Under which conditions must it work? What evidence tells us that the ability actually exists? Where is it becoming weaker? What changes in the environment require it to evolve? What have recent experiences taught us?

Those questions operate on a longer timescale than an improvement project. They concern continuity.

A Parallel with Product Management

This begins to resemble Product Management. Product Management does not need to own every specialist discipline contributing to a product. Architecture remains architecture. Engineering remains engineering. Testing remains testing. Operations remains operations.

What Product Management provides is continuity around the product itself. It maintains the connection between why the product exists, what it needs to become, what is currently being built, what evidence returns from use and what should change next. Specialist knowledge remains distributed, but the subject does not disappear between projects.

Organizational capabilities may require something similar. Capability Management would not replace the specialists who realize the capability. It would maintain continuity around the capability while those specialists continue to contribute their expertise.

That is a different proposition from appointing someone to “own testing.” It suggests a management discipline rather than merely a role.

When Nobody Manages the Capability

The absence of such stewardship may help explain another recurring pattern. Capabilities often expand into neighboring areas. Testing begins improving requirements because poor requirements make testing difficult. Architecture becomes involved in operational concerns because architectural decisions repeatedly create operational problems. Security begins governing development practices because insecure development creates security risk.

These interventions may be entirely reasonable. Capabilities are interdependent, and specialists should influence the conditions that affect their ability to succeed.

But there is an important difference between influence and accidental ownership. Testing should be able to challenge weak requirements. That does not necessarily mean Testing should become responsible for Requirements Engineering. Security should influence development practices. That does not automatically mean Security should become the organization’s steward of software engineering.

When nobody is responsible for maintaining a capability over time, the consequences of its weakness do not remain contained. They appear elsewhere, and another capability begins compensating for the gap. The vacuum does not stay empty.

From Influence to Accidental Ownership

This distinction becomes useful because capability boundaries are rarely clean. Testing depends on requirements. Architecture depends on product direction. Security depends on engineering practices. Operations depends on architecture. Product Management depends on business analysis.

Capability Management should therefore not attempt to isolate capabilities from one another. It should make the dependencies visible and preserve appropriate responsibility across them.

One capability may legitimately influence another. It may identify weaknesses, provide evidence, recommend changes or participate in improvement. But influence should not silently become permanent stewardship simply because nobody else is holding the responsibility. Otherwise organizational capabilities can gradually absorb one another’s problems until their boundaries become difficult to understand.

Improvement Becomes Part of a Longer Lifecycle

Seen this way, capability improvement becomes one activity within a longer lifecycle. An assessment may reveal that the current capability is insufficient. Capability Management helps interpret what that means for the future. A transformation or improvement initiative may then introduce deliberate changes. Reassessment provides evidence about whether those changes actually improved the organizational ability.

But once the intervention ends, Capability Management continues. It preserves the intent, observes the realized capability, incorporates learning and determines when further development is needed.

The lifecycle therefore does not end with transformation. It continues through stewardship.

Capability Ownership as a Realization

This also changes how the idea of a Capability Owner should be understood. If Capability Management is the discipline, a Capability Owner is one possible organizational realization of it. In some organizations, one person may hold that responsibility explicitly. In others, it may be distributed across a leadership group, community or existing management role. Different capabilities may require different arrangements. The organizational design is secondary. What matters is that somebody, or some mechanism, maintains continuity of the capability.

The responsibility is not necessarily to own every process, document, specialist or decision associated with the capability. It is to ensure that the organization continues to possess and deliberately develop the required ability. That is a much more durable responsibility.

A Portfolio of Capabilities

Once individual capabilities are viewed this way, another level becomes visible. Organizations possess many capabilities. Testing, Requirements Engineering, Architecture, Security, Business Analysis, Product Management, Data Management and countless others coexist and depend on one another.

Each may be strong or weak. Each may evolve at a different pace. Each may compensate for gaps elsewhere. Each consumes investment and management attention. This begins to look less like a collection of isolated improvement disciplines and more like a portfolio of organizational capabilities.

Capability Management concerns the continuity of an individual capability while Capability Portfolio Management would ask a different question: whether the organization possesses the right capabilities, in the right relationships, for what it is trying to accomplish.

That is a broader question and deserves treatment of its own. But it reinforces the same point: capabilities are not merely things organizations improve when they become problematic. They are organizational assets that require ongoing stewardship.

Reflection

Organizations are often quite good at launching capability improvement initiatives. They are less consistent at preserving responsibility once the initiative has done its work. That may be why the same capability problems return in cycles. The intervention succeeds, but continuity remains weak.

If that is true, then the missing discipline is not another improvement method. It is the management of organizational ability between improvements.

Assessment tells us where the capability is. Transformation helps change it. Capability Management ensures that somebody continues asking where it needs to go next.

Improvement projects change organizations.

Capability Management sustains organizational ability.

Organizations rarely suffer from a complete absence of information. Especially around long-lived products, systems and capabilities, the opposite is usually true. Years of work leave behind requirements, architecture descriptions, source code, test cases, assessment reports, incident records, change requests, presentations, meeting notes, operational procedures, manuals, roadmaps and countless other artifacts. Some are current, some are obsolete, some contradict one another, and some look like little more than old junk.

Yet hidden among them may still be a surprisingly large part of the organizational understanding that people assume has already disappeared. The problem is that nobody is going to read all of it.

For a long time, that limitation shaped how we thought about organizational knowledge. If knowledge was going to be useful, somebody first had to turn it into something another person could reasonably consume. Knowledge had to become a document. The document had to be found. The document had to be read. Only then could the knowledge become useful again.

AI may be changing that sequence more fundamentally than we realize.

Knowledge Prepared for Reading

Traditional knowledge management makes considerable sense when the eventual consumer is a human reader. Suppose the useful understanding of a twenty-year-old product is scattered across thousands of requirements, test cases, architecture descriptions, incident reports, change records and pieces of source code. In theory, much of the knowledge is still there. In practice, it is inaccessible because no person can economically reconstruct it whenever a question arises.

The natural response is therefore to consolidate. Someone reads the sources, identifies what matters, resolves contradictions, creates structure and publishes the result as a specification, architecture description, product reference, handbook or some other authoritative document. That document reduces the amount of material the next person has to process. Instead of reading thousands of artifacts, the reader consumes one carefully prepared representation.

The model is essentially:

Knowledge → Publication → Reading → Understanding

This is not a bad model. It solved a real problem.

But it also created another one. Every publication became another representation that had to remain synchronized with the knowledge from which it was derived.

The Cost of Publication

The work does not stop simply because somebody has written the document. Requirements continue to change. Architecture evolves. Code changes. Incidents reveal new information. Assessments produce findings. Decisions are made in meetings. New constraints appear. Old assumptions become invalid. The publication therefore begins ageing almost immediately.

Keeping it useful requires somebody to notice relevant changes, determine how they affect the document, update the appropriate sections and ensure that the resulting representation remains internally consistent.

If several publications depend on the same underlying knowledge, the problem multiplies. The same new insight may need to appear in a product reference, an architecture description, a methodology, training material and assessment guidance.

The problem is no longer simply preserving knowledge. It is maintaining all the representations through which people are expected to consume it. That cost was difficult to avoid when publication was the necessary bridge between accumulated information and human understanding.

But what happens when the bridge is no longer always necessary?

From Reading to Asking

Imagine someone encounters a strange piece of code in a twenty-year-old system. Traditionally, the hope would be that somewhere there is documentation explaining it. Perhaps an architecture description contains the rationale. Perhaps an old requirement explains the business rule. Perhaps somebody wrote a decision record. If the right document exists, is current, can be found and contains the answer, the problem is solved.

But the explanation may never have existed in one place. The relevant evidence might instead be scattered across an old requirement, a source-control change, two regression tests, an incident report and a presentation written three years later.

A human is unlikely to discover all of those relationships. An AI-enabled knowledge environment potentially can.

The person no longer needs to ask:

Which document should I read?

They can ask:

Why does this code exist?

The system can retrieve relevant evidence from several sources and synthesize an answer for that particular question.

That is a different model of knowledge consumption. The answer did not have to be published before the question existed. The representation was created because the question existed.

The Question Becomes the Interface

This changes the role of the document. For much of organizational history, documents have served as interfaces to knowledge. Someone had to anticipate what future readers might need, decide how to organize it and create a representation that could later be consumed.

The document therefore bundled many possible future questions into one predefined structure. A person looking for one answer might have to read twenty pages because the author had to write for many readers and many possible purposes.

When knowledge can be interrogated directly, the question itself can define the representation. A Product Owner may ask what business outcomes and constraints apply to a proposed change. An architect may ask which assumptions shaped a particular design decision. An assessor may ask which quality expectations apply and what evidence supports them. A developer may ask why a seemingly unnecessary rule exists. Each question creates a different view over the same underlying body of evidence.

The prompt becomes, in effect, a temporary specification for the representation required at that moment. That does not make documents obsolete. It changes their status.

Documents Become Views

There are many situations in which a stable document remains useful. A contractual context may require a frozen specification. An assessment may need a citable baseline. Governance may require a reviewed reference. A publication may deliberately capture the state of understanding at a particular point in time. In those situations, generating and preserving a stable document makes perfect sense.

But the document no longer has to be treated as the knowledge itself. It can be understood as one representation of a larger body of knowledge, produced for a particular purpose at a particular moment.

Tomorrow, another audience may need another representation. And sometimes no publication is needed at all. Someone asks a question, receives a synthesis supported by relevant evidence, makes a decision and continues working. The organizational knowledge has been consumed without first being packaged into a document.

Reachability Becomes the Problem

Once publication is no longer the mandatory interface, the knowledge-management problem changes.

The first question is no longer:

Where should we put all our knowledge?

It becomes:

Can we reach the relevant evidence when somebody needs to understand something?

That distinction has architectural consequences. Requirements do not necessarily need to be copied into a central knowledge repository. Architecture information does not need to be moved simply because other people may need it. Code does not need to stop living in source control. Operational evidence does not need to become prose before it can contribute to organizational understanding. The sources can remain where they belong.

What matters is that the knowledge environment can reach across them. Depending on the technology, that may involve indexing, linking, retrieval, ingestion or some combination of them. The implementation can vary.

The principle remains simple:

Do not move knowledge merely to centralize it. Make it reachable.

Old Information Changes Role

This also changes how we should think about accumulated historical material. When the objective is to create one clean authoritative document, old and contradictory information looks like a problem to eliminate. Before publication, someone has to decide what is current, what is obsolete and what can safely be discarded.

A knowledge environment built around interrogation has different needs. An obsolete requirement may no longer describe what the product should do today, but it may explain why a piece of code was introduced fifteen years ago. A superseded architecture decision may reveal which trade-off originally shaped a subsystem. An old incident may explain an otherwise mysterious constraint. A test case may preserve a business rule whose original requirement has disappeared. Obsolete is not the same as worthless. Historical evidence can remain useful precisely because it is historical.

The challenge is therefore not to make every source appear equally true. It is to preserve enough provenance to interpret each source correctly. When was this recorded? What did it apply to? Was it superseded? What is authoritative today? Which other sources support or contradict it?

Without those distinctions, broad access produces confusion. With them, history becomes evidence.

Connect First, Curate Where It Matters

This raises another possibility. Traditional knowledge initiatives often begin with extensive cleanup. Thousands of artifacts must be reviewed, classified and curated before they are considered suitable for inclusion in the knowledge base. That made sense when the objective was publication. Someone had to decide what deserved to appear in the finished representation.

But if AI can inspect sources at question time, asking humans to inspect everything first may recreate exactly the economic problem AI was supposed to help solve.

It may be more useful to begin broadly. Connect the old requirements. Connect the architecture documentation. Connect the test repositories, assessment reports, change histories and incident records. Make the surviving evidence reachable, subject to appropriate security and governance.

Then allow actual questions to reveal where human curation is valuable. Some sources will rarely matter. Others will repeatedly appear in important answers. Some contradictions will prove significant enough to resolve. Some missing rationale will become visible because the available evidence cannot explain what exists.

Curation does not disappear. It becomes more targeted. Instead of deciding in advance what every future reader might need, human effort can concentrate on the areas where real questions expose uncertainty, conflict or importance.

The Knowledge Environment Must Be Able to Say “I Don’t Know”

There is an obvious danger in all of this. A system capable of synthesizing across thousands of sources can produce an explanation even when the surviving evidence does not justify one. Reachability without provenance can therefore create the illusion of understanding.

A useful knowledge environment must preserve the difference between what is explicitly recorded, what is supported by several sources, what has been reconstructed from indirect evidence, what is disputed and what remains unknown.

A plausible explanation should not quietly become historical fact merely because it sounds convincing. Sometimes the correct answer to a prompt will be that the available evidence does not explain why something exists. That is not a failure. It is knowledge about the state of organizational understanding. And it tells us where human attention may still be required.

From Knowledge Prepared for Reading to Knowledge Prepared for Questioning

This may be the deeper change. Historically, organizational knowledge had to be prepared for reading. Someone had to decide what mattered, assemble it into a coherent representation and publish it in anticipation of future need.

AI makes another model increasingly practical:

• Preserve the sources.
• Preserve their provenance.
• Preserve deliberately what cannot reliably be reconstructed.
• Make the rest reachable.
• Then allow future users to ask the questions that actually matter when they matter.

The knowledge environment no longer has to anticipate everything somebody may eventually need to read. It has to preserve enough reachable evidence that somebody can ask what they need to know.

That changes the economics of Understanding Debt as well. A twenty-year-old system may appear poorly understood not because all of its understanding has disappeared, but because the surviving pieces are fragmented across thousands of artifacts that no human could economically reconstruct.

Making those fragments reachable does not magically restore everything. Some rationale will genuinely have disappeared. Some decisions will remain ambiguous. Some evidence will contradict itself. But fragmented knowledge is no longer necessarily inaccessible knowledge.

Reflection

Perhaps we have spent too much time asking where organizational knowledge should live. That question naturally leads toward repositories, migrations, canonical documents and the difficult work of keeping them synchronized.

The more interesting question may now be how organizational knowledge should be consumed.

For a long time, the path was largely:

Knowledge → Document → Read

Increasingly, another path becomes possible:

Knowledge → Question → Synthesis

Sometimes that synthesis will become a document. Sometimes it will become a decision, an explanation, an assessment or another question.

The important change is that publication no longer has to come first. Knowledge does not necessarily need to be assembled into the representation somebody might one day need.

It needs to remain sufficiently connected, contextualized and trustworthy that the representation can be created when the need appears.

The document is no longer always the interface. Sometimes the question is.

I once worked in an organization where “DoD” had become a verb. People would ask, “Has the Product Owner DoD’ed it yet?” What they meant was whether the Product Owner had performed acceptance testing.

Nobody seemed particularly bothered by the wording. It had simply become part of the local language. At first I treated it as harmless shorthand, but the more I thought about it, the more revealing it became. Definition of Done had not merely been interpreted loosely. Its meaning had drifted far enough that the name of one practice had become attached to a different activity altogether.

The activity had survived, in name only. The original reasoning had not. That made me wonder whether this is how practices become rituals.

Practices Perform Functions

Professional practices rarely exist for their own sake. Code reviews, architecture reviews, retrospectives, readiness checks, governance forums and countless other mechanisms exist because someone believed they performed an important function within a larger system. The meeting, checklist, template or ceremony is therefore not the purpose. It is one way of realizing the purpose.

A code review may exist to reduce defects, spread knowledge, challenge design decisions or strengthen collective ownership. An architecture review may exist to expose risks before they become expensive to reverse. A retrospective may exist to create structured learning from recent experience. The visible activity matters because of what it enables.

The difficulty is that organizations often preserve activities more successfully than they preserve the reasoning behind them.

When the Why Fades

Recurring meetings remain in calendars. Templates are copied forward. Checklists stay embedded in workflows. Governance gates survive reorganizations. New employees quickly learn which steps must be followed and which approvals must be collected.

The rationale is more fragile. Over time, people may become very good at performing a practice while becoming increasingly uncertain about what the practice is supposed to achieve. Eventually the organization no longer asks what outcome the activity is intended to create. It asks whether the activity has been completed. That is when a practice begins to resemble a ritual.

This does not necessarily mean that the ritual has become useless. It may still perform its original function reasonably well. A weekly meeting may continue to coordinate work. A review may still expose important risks. A checklist may still prevent mistakes. The problem is subtler: the organization no longer knows with confidence why the practice works, what part of it matters, or what would happen if it changed.

Rituals Can Look Healthy

This can make ritualization surprisingly difficult to detect. A ritualized practice may look perfectly healthy from the outside. The meeting happens every week. The checklist is completed. The approval is recorded. The template is filled in correctly. Compliance can remain high even while understanding becomes weak. The organization becomes good at doing something it can no longer explain.

And once that happens, the continued existence of the practice can begin to justify itself. We do this because this is what we do. The realization becomes its own reference. Eventually frustration appears, and the discussion often moves directly to removal.

Do we still need this meeting?

Can we simplify this checklist?

Can we eliminate this approval?

Can we automate this gate?

Those may all be reasonable questions, but they begin one step too late.

Recover the Function

Before deciding what to do with a practice, we need to understand what function it was intended to perform.

Perhaps the function remains important and the current practice still performs it well. Perhaps the function remains important but the practice has become a poor way of realizing it. Perhaps several practices now duplicate the same function. Perhaps another mechanism has made the original practice unnecessary. Or perhaps the function itself no longer matters.

These are very different situations. They cannot be distinguished by looking only at the visible activity.

This matters because organizational evolution does not require preserving practices unchanged. Quite the opposite. A practice may need to change considerably in order for its underlying function to remain healthy.

Evolution Does Not Mean Preservation

A review meeting might become asynchronous. A checklist might become automated evidence. A central governance forum might be replaced by distributed decision-making. A formal approval might disappear because the confidence it once created is now produced continuously through better controls.

If the important function survives, the organization may have evolved successfully even though the original practice has disappeared. Preserving the activity is therefore not the same as preserving what matters.

The opposite problem also occurs. Organizations sometimes retain practices long after their function has ceased to be relevant. The meeting remains because cancelling a recurring meeting feels more consequential than letting it continue. The report survives because someone might still need it. The approval stays in place because nobody is quite certain what would happen without it.

Practices accumulate much like old systems. Each one may once have had a perfectly good reason to exist. Over time, the artifact survives more easily than the understanding behind it. Eventually the organization inherits a landscape of ceremonies whose origins are difficult to reconstruct.

But the loss of rationale can also push in the other direction. A practice whose function is no longer understood can appear pointless precisely because the organization has forgotten what value it once created.

People see the meeting but not the coordination it enabled. They see the review but not the risk it was intended to expose. They see the documentation but not the decisions it helped preserve. A practice may therefore be preserved for the wrong reason or removed for the wrong reason. In both cases, the deeper problem is the same: the organization no longer understands the function well enough to make a deliberate choice.

From Practice to Realization

This suggests a simple principle. Before changing a practice, recover the function.

What problem was it intended to solve? What risk was it meant to control? What understanding was it supposed to create? What decision did it support? What evidence did it produce? What coordination did it make possible?

Once those questions can be answered, the organization has choices.

The practice may remain.

It may change.

It may be replaced.

It may disappear.

What matters is that the decision concerns the function rather than merely the artifact.

Seen this way, a practice is one realization of an organizational need. The need describes what the organization must somehow accomplish. The practice describes one way of accomplishing it.

That distinction makes deliberate evolution possible. If the practice is confused with the function, any change to the practice can appear threatening because it seems to endanger the need itself. If the two remain distinct, the organization can experiment with different realizations while preserving what actually matters.

A Continuity Problem

This is also why the problem belongs naturally to Continuity.

When a practice becomes ritualized, the organization has preserved the visible artifact of an earlier decision while losing part of the understanding that made the decision meaningful.

The meeting survived.

The checklist survived.

The approval survived.

The process survived.

The why did not.

Once that happens, the organization may still change the practice, but change becomes guesswork. It may still retain the practice, but retention becomes habit. It may still remove the practice, but removal becomes an experiment whose consequences are difficult to predict.

Continuity therefore does not mean preserving practices. It means preserving enough understanding to know what may safely change.

Reflection

Perhaps practices do not become rituals because people stop following them. Perhaps they become rituals when people continue following them after the reasoning behind them has faded. The activity remains visible, familiar and repeatable. The function becomes harder to articulate. Eventually someone asks the deceptively simple question:

Why are we doing this?

That question should not automatically be treated as evidence that the practice is useless. It may instead be evidence that something more important has already been lost.

The practice can always be changed. The harder task is preserving enough understanding to know what the change must not accidentally destroy.