Category: Capabilities

Much of the discussion about AI and software development focuses on whether AI will replace developers.

A different risk may be emerging.

Organizations may use AI to automate precisely the work through which people traditionally developed the understanding required to become senior.

Senior developers did not enter organizations as senior developers. Their expertise accumulated over time.

They implemented small changes. They investigated defects. They read unfamiliar code. They made mistakes. They observed production failures. They asked why something had been designed in a particular way. They discovered that apparently strange implementations sometimes existed for good reasons — and sometimes for reasons that had stopped being good years earlier.

Through repeated exposure, they acquired more than technical skill.

They acquired context.

They learned not only what the system does, but increasingly why it became the way it is.

The Efficiency Paradox

AI can remove substantial amounts of routine work from software development. That can be valuable.

A junior developer may no longer need to spend hours writing relatively straightforward implementation code, searching documentation, constructing tests, investigating logs or performing other work that an AI system can complete much faster. Measured as delivery efficiency, this looks like progress.

But some apparently inefficient work may have performed another function:

It created experienced people.

The work product was not its only output.

Learning was another.

If we automate the activity while measuring only whether the immediate deliverable can still be produced, we may overlook the organizational capability that the activity was helping to create.

Work Has More Than One Outcome

This suggests a more general distinction.

An activity may produce an explicit outcome and one or more implicit outcomes.

For example:

Explicit outcome:
– A developer fixes a defect.

Implicit outcomes:
– The developer learns how the system behaves.
– They discover relationships between components.
– They understand why a particular design decision matters.
– They encounter a business rule that was previously invisible to them.
– They become better able to recognize similar problems in the future.

An AI system may produce the explicit outcome extremely efficiently while reducing some of the implicit outcomes.

The defect still gets fixed. But who learned from fixing it?

The Succession Problem

This becomes particularly important when experienced people leave.

Organizations already struggle to preserve understanding across personnel changes. Documentation may preserve requirements, architecture, code and decisions while much of the reasoning connecting them remains in people’s heads.

AI could introduce a second continuity problem. It may not only change how existing knowledge is preserved.

It may change how new people acquire enough understanding to become future custodians of that knowledge.

If today’s senior developers retire or leave, organizations cannot simply replace them with today’s juniors plus more capable AI.

The question is whether those juniors have had opportunities to develop the contextual and causal understanding that made the departing developers senior in the first place. This is therefore not merely a staffing pipeline problem.

It is a succession of understanding problem.

Expertise Is More Than Accumulated Information

It would be tempting to solve this by giving future developers better access to documentation and AI-generated explanations. That will help, but it may not be sufficient.

Experienced practitioners possess more facts, but they also have developed judgment.

They recognize when something looks suspicious before they can necessarily explain exactly why. They know which questions to ask. They recognize recurring causal patterns. They understand where apparently local changes may have wider consequences. Much of that ability was developed through interaction with real problems.

The challenge is therefore not simply to transfer everything a senior developer knows to a junior developer.

It is also to preserve opportunities through which less experienced people can develop their own understanding and judgment.

AI Changes the Learning Path

This does not imply that organizations should preserve inefficient manual work simply because previous generations learned through it. That would confuse the practice with the function it served.

The important question is instead:

Which learning functions did the old way of working provide, and how will those functions be preserved when AI changes the work?

Perhaps some learning can happen faster with AI. AI can explain unfamiliar code, expose dependencies, challenge assumptions, simulate alternatives and make organizational knowledge easier to interrogate.

Used deliberately, it may accelerate the development of understanding rather than diminish it.

But that requires designing AI-supported work for more than immediate productivity.

The objective cannot only be:

How can AI help this developer produce the result faster?

It must also include:

How does this developer become capable of understanding, questioning and eventually owning the results?

Implication for Continuity of Understanding

Continuity of understanding therefore has at least two dimensions.

The first is preservation:

Can the organization retain enough of its existing understanding when people leave, systems change and structures evolve?

The second is regeneration:

Can new people develop enough understanding to extend, challenge and eventually replace the understanding held by today’s experts?

A reference model can help with the first by connecting fragmented knowledge and preserving relationships, rationale and intent.

But it may also support the second. If important relationships between intent, requirements, decisions, implementation, evidence and outcomes are made accessible, a less experienced person does not have to reconstruct all of them accidentally over years of work.

They can explore them deliberately.

AI may make that exploration dramatically easier.

The opportunity is therefore larger than preserving the old apprenticeship model.

It is to create a better one.

Working Proposition

AI should not only increase the productivity of today’s experts. It should help create tomorrow’s experts.

When evaluating AI-supported ways of working, organizations should therefore assess not only:

• whether work is completed faster,
• whether fewer people are required,
• whether output quality remains acceptable,

but also:

• whether practitioners continue to develop contextual understanding,
• whether reasoning and rationale remain accessible,
• whether people learn from the work AI performs with them,
• whether judgment and ownership continue to develop,
• and whether the organization is creating the people who will be capable of carrying its understanding forward.

Otherwise, AI may solve today’s capacity problem while quietly creating tomorrow’s capability problem.

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.

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.

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.