Blog

In The Death of the Document?, I explored a simple possibility: perhaps documents are no longer always necessary as the primary way in which knowledge is transferred.

Traditionally, a document has to be created before somebody knows exactly what they will want from it. An author decides what matters, how the material should be structured, how much detail should be included and in which order it should be presented. The reader then works through that predefined representation in order to extract whatever understanding is relevant to the question they actually have.

The sequence is familiar:

Knowledge → Publication → Reading → Understanding

AI makes another sequence possible:

Knowledge → Question → Synthesis

The answer no longer necessarily has to be published before the question exists. A representation can be created because somebody asks for it.

At first, this appears to be a question about documents. But once the idea is taken seriously, the same pattern starts appearing elsewhere.

A Dashboard Is Also a Predefined Answer

Consider a dashboard. A dashboard is an attempt to anticipate future questions. Someone decides that users will probably want to know how much was sold today, whether sales are rising or falling, which regions are underperforming, how margins are developing, and perhaps a dozen other things. Measures are selected, charts are designed, filters are added and drill-down paths are created. If the resulting dashboard cannot answer a particular question, somebody may eventually build a custom report. All of this happens before the user actually asks anything.

Now imagine that the user can simply say:

How much did we sell today?

The system answers.

Why is that lower than yesterday?

It investigates.

Is Sweden causing it?

It investigates again.

Then what is causing it?

The next answer is synthesized from whatever data is relevant.

The important change is not merely that the dashboard has become easier to use. The sequence of questions no longer has to be designed in advance. Each new question can emerge naturally from the answer to the previous one.

In some situations, that makes the predefined dashboard unnecessary.

Sometimes the Right Answer Is “Show Me”

Of course, not every answer is best expressed in words.

Sometimes an explanation immediately creates a different need:

Show me.

Show me the sales trend.

Show me where the customers are.

Show me what changed.

Show me how these components interact.

Show me the evidence behind that conclusion.

At that point, the system can create or retrieve a visualization appropriate to that particular question.

The visualization still matters. What changes is that it no longer has to exist permanently because somebody once imagined it might be useful. It can be created at the moment it becomes useful.

The same underlying information can also be consumed differently depending on the situation. Someone sitting at a desk may want a detailed written explanation. Someone preparing for a management meeting may want a few diagrams. Someone driving may simply want to talk. Someone investigating a difficult problem may move continuously between forms:

Tell me what is happening.

Why?

Show me.

Show me the evidence.

Explain that part.

The knowledge remains the same. The representation changes with the need.

This suggests that documents, dashboards, reports, presentations and visualizations may increasingly become temporary views over more durable knowledge and data.

The Command Prompt Returns

There is an interesting historical irony here.

The command line allowed users to tell computers what they wanted, but only if they knew how to speak the computer’s language. Commands, parameters, paths and syntax had to be learned.

Graphical interfaces made computers easier to use by reversing the relationship. Instead of requiring users to know the command, the computer exposed possible actions through menus, buttons, forms, folders, dashboards and navigation structures.

AI seems to bring us strangely close to the command prompt again. The user can once more simply express intent:

How much did we sell today?

What do we know about this customer?

Why was this architecture chosen?

What changed overnight?

Show me the trend.

The difference is that the command language is now ordinary human language.

The user does not necessarily have to know which application contains the answer, which report to open, which dashboard to inspect or which sequence of operations will produce the result. The system can determine which sources, calculations and representations are required.

The command prompt has returned. It just learned to speak human.

When the System Asks for Our Attention

There is another step beyond this. Sometimes the user should not have to ask at all. A dashboard assumes that somebody will look at it frequently enough to notice when something important changes. An intelligent agent can continuously interpret the underlying information instead.

Rather than displaying a graph and waiting for a human to notice an undesirable trend, it can say:

You may want to look at this.

Or, less formally:

Psst. You have a problem.

The human can then ask why.

The system explains.

Show me.

A visualization appears.

What changed?

The relevant history is retrieved and synthesized. The dashboard has not disappeared completely. It has become an on-demand representation inside a conversation. What used to be a permanent interface becomes something that materializes only when it helps us understand the situation.

What Should Actually Be Permanent?

This leads to a more fundamental question.

What actually needs to be durable?

We currently spend considerable effort maintaining representations. Documents have to be updated. Dashboards have to be redesigned. Reports have to remain current. Presentations are recreated. Diagrams gradually become obsolete. Interfaces are maintained because somebody may need to navigate through them in the future. Perhaps these are increasingly the wrong things to make permanent.

What needs to remain durable is the material from which trustworthy representations can be produced: knowledge, data, evidence, sources, provenance, decisions, assumptions, relationships and expectations.

Above that durable layer, representations can increasingly be generated according to the need of the moment. A document when a document is useful. A chart when a chart is useful. A spoken explanation when somebody wants to listen. A dashboard when somebody wants an overview. A detailed evidence trail when somebody wants to challenge a conclusion.

The representation can be generated, consumed and discarded. The knowledge remains.

The Death of the Predefined Representation?

This does not mean that documents will disappear. Nor will dashboards, reports, presentations, diagrams or graphical interfaces. We may actually create more of them than ever.

What may disappear is the assumption that these representations have to be designed, published and maintained before we know what somebody actually wants to know.

Instead, the sequence becomes:

Knowledge and data → Intent → Representation

The representation is created at the moment of need, for the person who needs it, for the question they are actually asking and in the form most appropriate to the situation. Read it. Listen to it. Look at it. Interact with it. Then ask the next question.

Perhaps the document was only the first thing we noticed becoming ephemeral. The more fundamental change may be the death of the predefined representation.

Understanding debt accumulates when the reasons behind a product gradually disappear. Requirements remain. Architecture remains. Test cases remain. Backlogs remain. Decisions may be scattered across meeting notes, presentations, emails, issue trackers, source repositories and documentation. The artifacts survive, but the understanding that connects them becomes increasingly difficult to reconstruct.

The conventional response is to organize the information. Inventory the documentation. Classify it. Clean it. Standardize formats. Define a taxonomy. Migrate information into appropriate repositories. Establish ownership and maintenance processes. This is sensible.

It is also a considerable undertaking, which may explain why understanding debt is so rarely addressed systematically.

There may be a more pragmatic starting point.

Make Everything Accessible

Suppose all surviving artifacts concerning a product are made accessible within a single knowledge environment. They do not necessarily have to be moved into one physical repository. They may remain in document management systems, issue trackers, source repositories and other locations, provided that they can be accessed together. Their formats do not have to be standardized either.

The important requirement is simpler:

AI must be able to reach them, interpret them and identify their provenance.

The resulting knowledge environment may initially be messy. That may be good enough.

Instead of asking a person to navigate the information structure, we can ask the question we actually want answered.

Why was this architecture chosen?

Why does the product behave this way?

Why does this requirement exist?

What problem was this feature intended to solve?

Why was this alternative rejected?

AI can search across the available artifacts and synthesize an answer from whatever relevant information survived. The person no longer has to know where the answer lives.

The White Gaps

Making existing information accessible does not recover understanding that was never recorded. This is not a reason for the approach to fail. It may be one of its greatest benefits.

When asked a question, AI may discover several different situations. The answer may be explicitly supported by available sources. The answer may not be stated explicitly but may be reasonably reconstructed from several sources. Available sources may contradict each other. Or there may simply be insufficient information to answer the question. These are different states of organizational understanding.

AI should distinguish between them. An educated guess can be useful, but it must remain an educated guess. If available evidence suggests a likely explanation, AI can present that explanation as a hypothesis together with the evidence from which it was inferred.

It should also be able to say:

I don’t know.

The unanswered question reveals a white gap in the knowledge body. That gap is itself valuable information.

Let Questions Reveal the Debt

Understanding debt therefore does not have to be identified through a comprehensive documentation program. It can reveal itself through use.

Someone asks why a component has a particular constraint. AI cannot establish the reason from the available information. It finds some indications that performance may have been involved, but confidence is low. An experienced engineer remembers that the real reason was compatibility with a customer’s legacy interface. Perhaps that recollection leads to an old procurement specification that confirms it. Perhaps no documentary evidence survives.

Either way, the organization has learned something about the state of its understanding. The answer, its source and the remaining uncertainty can now be preserved. The next person who asks the question starts from a better position.

A simple learning cycle emerges:

Question → Synthesis → Gap → Investigation → Understanding → Capture

The knowledge body improves because people use it.

From Retrieval to Continuity

This suggests two related but different objectives.

The first is recoverability.

Make surviving organizational information accessible so that AI can reconstruct as much existing understanding as possible.

The second is continuity.

When questions expose missing, uncertain or conflicting understanding, investigate where worthwhile and preserve what is learned. Over time, the knowledge environment becomes more than a searchable collection of artifacts. It becomes a living body of organizational knowledge.

AI then performs a role beyond enterprise search. It helps the organization distinguish between what it knows, what it can infer, what it disagrees with itself about, and what it no longer knows.

The white gaps become a map of understanding debt.

Start With the Mess

There will still be reasons to improve documentation, establish authoritative sources, manage provenance and confidence, remove obsolete material, protect sensitive information and structure important knowledge explicitly.

But these activities do not necessarily have to precede useful knowledge recovery. A pragmatic first step may be much simpler:

Make the surviving knowledge accessible.

Then ask questions. Let AI synthesize what can be synthesized. Let it identify what cannot. Use real questions to discover which missing understanding actually matters. And preserve the answers as they emerge.

Instead of first organizing the mess so that people can search it, perhaps we should begin by making the mess interrogable.

A subject can be understood on its own. It has a purpose, characteristics, qualities and constraints that explain what it is and why it exists. Once several subjects are deliberately brought together into a portfolio, however, another subject appears: the portfolio itself.

The portfolio has its own purpose. This changes how its constituents should be understood.

Consider a collection of watches. A Victorinox I.N.O.X. can be understood and appreciated independently. It may be robust, mechanical, architectural and versatile. A Seiko Presage can likewise be understood independently, with an emphasis on elegance, refinement and dial design.

But once both watches belong to the same collection, another question becomes relevant. It is no longer sufficient to ask:

Why does this watch exist?

We must also ask:

Why is this watch in this collection?

These are different questions.

The distinction does not depend on the constituents being watches, or even products. It arises whenever independently meaningful subjects are deliberately brought together into a portfolio.

The portfolio has an intent of its own

A watch collection might exist to cover its owner’s relevant use cases while providing distinctly different experiences. In such a portfolio, the I.N.O.X. and Presage have different reasons for belonging. The I.N.O.X. contributes robustness, architectural character and everyday versatility. The Presage contributes refinement, restraint and a dressier personality.

Neither needs to be better than the other. In fact, making them increasingly similar could make the portfolio worse.

The same effect can be seen with bicycles. A road-oriented Giant Defy and a Trek Dual Sport can be deliberately optimized for different practical situations. Improving one does not mean making it resemble the other. If both gradually converge on the same compromise between road speed and mixed-surface versatility, each bicycle might remain individually excellent while the reason for owning both becomes weaker.

A portfolio of individually good constituents is therefore not necessarily a good portfolio.

The intent of the whole introduces criteria that do not exist when the constituents are considered separately.

The WHY of a constituent has two perspectives

A constituent of a portfolio can consequently be considered from two perspectives.

The first concerns the subject itself:

Why does this subject exist?

The second concerns its membership of the portfolio:

Why is this subject here?

The second WHY derives from the intent of the portfolio.

This distinction becomes particularly clear in a model train collection. Each locomotive, carriage or train can be described independently: what real rolling stock it represents, when that rolling stock existed, how the model represents it and what characteristics make the model interesting.

But a particular collection might have a very different purpose: preserving the memory of the rolling stock someone remembers from childhood.

That purpose changes the meaning of individual acquisitions. An exceptionally detailed model of a locomotive that was never part of that remembered environment might be an excellent model but a poor addition to the collection. A less sophisticated model of a familiar train might contribute much more strongly to the purpose of the portfolio.

The quality of the constituent and the quality of its contribution are therefore different judgments.

Portfolio intent gives meaning to constituent roles

This suggests a relationship between portfolio intent and constituent intent:

Portfolio intent → required contributions → constituent roles → constituent intent

The portfolio intent explains what the portfolio as a whole is intended to accomplish. From this follow the contributions that are needed from its constituents. Those contributions establish roles within the portfolio. A particular subject can then be selected, developed or configured to fulfil such a role.

This does not mean that a constituent has no independent purpose. A bicycle remains a bicycle, a watch remains a watch, and a capability remains a capability. Rather, membership of a portfolio gives the constituent an additional context in which its purpose must be understood.

The WHY of the constituent should therefore align with the WHY of the portfolio.

This alignment also explains why optimization at constituent level can conflict with optimization at portfolio level.

Suppose a Dual Sport is changed to become increasingly effective on paved roads. Considered independently, some of those changes may be improvements. But if the portfolio already contains a Defy optimized for that purpose, the changes may increase overlap and reduce the range of situations covered by the bicycle portfolio.

Likewise, making an elegant Presage tougher, sportier and more universally versatile might improve certain characteristics of the watch in isolation while simultaneously moving it toward the role already occupied by an I.N.O.X.

A constituent should therefore not necessarily be optimized toward some universal conception of the best possible subject. It should be developed with regard to the contribution it is intended to make.

Redundancy is a portfolio question

This also changes how overlap should be interpreted.

Overlap is not inherently undesirable. Some portfolios may deliberately require redundancy, resilience, interchangeability or multiple alternatives. But where the intent of the portfolio is to provide coverage or diversity, unnecessary overlap consumes resources without adding a corresponding contribution.

This explains a familiar phenomenon in collections based on an upgrade hierarchy.

Someone might first buy an affordable watch, later buy a more expensive watch with essentially the same personality and use cases, and eventually replace that with an even more prestigious version. Each acquisition may represent an improvement when the watches are compared directly. Yet the previous watch increasingly remains unworn because the new constituent has taken over its role.

The portfolio has not gained another meaningful option. One constituent has effectively displaced another.

By contrast, adding a watch with a distinctly different purpose or personality increases the range of meaningful choices available without making the existing watch obsolete.

A useful portfolio principle follows:

A new constituent should add a meaningful contribution to the portfolio, not merely improve the ranking among existing constituents.

Whether that means maximizing diversity, providing redundancy, filling a gap, increasing resilience or serving some other purpose depends on the intent of the particular portfolio.

A portfolio is itself a subject

Once the portfolio is recognized as having an intent of its own, it can also be treated as a subject in its own right.

It can be understood.

It can be deliberately developed.

And it can be assessed.

Its reference cannot simply be the sum of the references of its constituents.

A portfolio reference must describe what the portfolio as a whole is intended to accomplish: the contributions required from its constituents, important distinctions or relationships between their roles, relevant constraints, desired coverage or redundancy, and principles governing addition, development, replacement or removal.

This creates references at two related levels.

At the constituent level, a reference describes what the individual subject is intended to be.

At the portfolio level, a reference describes what the portfolio is intended to accomplish through its constituents.

The two references are related because the intended contribution of the constituent derives partly from the intent of the portfolio.

The portfolio therefore provides context for understanding the constituent without replacing the constituent’s own reference.

Assessment also occurs at two levels

The distinction produces two different assessment questions.

At constituent level:

How well does this subject realize its own intent?

At portfolio level:

How well does this constituent make its intended contribution, and how well does the portfolio as a whole realize its intent?

These assessments can produce different answers.

Every individual constituent in a portfolio may be excellent while the portfolio has excessive overlap, important gaps or constituents that contribute little to its purpose.

Conversely, a constituent that would not rank highest when assessed independently may be precisely the constituent that makes the portfolio better because it provides a contribution that would otherwise be missing.

This means that assessment of a portfolio cannot be reduced to aggregation of constituent assessments.

A portfolio containing five individually excellent subjects is not necessarily better than a portfolio containing four. Nor does improving the assessment result of every constituent necessarily improve the portfolio.

The reference for the portfolio determines what improvement means at portfolio level.

From product portfolios to portfolios of subjects

Nothing in this reasoning requires the constituents to be physical products.

The same structure can apply wherever independently meaningful subjects are deliberately managed together.

A product portfolio consists of products.

A service portfolio consists of services.

A project portfolio consists of projects.

An application portfolio consists of applications.

A capability portfolio consists of capabilities.

The nature of the required contributions will differ, but the underlying relationship remains:

Portfolio intent → required contributions → constituent roles → constituent intent

The portfolio is therefore not merely a convenient grouping or administrative container. When the grouping is intentional, the portfolio itself becomes a meaningful subject whose intent provides context for decisions about its constituents.

The implication for capability portfolios

This has a particularly interesting consequence for capability development.

An organizational capability can be understood, developed and assessed as a subject in its own right. A reference for that capability can describe what the capability is intended to accomplish and the characteristics necessary to do so.

But capabilities do not exist merely to achieve high assessment scores. They exist to contribute to what the organization is trying to accomplish.

Once capabilities are considered as constituents of a capability portfolio, their development can therefore no longer be determined solely by deficiencies found in individual capability assessments.

A capability assessed at a relatively low level might already be sufficient for the contribution expected from it. Developing it further could consume substantial resources while adding little value to the portfolio.

Another capability might appear reasonably strong when considered independently but be inadequate for a contribution that is critical to the portfolio.

The relevant question is therefore not simply:

How can we improve this capability?

It must also be:

What contribution does the organization require from this capability, and how should it be developed to make that contribution?

This provides a possible foundation for capability portfolio management as a discipline.

Business intent gives meaning to the capability portfolio. Portfolio intent establishes the contributions required from its constituent capabilities. Those contributions give context to the intent and reference of each capability. Capability development can then be directed toward what the organization actually requires rather than toward generic improvement or maturity for its own sake.

The resulting chain is:

Business intent → portfolio intent → required contributions → capability intent → capability reference → capability development

Assessment and learning can operate at both capability and portfolio level, providing feedback into subsequent development.

From individual quality to contribution

A subject can be valuable in its own right and still be the wrong constituent for a particular portfolio.

Likewise, a constituent that would not rank highest independently can be exceptionally valuable because of the contribution it makes to the whole.

This changes the fundamental question.

It is not sufficient to ask:

How good is this subject?

We must also ask:

Why is it here, and what is it supposed to contribute?

A portfolio is therefore more than a collection of individually valuable subjects. It is itself a subject with an intent, and that intent gives meaning to the contribution expected from each constituent.

The WHY of the portfolio gives context to the WHY of its constituents.

How do we approach capability development in an Agile product development organization? I first started thinking about this question during an assessment.

Agile product development teams are deliberately given a high degree of autonomy. They are expected to organize their own work, use their professional expertise and continuously improve how they work. Different teams operate in different contexts and may therefore develop different practices.

That creates an interesting problem. Suppose an assessment shows that an organizational capability needs to improve. Perhaps teams need to become better at identifying product-quality risks. Perhaps requirements need to become clearer before implementation. Perhaps testing needs to provide useful evidence earlier. Perhaps teams need to become better at learning from production.

How should the organization make that happen?

We could define a better process and ask every team to implement it. But then we are no longer developing a capability. We are prescribing its realization.

At the other extreme, we could simply tell autonomous teams to improve. But if the capability matters at organizational level, leaving its development entirely to independent local initiatives provides little direction or continuity.

There seems to be a tension between deliberate capability development and team autonomy. Perhaps Agile product development itself provides a way through it.

What If We Developed Capabilities Like Products?

Agile teams already work within a similar tension.

A Product Owner or Product Manager can determine that something about the product needs to change without prescribing exactly how developers should implement that change.

A Product Backlog makes those required changes visible and allows them to be prioritized.

The development team then determines how to realize them.

What if capability development worked in much the same way?

A Capability Owner could maintain a Capability Backlog.

A Capability Backlog Item could describe a required change in organizational ability.

For example:

Teams can identify significant product-quality risks early enough to influence development.

The Capability Owner can decide that this ability matters and prioritize its development.

But the backlog item does not say:

Introduce mandatory product-risk workshops.

Nor:

Train every team in method X.

Nor:

Implement tool Y.

Those are possible ways of realizing the required capability.

They are interventions.

The Capability Backlog Item describes what the organization needs to become capable of doing. The people developing the capability determine how to make that ability real.

Perhaps capabilities themselves could be developed using Agile principles.

From Implementation to Intervention

The parallel with product development is surprisingly direct.

A Product Backlog Item describes a required product change. Developers determine how to implement it.

A Capability Backlog Item describes a required capability change. Teams determine how to intervene in their existing way of working to realize it.

The relationship becomes:

Product Backlog Item → Implementation → Product Increment

and:

Capability Backlog Item → Intervention → Capability Increment

This distinction is important.

Suppose teams need to become better at identifying significant product-quality risks.

One team may introduce collaborative risk analysis during refinement.

Another may change how testers and Product Owners work together.

Another may introduce examples, modelling or lightweight risk classification.

Another may discover that its existing practices are sufficient with a relatively small change.

The interventions can differ because the teams and their contexts differ.

What should remain common is the required organizational ability.

This allows capability development to provide direction without unnecessarily standardizing how autonomous teams work.

The Capability Reference Model

But how does the Capability Owner know what belongs in the Capability Backlog?

A backlog alone cannot provide the answer.

There first needs to be an explicit understanding of the capability itself.

A Capability Reference Model can describe the significant organizational abilities, expectations and conditions associated with the capability.

Assessment then compares the realized capability with that reference.

Perhaps the reference says that teams should be able to identify significant product-quality risks early enough to influence development.

Assessment shows that several teams cannot reliably do this.

That creates a development need.

The need can become a Capability Backlog Item and be prioritized against other capability-development needs.

This gives the reference model and backlog different purposes:

The Capability Reference Model describes what good means.

The Capability Backlog describes what we believe should change next.

The reference provides continuity.

The backlog provides focus.

The Capability Increment

Once a Capability Backlog Item has been prioritized, a team can take it into development.

Suppose the item says:

Teams can use identified product-quality risks to prioritize testing effort.

The team explores why it cannot reliably do this today.

Perhaps risk information arrives too late. Perhaps business impact is poorly understood. Perhaps testing is planned before risks have been discussed. Perhaps the team lacks experience with risk analysis.

The team then chooses interventions appropriate to its situation.

It might change refinement.

It might experiment with risk workshops.

It might seek coaching.

It might change collaboration between Product Management and Testing.

It might introduce supporting tools.

Those interventions are analogous to implementation decisions in product development.

But what is the resulting increment?

It is not the workshop.

It is not the training.

It is not the tool.

The increment is the change in organizational ability.

Before the sprint, the team could not reliably use product-quality risks to prioritize testing.

After development, it should be able to.

That is the capability increment.

Done Means Capable

This has an important consequence for the Definition of Done.

Suppose the team planned three interventions:

• conduct training;
• introduce a risk model;
• use it during refinement.

At the end of the sprint, all three activities have been completed.

Is the Capability Backlog Item Done?

Not necessarily.

Completing the interventions demonstrates that development work occurred.

It does not demonstrate that the capability increment exists.

The relevant question is:

Can the team now do what the Capability Backlog Item says it should be able to do?

That requires evidence.

The team might demonstrate the ability using real product work. It might be observable during refinement. A simulation might sometimes provide sufficient evidence. Other capabilities may require operational evidence over a longer period.

The form of evidence will vary.

The principle does not.

A Capability Backlog Item is not Done because its interventions were completed. It is Done when there is sufficient evidence that the required capability has been realized.

In other words:

Done means capable.

Reassessment Becomes Part of Development

Capability assessment is often treated as something that happens before an improvement initiative and perhaps again much later.

Agile capability development suggests something more continuous.

Assessment identifies a capability-development need.

That need enters the Capability Backlog.

A team develops a capability increment through interventions.

Evidence is collected.

The resulting capability is reassessed against the relevant part of the Capability Reference Model.

The cycle becomes:

Reference → Assess → Prioritize → Develop → Intervene → Reassess → Learn

If the required ability exists, the Capability Backlog Item may be Done.

If it does not, the interventions may have failed or been insufficient.

That is not necessarily wasted work. It is learning.

The team may try another intervention. The Capability Owner may reconsider the backlog item. The assessment may reveal another underlying weakness. In some cases, experience may even challenge the Capability Reference Model itself.

Capability development becomes iterative.

Autonomy Without Abandoning Direction

This may resolve the tension that started the question.

Team autonomy does not have to mean that organizational capability development is left entirely to local initiative.

And organizational capability development does not have to mean prescribing one standardized way of working.

The organization can establish:

what ability is needed,

while autonomous teams retain substantial freedom over:

how that ability is realized.

Assessment closes the loop.

Teams are not judged primarily on whether they adopted the prescribed practice. They are assessed on whether the required capability exists.

Two teams may therefore realize the same capability differently.

That is not necessarily inconsistency.

If both realizations satisfy the relevant capability expectations, it may simply be autonomy working as intended.

The reference provides coherence without requiring uniform implementation.

When Capability Development Crosses Team Boundaries

Not every capability can be developed by one team acting independently.

Capabilities interact.

Product Management affects Requirements Engineering. Requirements Engineering affects Testing. Architecture affects Engineering and Release Management. Operations provides evidence that influences several of them.

An intervention may therefore contribute to several capability changes at once.

Collaborative product-risk analysis, for example, might strengthen Product Management’s ability to make quality expectations explicit, Requirements Engineering’s ability to identify significant conditions and Testing’s ability to focus evidence on important risks.

Likewise, one capability change may require several coordinated interventions.

This is where broader organizational development becomes necessary.

Transformation as Orchestrated Intervention

A transformation program can be viewed from this perspective as a temporary mechanism for orchestrating interventions across multiple capabilities.

Consider adopting SAFe.

The visible transformation introduces roles, events, structures, backlogs, planning mechanisms and governance arrangements.

Those are interventions.

Behind them are organizational capabilities that the transformation is intended to strengthen: Portfolio Management, Product Management, Architecture, Requirements Engineering, Engineering, Testing, Release Management, cross-team coordination and others.

The important question is therefore not simply:

Did we successfully implement SAFe?

It is:

Did the capabilities we intended to improve actually improve?

PI Planning may have been implemented perfectly while cross-team coordination remains weak.

Product Management roles may have been appointed while product direction remains fragmented.

New testing practices may have been introduced while the organization remains unable to provide timely evidence about product quality.

The interventions can be successfully implemented while the capability development fails.

This is why the intervention should not become the reference against which improvement is judged.

Capability Stewardship Continues

Transformation programs are temporary.

Capabilities are not.

A transformation may accelerate development across many capabilities and coordinate interventions that would otherwise be difficult to perform.

Eventually the program ends.

The Capability Reference Model remains.

The Capability Backlog remains.

New evidence appears.

The environment changes.

New weaknesses emerge.

The capability continues to develop.

The Capability Owner therefore provides continuity beyond any particular intervention or transformation.

The role is not to own every practice used to realize the capability.

It is to steward the capability itself: maintain its reference, understand its current state, prioritize what needs to change, and ensure that development and reassessment continue.

Reflection

The original problem seemed to be about autonomy.

How can an organization deliberately improve ways of working when Agile teams are supposed to determine for themselves how they work?

Perhaps the problem appears because we confuse the capability with its realization.

The organization does not necessarily need to prescribe the practice.

It needs to make the required ability explicit.

A Capability Reference Model can describe that ability.

Assessment can show where the realized capability is insufficient.

A Capability Owner can prioritize the required changes through a Capability Backlog.

Autonomous teams can discover suitable interventions.

Reassessment can determine whether those interventions actually produced the required capability increment.

That is remarkably similar to the way we already develop products.

Perhaps capabilities themselves could be developed using Agile principles.

For many years I have encountered organizational disciplines named after what they manage:

• Product Management
• Capability Management
• Portfolio Management
• Service Management
• Risk Management
• Workforce Management

The naming convention appears natural. Organizations contain subjects, and those subjects require management.

But I increasingly wonder whether management is the most fundamental concept.

A Pattern

In Product Continuity, an important distinction emerged between the product, its current realization and the understanding required to continue reasoning about the product over time.

The same distinction later emerged for capabilities. A capability is not a process. It is not a role. It is not a tool. It is not an organizational structure.These are realizations. The capability itself is something more enduring.

The question then became:

What understanding must be preserved so that the capability can continue to be developed and assessed?

The same question appears equally relevant for products. Over time it became apparent that the problem was not primarily one of management. It was a problem of continuity.

Testing the Pattern

An interesting way to evaluate a theory is to apply it to subjects outside its original domain. Products and capabilities may be special cases. If so, the underlying pattern should fail when applied elsewhere. So let us try.

Governance

Organizations preserve governance structures remarkably well. Steering committees survive. Approval procedures survive. Policies survive. Yet organizations frequently lose understanding of:

• why decisions were made,
• what assumptions informed them,
• what trade-offs were accepted,
• which objectives they were intended to serve.

The governance remains. The understanding does not. This suggests that governance, like products and capabilities, may have a continuity problem.

Leadership

Leadership transitions provide a similar example. Many organizations speak of succession planning. Yet succession often focuses on replacing individuals. The more important challenge may be preserving understanding. When a leader leaves, what disappears?

• Assumptions
• Relationships
• Decision rationale
• Strategies
• Historical context

Perhaps successful succession is not the transfer of responsibility. Perhaps it is the transfer of understanding.

People

The same pattern appears at the individual level. Organizations maintain personnel records. They maintain performance reviews. They maintain competence matrices. Yet managers are frequently dependent on personal knowledge of employees. When a manager changes, much understanding is often lost.

The employee remains. The understanding does not. Again, the pattern appears.

A Different View of Management

Traditional management tends to focus on planning, organizing, controlling and coordinating. These activities are necessary.

But they may not represent the deeper responsibility. Suppose an individual inherits responsibility for:

• a product,
• a capability,
• a portfolio,
• a governance model,
• an employee.

The first question should perhaps not be:

How do I manage this?

The first question may instead be:

What understanding am I responsible for preserving and evolving?

That question feels different. It introduces a longer time horizon. It introduces responsibility beyond current delivery. It introduces responsibility beyond one’s own tenure.

Stewardship

The concept of stewardship appears increasingly useful. Management often implies control. Stewardship implies care. Management often assumes ownership. Stewardship assumes temporary responsibility. A steward inherits something, maintains it and improves it. And leaves it in a condition that allows future stewards to continue.

This appears remarkably consistent with the principles of continuity.

Subject Stewardship

If this line of reasoning is correct, many disciplines may be reframed:

A Product Steward becomes responsible for preserving and evolving understanding of a product.

A Capability Steward becomes responsible for preserving and evolving understanding of an organizational capability.

A Governance Steward becomes responsible for preserving and evolving understanding of organizational decision-making.

A People Steward becomes responsible for preserving and evolving understanding of human capability and potential.

The subject changes. The responsibility remains surprisingly similar.

Portfolio Stewardship

The pattern may extend even further. Management disciplines typically address individual subjects. Organizations, however, rarely contain only one subject. They contain portfolios.

Products exist in product portfolios. Capabilities exist in capability portfolios. People exist in talent portfolios. A portfolio is not merely a collection. It is a network of relationships, dependencies, priorities and trade-offs.

Consequently, portfolios may require their own stewardship. Not stewardship of the individual elements. Stewardship of the understanding that connects them.

A Candidate Theory

The recurring pattern can be expressed as follows:

Every important organizational subject appears to require:

1. A reference through which it is understood.
2. Development through which it is intentionally changed.
3. Assessment through which it is understood in its current state.
4. Stewardship through which understanding is preserved and evolved.
5. Continuity through which future development and assessment remain possible.

Products appear to follow this pattern.

Capabilities appear to follow this pattern.

Governance appears to follow this pattern.

Leadership appears to follow this pattern.

People appear to follow this pattern.

Portfolios appear to follow this pattern.

If the pattern continues to hold across domains, then Product Continuity and Capability Continuity may not be the destination. They may be early examples of a more general discipline.

A Final Reflection

Many organizations appear to assume that their most valuable assets are products, systems, capabilities, people, processes and data. Perhaps these are not the primary assets.

Perhaps the primary asset is the shared understanding that allows those things to be developed, assessed, governed and evolved over time.

If so, then management may not be the deepest responsibility. Stewardship may be. And continuity may be the measure by which stewardship is ultimately judged.