Blog

A recent Practice Note explored the possibility that Product Management and Capability Management may share a deeper structure. Both concern something that has to remain understandable over time. Both involve deliberate change. Both require some basis for judging what currently exists. Both learn from evidence, and both appear to require continuing stewardship if that learning is not to disappear again.

That similarity led to a speculative idea: perhaps products and organizational capabilities are examples of a more general kind of managed subject. I tentatively called the phenomenon Subject Management.

There is nowhere near enough evidence yet to know whether Subject Management is a useful abstraction. Product and Capability may simply be unusually similar. Other subjects may expose important differences, or show that the concepts developed so far are incomplete. Portfolio and Compliance look like interesting candidates for further exploration, but neither has yet been developed sufficiently to tell us much.

Still, an emerging theory can be useful before it is established. Not because its implications should be accepted, but because they can reveal interesting questions.

One implication in particular keeps returning.

What if the subject, rather than the practices surrounding it, is the organizing principle?

We Usually See the Practices First

Organizations contain many established professional disciplines, each with its own language, responsibilities, methods and artifacts. Requirements Management deals with requirements. Architecture produces models and decisions about structure. Testing produces evidence about behaviour and quality. Operations deals with the product under real operating conditions. Product Management works with strategy, priorities, roadmaps and backlogs.

There is nothing inherently wrong with this specialization. Complex subjects require different forms of expertise, and those forms of expertise need their own professional practices.

The difficulty appears when all of those disciplines are contributing to the same thing.

Consider a product. Its requirements tell us something about what is expected. Its architecture tells us something about how important concerns have been interpreted structurally. Its implementation embodies countless decisions. Tests provide evidence about some of its characteristics. Operational telemetry reveals how it behaves under actual conditions. Customer research tells us how people experience it. Business measures may eventually tell us whether the outcomes that justified the product are actually occurring.

All of those perspectives matter, yet none of them is the product.

This creates a familiar integration problem. We try to connect Requirements with Architecture, Architecture with Development, Development with Testing, Testing with Operations, Product Management with Delivery, and eventually all of them with business strategy and outcomes. The natural response is to improve the interfaces between the practices.

Product Continuity suggests that there may be another way to look at the same problem.

Perhaps the practices do not primarily need to be integrated with each other.

Perhaps they need to be integrated through the subject they collectively serve.

The Reference Model Changes the Center of Gravity

A Product Reference Model does not require all knowledge about a product to be moved into one enormous central document. In fact, that would often be counterproductive. Architecture knowledge may be best maintained by architects. Operational knowledge may belong in operational systems and with the people responsible for them. Customer understanding may live partly in research, analytics and Product Management. Requirements, decisions, evidence and rationale may remain distributed across several authoritative sources.

The important thing is not that everything is stored together. It is that the significant pieces of understanding remain sufficiently connected that they can still describe one coherent product.

Once viewed that way, the Product Reference Model begins to change the relationship between the established artifacts.

A requirements specification is no longer the definition of the product. Neither is the architecture, implementation, backlog, test suite or operational dashboard. Each is potentially an authoritative source for some part of the understanding, but each remains a partial representation of a larger subject.

A similar argument can be made for organization capabilities and their Capability Reference Model.

The Reference Model does not have to replace these artifacts. Its function is different. It makes it possible to understand how their contributions relate to the subject and therefore to each other.

That distinction becomes especially important when those contributions disagree. If requirements say one thing, architecture implies another and operational behaviour shows something else, the problem is not merely that three artifacts are inconsistent. Something about the organization’s understanding of the product has become inconsistent.

The question then changes from which document is correct? to something richer: what does each source tell us about the product, what authority does it have for that claim, why do the claims differ, and what does that disagreement mean for our current understanding of the subject?

The subject becomes the point through which the disagreement can be interpreted.

Specialization Does Not Have to Mean Fragmentation

This does not imply that somebody should become the central expert on everything.

Quite the opposite. If the subject is complex enough to require multiple disciplines, distributed expertise is unavoidable and desirable. Architects should contribute architecture expertise. Engineers should contribute engineering knowledge. Compliance specialists should interpret relevant obligations. Operations should contribute what can only be learned from operating the realized product. Assessment specialists should safeguard the integrity with which evidence is turned into judgment.

The emerging Continuity work has already produced a useful principle for this:

Contribution follows expertise; stewardship preserves coherence.

That may eventually prove to be specific to Product and Capability Continuity. But if Subject Management survives as a more general phenomenon, the principle may travel with it.

Stewardship would then not mean owning all knowledge about a subject. It would mean preserving enough coherence across distributed contributions that the organization can continue to understand, develop and assess that subject as circumstances change.

This gives specialization a different position. The disciplines do not disappear, nor are they subordinated to some universal management role. Their expertise remains essential.

What changes is what sits in the middle.

What Happens When the Subject Changes?

Products and organizational capabilities provide the observations from which this idea emerged, but they are not necessarily the only possible subjects.

A portfolio, for example, might also require a coherent reference. Strategy, investment choices, dependencies, constraints, expected benefits, risks and realized outcomes all contribute to understanding what the portfolio is intended to accomplish and whether it is doing so. Portfolio reviews, prioritization and benefits realization might then be understood not merely as separate portfolio practices but as different contributions to maintaining, changing and judging the same subject.

Compliance presents a rather different case. Regulation, interpretation, organizational policy, controls, exceptions, operational reality, evidence and assurance all contribute to an organization’s understanding of what being compliant actually requires. A control framework alone may no more constitute the complete Compliance Reference Model than a requirements specification constitutes the complete Product Reference Model.

These are only extrapolations. Portfolio Continuity and Compliance Continuity have not yet been developed, and it would be easy to make them fit the emerging theory simply by starting from the theory and constructing them accordingly.

Their real value may therefore be precisely the opposite. They provide opportunities to discover whether the pattern survives when the subject changes.

If they independently reveal similar needs for reference, stewardship, development, assessment and learning, the Subject Management hypothesis becomes more interesting. If they expose additional recurring functions, the emerging architecture may need to expand. If they require fundamentally different structures, perhaps Subject Management is not a useful generalization after all.

Perhaps the Practices Change Position

If the pattern does survive, however, the implications could become substantial.

Testing might be understood less as an isolated lifecycle activity and more as one way of producing evidence about a subject. Requirements Management might become one way of preserving and developing explicit expectations about that subject. Architecture could represent significant structures, relationships, constraints and decisions within it. Operations could reveal behaviour that could not be known before realization. Assessment could establish trustworthy understanding of what currently exists. Development could deliberately change the subject. Learning could alter both the realization and the reference against which future development and judgment take place.

None of this makes those disciplines less important. In some ways it makes their contribution more explicit.

But it changes their position.

Instead of asking how Testing should integrate with Requirements, or how Architecture should integrate with Product Management, we might first ask what each contributes to the continuing understanding and management of the product. Their relationship to one another can then be understood through their relationship to the shared subject.

The same reframing could potentially occur around a capability, portfolio or compliance domain.

Many practices that currently appear to require pairwise integration might instead turn out to be different specialist contributions around a common reference.

We May Not Yet Know the Whole Architecture

There is another reason not to turn Subject Management into a framework too quickly.

The concepts that have become visible through Product and Capability Continuity may not constitute the complete phenomenon.

Reference, Stewardship, Development, Assessment and Learning recur strongly. But perhaps that is because the original questions were concerned primarily with preserving understanding for development and assessment. Once the lens widens toward management of the subject itself, other functions may become equally fundamental.

Perhaps Direction or Intent deserves a distinct place. Perhaps Decision-making does. Operation may turn out to be more than a source of evidence. Governance, value realization or something not yet identified may prove necessary to the generic architecture.

Portfolio and Compliance may reveal these things precisely because they are different from Product and Capability.

So Subject Management should not yet tell those subjects what their architecture is supposed to be. The subjects should be allowed to tell us what Subject Management might be.

An Emerging Reframing

For now, then, Subject Management remains speculation built from a small number of recurring patterns.

But it suggests a useful inversion.

Organizations naturally see their established practices because those practices have names, roles, processes, artifacts and organizational homes. The subject they collectively serve can be less visible precisely because no single practice contains it.

Continuity has repeatedly brought that subject back into view.

Perhaps that is merely useful for Product and Capability. Perhaps Portfolio and Compliance will show something different. Or perhaps the same pattern will continue to appear: distributed specialist knowledge, an explicit reference, deliberate change, recurring assessment, learning and continuing stewardship of something that must remain coherent even while everything around it changes.

If that happens, Subject Management may eventually become more than a convenient abstraction.

And its most significant contribution may not be another management discipline alongside all the others.

It may instead be a different way of seeing the disciplines we already have.

The practice is not the thing being managed. The subject is.

A recurring idea in this body of work is that organizations need an explicit reference if they want to preserve, develop and assess understanding over time.

Without such a reference, understanding gradually becomes implicit. People leave. Context disappears. Decisions remain while their rationale is forgotten. Eventually, whatever happens to survive — an existing system, a process, a framework, a set of requirements — may become the implicit definition of what should exist.

The Reference Model provides an alternative. It makes important concepts, relationships, expectations, assumptions and boundaries explicit enough that future people do not have to reconstruct everything from the realization itself.

But there is a potential problem with this argument. If documentation does not preserve understanding simply because it exists, why should a Reference Model?

It should not. A Reference Model is necessary for Continuity, but it is not sufficient.

Making Understanding Explicit

The first step toward preserving understanding is making enough of it explicit.

This is important because artifacts tend to survive longer than the reasoning that created them. A system may continue operating long after its designers have left. A capability may retain its processes after nobody remembers why they were introduced. A product backlog may continue evolving after its connection to the original product intent has weakened.

A Reference Model helps by separating the intended understanding of the subject from its current realization. That creates a stable point from which the subject can be developed and assessed without treating the current implementation as the definition of what is correct.

But making understanding explicit is not the same as preserving it. A Reference Model is itself an artifact. It can survive while the understanding required to interpret it disappears.

A Model Must Remain Interpretable

Imagine finding a carefully structured Reference Model ten years after it was created. The concepts are still there. The relationships are documented. Important expectations are described. Nothing has been deleted.

Yet some of the terminology has changed. Several concepts no longer mean quite what they once did. Assumptions that were obvious to the original authors are no longer obvious to the current organization. Nobody remembers why one relationship was considered significant while another was deliberately excluded.

The model survived. Its interpretation did not.

This is the same problem that affects ordinary documentation. Preserving information does not automatically preserve the context required to reconstruct its meaning.

A Reference Model therefore needs more than correct statements. Where necessary, it must preserve enough rationale, assumptions, definitions and context for future people to understand what those statements were intended to mean.

Otherwise, the model may remain readable while becoming progressively less understandable.

A Model Must Remain Connected to Reality

There is another risk. Once a Reference Model becomes authoritative, its contents can begin to acquire authority simply because they are in the model.

An expectation may originally have been based on operational evidence. An assumption may have reflected a particular business condition. A relationship may have been inferred from several observations. A constraint may have represented a deliberate decision rather than an unavoidable fact.

Over time, those distinctions can disappear.

Eventually someone asks:

Why do we believe this?

And the answer becomes:

Because it is in the Reference Model.

At that point, the mechanism intended to prevent Reference Substitution risks becoming a Reference Object itself.

A Reference Model should therefore remain connected, where relevant, to the basis for its claims. That does not mean every statement needs an academic citation. It means that important distinctions between observation, evidence, assumption, decision, interpretation and intent should not disappear simply because they have been synthesized into a model.

Agreement does not solve this problem either. An entire organization may agree with what the Reference Model says. That agreement is useful evidence that the model represents shared understanding. It is not necessarily evidence that every claim within the model remains correct.

The Reference Model must remain open to challenge from evidence.

The Boundary Must Be Explicit

No Reference Model can contain everything.

The moment we describe a product, capability, system or body of knowledge, we make decisions about what belongs inside the subject and what remains outside it. Those decisions matter because the boundary helps define the object being understood.

Without an explicit boundary, absence becomes ambiguous. If something is missing from the Reference Model, is it outside the subject? Was it deliberately excluded? Is it considered insignificant? Is it unknown? Or did somebody simply forget it These possibilities have very different meanings.

A useful Reference Model therefore needs an explicit subject and sufficiently clear boundaries. Not because boundaries can eliminate every ambiguity, but because they allow people to reason about what the model claims to represent.

Before asking whether a Reference Model is complete, we need to know what it is intended to be complete about.

The Problem of Appropriate Abstraction

Reference Models need abstraction. If a Capability Reference specifies a particular process, role structure and toolset as the definition of good capability, it may prevent legitimate alternative realizations.

If a Product Reference simply reproduces the current architecture, requirements and behavior, the existing product becomes the model for its own future. The Reference Model has then become too concrete. Instead of preserving intent independently of realization, it preserves the realization.

But abstraction has an opposite failure mode. Consider a Capability Reference that says an organization should have effective governance, appropriate competence, efficient processes and continuous improvement. It is difficult to disagree with. It is also difficult to do much with.

What would distinguish a strong realization from a weak one? What evidence would matter? What should Development attempt to improve? What exactly should an assessor assess?

Excessive abstraction can make a Reference Model universally acceptable precisely because it no longer makes sufficiently meaningful distinctions.

The challenge is therefore not to maximize abstraction. It is to find the appropriate abstraction.

A Reference Model should be abstract enough to permit alternative realizations, but specific enough to distinguish meaningful alternatives.

This principle applies beyond any particular domain.

A Capability Reference must avoid prescribing one organizational implementation while remaining specific enough to describe meaningful organizational ability.

A Product Reference must remain independent of today’s implementation while being concrete enough to guide Development and Assessment.

A model of a body of knowledge must allow understanding to evolve without reducing that understanding to principles so generic that the observations, relationships and reasoning that gave them meaning disappear.

The object changes. The problem remains the same.

A Model Must Be Maintained Through Learning

Even a well-bounded, appropriately abstract and interpretable Reference Model eventually becomes outdated if understanding continues to evolve while the model does not.

New evidence appears.

Operational experience challenges assumptions.

Assessments reveal weaknesses in the reference itself.

Development creates possibilities that were not previously considered.

The environment changes.

Stakeholders learn that they value something differently than expected.

A Reference Model that cannot change eventually stops representing current understanding.

But simply updating it creates another Continuity problem. If yesterday’s model says one thing and today’s says another, future people may need to understand not only what changed but why.

Otherwise maintenance preserves the latest answer while destroying the reasoning that connects one state of understanding to the next.

A living Reference Model therefore needs stewardship.

Changes should be deliberate. Important revisions should remain reconstructable. New evidence should be able to challenge old assumptions. Learning should feed back into the reference rather than accumulating elsewhere until the model gradually drifts away from what the organization actually knows.

Continuity does not require the Reference Model to remain unchanged. It requires understanding to remain continuous while the Reference Model evolves.

The Reference Model Is Not the Understanding

This leads to an important qualification.

A Reference Model does not contain organizational understanding in the same way that a database contains records.

Understanding exists through the relationship between the model, the evidence behind it, the context in which it is interpreted, the people who use it, the realizations it guides and the learning that changes it.

The Reference Model gives that understanding structure.

It makes important parts explicit.

It provides an independent reference for Development and Assessment.

It helps future people reconstruct why the subject is understood in a particular way.

But the artifact itself is not Continuity.

A perfectly preserved Reference Model can still become incomprehensible, outdated, disconnected from evidence, incorrectly scoped or so abstract that it ceases to guide meaningful judgment.

The same lesson that led to Reference Models therefore applies to Reference Models themselves.

Artifacts do not preserve understanding merely because they survive.

A Reference Model does not preserve understanding by itself.

It creates a structure through which understanding can be preserved, challenged, developed and continued over time.

In assessments, workshops and organizational discussions, agreement often feels reassuring. Several people describe the situation in the same way. Stakeholders confirm one another’s explanations. A workshop reaches consensus about why something works as it does. After enough people have repeated the same account, it becomes tempting to treat the matter as established.

Everyone agrees. Therefore, we know.

But those are two different things. Agreement tells us something about what people believe. It does not necessarily tell us whether what they believe is true.

When Agreement Looks Like Evidence

Imagine interviewing five people about why a particular governance process exists. All five give essentially the same explanation. That consistency is useful information. It suggests that the organization has a shared understanding of the process.

But suppose all five originally learned the explanation from the same person. We do not really have five independent pieces of evidence. We have one explanation that has propagated through five people.

Or perhaps the explanation has simply been repeated for so long that nobody remembers where it came from. It has become organizational knowledge through repetition rather than through continued connection to its original rationale. The agreement is real. The explanation may still be wrong.

This creates an important distinction in assessment.

Agreement can be evidence of agreement without being evidence for the claim being agreed upon.

If several stakeholders independently describe the same organizational problem, their agreement may tell us that the perception is widespread. That can itself matter. Shared perceptions influence behavior, decisions and organizational relationships.

But if the question is whether the underlying claim is correct, agreement alone is not enough. Suppose everyone agrees that a particular control is required by regulation. The agreement demonstrates that the organization believes the control to be mandatory. It does not establish that the regulation actually requires it.

Suppose everyone agrees that a system limitation exists because of an architectural constraint. The agreement tells us that this explanation is commonly accepted. It does not establish that the constraint still exists.

Suppose everyone agrees that a capability works well. That tells us something about organizational confidence or perception. It does not demonstrate that the capability reliably produces the intended effects under the conditions that matter.

Agreement Is Not Corroboration

The distinction becomes particularly important when evidence is collected through interviews and workshops. Multiple participants can easily create an impression of corroboration. But corroboration depends on more than the number of people repeating a claim. It depends on whether the supporting evidence is meaningfully independent.

Ten people repeating an explanation that originated from the same document may represent one source, not ten.

Five teams using the same dashboard may appear to provide five confirmations of performance while all relying on the same underlying measurement.

Several documents may repeat the same statement while ultimately tracing back to one original assumption.

Counting confirmations without understanding their provenance can therefore create false confidence.

When Agreement Does Matter

This does not make agreement unimportant. Agreement can reveal shared understanding. Disagreement can reveal ambiguity, hidden assumptions, competing perspectives or different experiences of the same subject. Consensus can be valuable when an organization must choose an intention, define a boundary, establish priorities or decide which trade-offs it is willing to accept.

Some organizational questions are inherently matters of choice.

What do we want this capability to achieve?

Which outcomes do we value?

What level of risk are we willing to accept?

Where should we place the boundary of this product or capability?

For questions like these, agreement may be part of establishing the reference itself. The organization is not discovering an external fact. It is making its intent explicit.

But other questions concern reality.

Does the capability currently produce the intended effect?

Does this architectural constraint actually exist?

Did this decision originate for the reason we now believe?

Does the product behave reliably under the conditions we expect?

Those claims require evidence.

Understanding What Kind of Evidence We Have

This is why agreement should not be confused with corroboration.

Corroboration strengthens a claim by connecting it to additional evidence that does not merely reproduce the same assumption. That evidence might come from observed behaviour, measurements, historical records, operational outcomes, contemporaneous decisions, technical artifacts or genuinely independent accounts.

The purpose is not to distrust people.

It is to understand what kind of evidence we actually have.

A shared explanation may be highly valuable evidence about organizational understanding while remaining weak evidence about historical fact. A unanimous workshop may establish organizational intent while saying little about current performance. A commonly accepted assumption may provide a useful starting point while still requiring validation.

Agreement and Continuity

This distinction also matters for Continuity.

Organizations inherit explanations just as they inherit documents, processes and systems. Over time, an interpretation can lose its connection to the evidence or rationale that originally supported it. The explanation survives because people continue to repeat it.

Eventually, agreement itself becomes the justification.

“We have always understood it this way.”

At that point, shared understanding can conceal Understanding Debt rather than prevent it.

Preserving understanding therefore requires more than preserving consensus. Where a claim matters, future people should ideally be able to distinguish what was recorded, what was observed, what was inferred, what was decided, and what became commonly believed.

Agreement belongs in that picture. But it should remain what it is.

Agreement is evidence that people agree.

It is not, by itself, evidence that they are right.

I have now reached eighty posts.

At the end of the previous retrospective, I wrote that the subjects were changing while the method did not. At the time, that already felt important. The Practice Notes had moved well beyond software quality into watches, clothing, memory, writing, AI and organizational continuity, yet the same underlying questions kept returning. What I had not expected was what would happen next.

During the last twenty posts, the body of knowledge began to do more than connect existing observations. It started generating new ones.

The Body of Knowledge Became a Subject

The first part of this cycle was less about extending the theory and more about understanding what had already accumulated. As the number of Practice Notes increased, a new problem appeared. Writing had become cheap. Reviewing, synthesizing and maintaining all of the resulting representations had not.

That led to a shift in how I thought about the notes themselves. Perhaps the objective was not to keep producing more polished documents about the same underlying knowledge. Perhaps the notes could become the primary body of evidence, while papers, models, guidance and other publications became derived representations.

That idea changed the role of AI as well. Instead of using AI only to help write individual notes, it could help search across them, connect them, identify recurring patterns and synthesize different views of the same body of understanding.

The notes were no longer merely outputs. They had become material for further inquiry.

From Experience to Pattern

That made another change possible. Professional experience usually arrives as cases. A difficult assessment. A strange organizational behavior. A successful intervention. A failed transformation. A watch that reveals something unexpectedly useful about reference models.

Individual cases matter, but their greater value may lie in what becomes visible when several of them are compared. A practitioner who has seen the same underlying mechanism repeatedly may begin to recognize it in very different situations.

This does not mean that experience produces automatic answers. It produces better hypotheses.

That distinction became increasingly important during this cycle. The blog began moving from recording what happened toward asking what different experiences might have in common. Once that happened, the theory started becoming more active.

When the Theory Began to Extrapolate

Several recent notes were no longer straightforward abstractions from direct experience. They were consequences of ideas that had already developed elsewhere.

If organizational capabilities persist after improvement projects end, perhaps improvement is not enough. Perhaps they require continuing Capability Management.

If major transformations change several capabilities at the same time, perhaps transformation can be understood as the coordinated evolution of a capability portfolio rather than primarily as the implementation of a framework.

If individual subjects can all be strong while the collection as a whole is poorly composed, perhaps the portfolio itself is also a subject with its own reference, development and assessment.

And if Product Management and Capability Management appear to contain the same recurring architecture of reference, development, assessment, learning and stewardship, perhaps they are two specializations of something more general.

For now, I have called that possibility Subject Management. That last idea is deliberately speculative. In fact, several notes in this cycle received question marks for exactly that reason.

I have enough experience and theory to see why the idea might make sense. I do not have enough to claim that it does. That distinction has become more important as the theory has grown.

The Difference Between Observation and Extrapolation

One useful correction happened while writing Returning to the Same Organization.

The original draft tried to connect the experience directly to loss of organizational understanding. But that was not actually what I had observed.

What I had observed was simpler. I had returned to several very large organizations after roughly ten years and found that they had become remarkably different organizations. The company was still there. The organization I remembered largely was not.

That led to the idea of an organizational generation, and to a question about how continuity is preserved when organizational generations may be much shorter than human generations.

That was enough. The note became better when I stopped trying to make the observation prove more than it actually did. This may be one of the most important developments in this cycle.

As the theory becomes more ambitious, the need to distinguish between experience, interpretation and speculation becomes more important as well.

Knowing When to Stop

That same concern appeared more explicitly in Knowing When to Stop.

I have always been inclined to keep asking Why. One explanation usually leads to another question, and another, until the underlying principle starts becoming visible.

But there is a limit. Sometimes the evidence simply runs out. At that point, further reasoning may stop producing understanding and start producing speculation. There is an important difference between saying that there is no answer and saying that I cannot justify an answer. The second is often the more honest conclusion.

That idea later returned in a more professional form: assessment requires curiosity. But curiosity must be disciplined. The assessor should keep asking when something does not make sense, but should also stop when the evidence no longer supports another conclusion.

That led to one of the clearest propositions of this cycle:

Assessment is disciplined curiosity directed toward justified judgment.

A Method in the Madness

The biggest surprise, however, may not have been any one of the theoretical ideas. It was recognizing something about the way those ideas are being produced.

Across quality management, capability assessment, Product Continuity, watches, dress codes, organizational change and even a fictional Swiss engineer called Hans Hexagon, I seem to keep following the same pattern.

It begins with Why.

Then Why behind the Why.

And often another Why behind that.

The questioning continues until the visible practice, product, process or artifact starts giving way to the purpose beneath it. Once that purpose becomes clearer, inconsistencies become easier to see.

The process no longer performs the function it was intended to perform. The framework has become more important than the capability it was meant to create. The implementation has become the reference. The visible What has drifted away from the underlying Why. And once that inconsistency becomes visible, the direction of development often becomes clearer. A compact version of the pattern is:

Reveal the Why → Reveal the Inconsistencies → Reveal the Path

I have started calling this the Recursive Why. I do not yet know whether it is anything more than a description of how I personally tend to think. But that question itself is now interesting.

The Theory Is Beginning to Talk Back

Earlier Practice Notes mostly captured observations. Later notes connected those observations into recurring concepts. Those concepts gradually became a theory. During this cycle, something changed again.

The theory began suggesting what I should look at next. Capability Continuity suggested Capability Management. Capability Management suggested capability-portfolio thinking. Portfolio thinking changed how transformation could be interpreted. Product and Capability Management suggested the possibility of a common management architecture.

The theory was no longer only organizing the past. It was generating hypotheses about things I had not originally set out to investigate. That feels like an important threshold.

It is also dangerous. A theory that can generate new ideas can also generate very convincing nonsense. Which is why the other development in this cycle matters just as much. Keep asking. But do not claim more than the evidence allows.

Perhaps the Recursive Why and disciplined curiosity belong together. One keeps the inquiry moving. The other keeps it honest.

What Comes Next?

I am less certain than ever that I know. That is not necessarily a problem. The Practice Notes increasingly seem to work best when they preserve observations before I know exactly where those observations belong.

Some will become part of Reference Model Theory. Some may contribute to Capability Management or Product Management. Some may belong in a future theory of Assessment as a Professional Discipline. Some may disappear during later synthesis because they turn out to add very little. And some speculative ideas may simply be wrong. The important thing is that their status remains visible.

The notes are becoming a record not only of conclusions, but of how those conclusions emerged, changed and occasionally failed. That may become valuable in its own right.

Reflection

At sixty posts, I wrote that the subjects were changing while the method remained the same. At eighty, I think I am beginning to see part of that method. The progression so far looks something like this:

Observation → Pattern → Theory → Extrapolation → Method

The next question may be whether the method itself can be understood well enough to test. Is the Recursive Why simply one person’s habit of thought? Or is there something more general in it?

I do not know. Which, after the last twenty posts, feels like exactly the right answer. For now.

Assessment is often described in procedural terms. We define criteria, conduct interviews, review documents, observe practices, gather evidence, analyze findings and eventually produce a judgment. All of those activities matter. Yet they describe what an assessor does without quite capturing the intellectual discipline behind it.

Recently, while thinking about the importance of asking Why—and equally about knowing when to stop asking—I began to wonder whether assessment starts somewhere simpler.

Perhaps it starts with curiosity.

Looking Beyond the First Answer

An assessor spends a remarkable amount of time asking questions. Why does this work this way? What is this process intended to accomplish? How do we know that it works? Why was this decision made? What evidence supports that conclusion? The first answer is rarely the end of the inquiry.

A process exists because a policy requires it. But why does the policy require it? A metric is reported because management considers it important. But what decision is the metric supposed to support? A test is performed because a requirement says something must happen. But why does that behavior matter?

One Why leads naturally to another. Gradually, the inquiry moves away from the visible realization and toward the purpose behind it. This matters because assessment can easily become an examination of visible things. Does the process exist? Is the document available? Has the activity been performed? Is the required role present?

Those may all provide useful evidence, but they do not necessarily tell us whether the subject is actually doing what it needs to do. Curiosity pushes beyond the visible What toward the underlying Why.

But curiosity alone is not assessment.

Curiosity With Constraints

An endlessly curious person can keep asking questions forever. An assessor eventually has to reach a judgment, and that judgment has to be justified by the available evidence.

This creates an important tension. The assessor must be curious enough not to accept the first convenient explanation, but disciplined enough not to replace missing evidence with a more satisfying story. A plausible explanation is not necessarily a finding. An inference is not necessarily a fact. Several consistent observations may increase confidence without producing certainty. Sometimes different sources continue to contradict one another even after careful investigation.

And sometimes the most accurate answer is simply that we do not know. That is not necessarily a failure of assessment. The purpose is not to eliminate uncertainty. It is to understand the subject well enough to make the most justified judgment the available evidence permits.

This is also why collecting evidence is not enough. Evidence does not interpret itself. A document can show that a process exists without establishing whether the process is appropriate. A metric can show that something changed without explaining why. An interview can reveal how someone understands a situation without establishing that their understanding is correct. Even direct observation requires interpretation before it becomes meaningful.

Assessment therefore moves continually between questions, evidence and interpretation. One source raises another question. Another source strengthens or weakens a possible explanation. Contradictions become interesting rather than inconvenient because they may reveal that the subject is not as well understood as it first appeared.

Eventually, however, interpretation has to stop and judgment has to begin.

Giving Curiosity Direction

Assessment is also not curiosity about everything. Almost any subject can generate an unlimited number of interesting questions. An assessor could investigate indefinitely and still fail to answer the question the assessment was supposed to address.

Curiosity therefore needs direction. That direction comes from the reference against which the subject is being assessed. The reference establishes what matters. It helps determine which questions are relevant, which evidence is significant and what kind of judgment must eventually be made.

Without a reference, curiosity can become exploration without a destination. Without curiosity, the reference can become a checklist. Assessment requires both.

The reference gives the inquiry direction, while curiosity prevents the assessor from reducing that inquiry to mechanical compliance.

Knowing When to Continue—and When to Stop

Some answers deserve another question. Something may be formally compliant but ineffective. A process may exist but no longer perform its intended function. A healthy-looking metric may hide an important weakness. Two sources may tell incompatible stories. An apparently minor inconsistency may reveal that reality has drifted away from the organization’s own understanding of what should be happening.

Those are reasons to continue. The assessor follows the inconsistency because it may reveal something important.

Yet the opposite discipline matters just as much. Eventually the evidence may run out. Further questioning may stop increasing justified understanding and start producing increasingly elaborate speculation.

At that point, the assessor has to be willing to stop. Not because the question no longer matters, and not because an answer cannot exist, but because assessment should not claim more than the available evidence supports.

There is value in preserving the difference between what we know, what we can reasonably infer and what remains unknown. Making that boundary visible may sometimes be more valuable than forcing every question toward a confident conclusion.

The discipline therefore works in both directions. Keep asking when the evidence suggests there is more to understand. Stop when the evidence no longer justifies another step.

The Discipline of Curiosity

This leads me to a description of assessment that I had not considered before:

Assessment is disciplined curiosity directed toward justified judgment.

Curiosity makes us ask. The reference gives those questions direction. Evidence constrains the possible answers. Interpretation turns evidence into understanding. Discipline prevents interpretation from quietly becoming invention. Judgment expresses what we can reasonably conclude, while uncertainty preserves the boundary of what we cannot.

The familiar mechanisms of assessment still matter. Interviews, observations, evidence reviews, assessment models, scoring approaches and reporting methods help make the work systematic and repeatable.

But perhaps those mechanisms are not the essence of assessment. They are the means through which disciplined curiosity operates.

Much of the assessor’s craft may therefore exist between two apparently opposing instincts: keep asking and know when to stop. Ask too little, and the assessment merely confirms what was already visible. Ask without discipline, and the assessment disappears into speculation.

The skill lies somewhere between them: remaining curious enough to discover what lies beneath the first answer while remaining disciplined enough to recognize where justified understanding ends.

Perhaps that is why assessment has always felt like more than applying a model or completing a checklist. At its best, it is a disciplined attempt to understand before we judge.

Assessment is disciplined curiosity directed toward justified judgment.