Blog

There is a recursive quality to the question why that I find fascinating.

Suppose we are automating regression testing. Why are we doing that? Perhaps because we want confidence that changes have not broken existing behavior. But that answer can itself become the subject of the next question. Why do we need that confidence? Perhaps because we want to release changes without creating unacceptable risk. Why do we want to do that? Perhaps because the product needs to respond quickly to changing needs.

Something interesting happens as we move through these questions. The answer to why at one level becomes the what at the level above it.

Automated regression testing is a What whose Why is confidence in changes. Confidence in changes is then itself a What whose Why is the ability to release safely. The ability to release safely becomes another What, connected to another Why.

The Why of one layer is the What of the layer above it.

This suggests that Why is not simply an explanation attached to something. It is a connection between levels. The higher level gives purpose to the level below it, while the lower level is one way of contributing to what the higher level is trying to achieve.

Perhaps this is also an important part of what we mean by understanding.

We can know a great deal about something without necessarily understanding it. We can know what a system does, what requirements it has, what decisions were made, what processes people follow, and what technologies are used. But if we can no longer move from those Whats toward the Whys that give them meaning, something important has been lost.

A requirement without its Why becomes an isolated statement. A design decision without its Why becomes an historical fact. A process without its Why becomes a sequence of activities that may continue long after anyone can explain what capability those activities were intended to provide.

The information may still be there. The understanding is not.

This also means that Why has no obvious natural endpoint. Every answer can potentially become the subject of another Why. Eventually we stop, but perhaps not because we have reached some ultimate Why. We stop because we have reached a boundary that is sufficient for what we are currently trying to understand.

That makes the choice of boundary important. If we draw it too narrowly, the Why may sit outside it. We can then describe the subject in extraordinary detail while remaining unable to explain its purpose. We may even optimize it successfully according to its internal logic while losing sight of whether it still contributes to what matters at the level above.

Perhaps understanding, then, does not primarily reside in the individual pieces of information we preserve.

It resides in the connections between them.

And perhaps one of the most important connections we can preserve is the one that allows us to keep asking:

Why?

Come to think of it, Why? may be the most frequently asked question in the universe. After all, every answer gives us something new to ask Why? about.

Earlier Practice Notes use the term Assessment Model to describe the way an assessment is structured and performed.

I have come to think that Assessment Approach is a better term.

The distinction matters because a Reference Model and an Assessment Approach are not the same kind of thing.

A Reference Model describes what we assess against. It makes explicit our understanding of the subject: its purpose, expected qualities, characteristics, relationships, constraints, or other aspects relevant to judging it.

An Assessment Approach describes how we perform the assessment. It determines how we investigate the subject, what evidence we seek, how we collect and interpret that evidence, and how we arrive at justified judgments.

Put simply:

Reference Model = what we assess against.

Assessment Approach = how we assess.

Calling both of these things models creates an unnecessary symmetry between them. The Reference Model represents an understanding of the subject. The Assessment Approach is the means by which we investigate reality in relation to that reference.

This Practice Note therefore introduces a terminology change.

From this point onward, I will use Assessment Approach rather than Assessment Model.

Earlier Practice Notes will remain unchanged. Where they use Assessment Model in this sense, it should generally be understood as what I would now call an Assessment Approach.

This is not a change to the underlying ideas in those notes. It is a refinement of the language used to express them.

And perhaps there is a broader principle here as well.

A developing body of knowledge does not need to rewrite its past every time its language improves. Earlier thinking can remain visible while later notes clarify, refine, or supersede it.

The history of the terminology then becomes part of the history of the understanding.

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.