Marcel van Oosterwijk

Category: Capabilities

Organizational capabilities, responsibilities, governance, ways of working, transformation, and how organizations develop and sustain their ability to achieve outcomes.

  • Practice note: When Local Heroes Hide Missing Capability

    Organizations often depend on people who make things work despite the organization around them. They build professional communities. They connect people who would otherwise remain disconnected. They maintain methods and knowledge. They support Sales. They create training. They solve recurring problems. They preserve relationships between organizational units. They know whom to call when something needs to happen.

    These people are often extremely valuable. They can also make organizational weakness remarkably difficult to see.

    Success Does Not Necessarily Demonstrate Capability

    Capability concerns organizational ability. If an organization repeatedly produces a valued effect, it is tempting to conclude that the organization possesses the capability required to produce it.

    That conclusion may be premature. Sometimes the effect exists because one or a few individuals continuously compensate for weaknesses in the surrounding organization.

    The organization may lack clear ownership, coherent processes, sufficient knowledge, effective collaboration, appropriate decision rights, or sustainable mechanisms for learning. Yet an experienced and motivated individual bridges those gaps personally.

    The desired effect still appears. From the outside, the capability seems to work. But the organization may actually be observing exceptional individual performance rather than robust organizational capability.

    The Local Hero Paradox

    This creates a paradox. The better the local hero becomes at compensating for organizational weakness, the less visible that weakness becomes.

    Management sees that:

    • problems are being solved;
    • people are being connected;
    • knowledge is being maintained;
    • customers are being supported;
    • initiatives continue to move;
    • important outcomes are still being produced.

    The immediate organizational need therefore appears to have been satisfied.

    Why invest further?

    The answer only becomes obvious when the local hero becomes unavailable, overloaded, changes role, or leaves. Suddenly relationships disappear. Knowledge becomes difficult to find. Activities that seemed routine stop happening. Decisions take longer. People discover that nobody knows why particular arrangements exist. The organization then learns that an apparently functioning capability depended upon a person rather than upon a sustainable organizational ability.

    The Hero Can Preserve the Problem

    There is a more uncomfortable consequence. Local heroes do not merely compensate for missing capability. Their success can help preserve the conditions that made their heroics necessary. Investment is easiest to justify when organizational weakness produces visible consequences. The local hero prevents those consequences. The stronger their performance, the weaker the apparent case for investing in the underlying capability.

    A self-reinforcing pattern can emerge:

    Weak organizational capability

    → individual compensates

    → desired effects continue

    → weakness becomes less visible

    → investment appears unnecessary

    → dependency on the individual continues

    The organization receives the benefit without developing a sustainable ability to produce it. Success therefore becomes misleading evidence.

    Look Beyond the Effect

    Capability Assessment should therefore not ask only whether the intended effect currently occurs. It should also investigate how reliably the organization can continue producing that effect under relevant conditions.

    Important questions include:

    • What happens when key individuals are unavailable?
    • Is important understanding distributed or concentrated?
    • Can responsibilities be transferred without substantial loss?
    • Are important relationships institutional or primarily personal?
    • Can another competent person reconstruct why current arrangements exist?
    • Does the organization have mechanisms for maintaining and evolving the capability?
    • Would the capability survive reorganization, growth, turnover, or changing priorities?

    A capability that works only while particular individuals remain personally engaged may still produce considerable value.

    But its resilience is limited. That limitation should be visible in the assessment.

    Local Heroes Are Not the Problem

    The lesson should not be to suppress exceptional individual initiative. Organizations need people who see gaps, connect knowledge, challenge existing arrangements, and make things happen.

    The problem arises when the organization treats their extraordinary contribution as evidence that no further organizational development is required.

    A local hero may actually provide some of the strongest evidence about where capability needs strengthening.

    Their work reveals which relationships matter, which knowledge must be preserved, which decisions require coordination, and which organizational mechanisms are currently missing.

    Instead of asking:

    How do we make this person less important?

    a better question is:

    What organizational ability is this person currently making possible, and how can we make that ability sustainable?

    The objective is not to eliminate individual excellence.

    It is to ensure that excellence strengthens organizational capability rather than permanently substitutes for it.

    From Heroism to Capability

    Capability Development can use successful local practice as evidence. The organization can examine what the individual actually does:

    • which functions they perform;
    • which relationships they maintain;
    • which knowledge they preserve;
    • which decisions they enable;
    • which gaps they bridge;
    • which effects their contribution produces.

    The objective is not necessarily to formalize every activity. That would risk replacing useful human judgment with bureaucracy.

    Instead, the organization should understand the functions behind the successful behavior and determine which of those functions need to become sustainable organizational abilities. Some may remain dependent on professional expertise.

    Some may be distributed across several people. Some may require explicit stewardship. Some may benefit from better information, authority, processes, tools, communities, or governance. The realization can vary. What matters is that the organizational ability no longer disappears when one person does.

    A Continuity Problem

    Local-hero dependency is therefore also a Continuity problem. Understanding may exist, but remain concentrated. Relationships may work, but remain personal. Decisions may be effective, but their rationale may remain undocumented.Learning may occur, but remain inside one person’s experience. The organization possesses knowledge without necessarily possessing continuity of that knowledge.

    A useful test is therefore:

    Can the next generation continue the reasoning rather than merely inherit the artifacts?

    If not, the apparent capability contains significant Understanding Debt.

    The Management Trap

    There is a final irony. Organizations sometimes respond to highly capable individuals by giving them even more responsibility. Because the person repeatedly solves difficult problems, additional problems are routed toward them. The local hero becomes increasingly valuable and increasingly overloaded at the same time.

    This further concentrates knowledge and relationships. Eventually the organization has created a critical dependency around precisely the person who appeared to demonstrate that the capability was strong.

    The appropriate response to successful local heroism may therefore be investment rather than additional dependency.

    The question for management is not merely:

    How much more can this person deliver?

    It is:

    What does this person’s success teach us about the capability we should build around them?

    Closing Thought

    Local heroes can create extraordinary organizational value. But the effects they produce should not automatically be mistaken for evidence of sustainable organizational capability.

    Sometimes the opposite is true. Their success reveals how much organizational ability currently depends upon individual effort. The strongest organizations should therefore learn from their local heroes rather than simply depend upon them.

    Because a local hero can compensate for missing capability. And, paradoxically, the better they become at doing so, the longer that missing capability may remain hidden.

  • Practice Note: How many systems did you retire last year?

    Organizations often associate continuity with keeping systems, products, or capabilities running. Yet continuity can require the opposite: knowing when something can safely cease to exist.

    A mature portfolio does not only make informed decisions about what to add. It also makes informed decisions about what to remove.

    One provocative measure of product-portfolio maturity is therefore the number of systems an organization has been able to retire. The measure should not be taken literally—retiring more systems is not inherently better—but the reasoning behind it is revealing. Retiring a system confidently requires understanding what the system still contributes and what depends upon it.

    Consider an old mainframe environment.

    Over many years, applications may have been migrated elsewhere. New development has stopped. Most known business functionality has disappeared. The organization believes that the mainframe has effectively become redundant.

    Yet it remains operational. Why? Because nobody is sufficiently confident that it can be switched off.

    There might still be a batch process running somewhere. An obscure interface may still exchange data with another system. A business process performed only once a year may depend upon it. Some responsibility may have been assumed to have migrated but never actually did.

    The organization does not know that the mainframe is necessary. It does not know that it is unnecessary. That distinction can keep an obsolete system alive for years. Loss of understanding can preserve obsolete realizations

    This exposes an interesting inversion. Normally, understanding is associated with an organization’s ability to maintain and develop something. But understanding is equally important when deciding to stop maintaining it.

    As organizational understanding disappears, the realization can become increasingly difficult to change or remove. Its known value may decrease while uncertainty about its unknown value increases.

    Eventually the organization may preserve the realization not because it believes the realization is valuable, but because it cannot establish that removing it is safe.

    Loss of understanding can increase the persistence of something whose value has already disappeared.

    The resulting portfolio contains systems that survive through uncertainty.

    They consume infrastructure, licenses, operational effort and scarce expertise. They may constrain architectural change and introduce security or operational risks. Yet attempts to remove them encounter the same question:

    Are we absolutely sure nothing important still depends on this?

    Without sufficient understanding, the organization cannot answer.

    Retirement is an assessment problem

    Retiring a system is therefore not merely a technical activity. It requires an assessment. The organization needs sufficient understanding of the system’s purpose, current contribution, dependencies, users, data, business processes and outcomes to form a justified judgment about what will happen when it disappears.

    Evidence may need to be collected: usage information, interface traffic, batch execution, dependency analysis, business-process mapping, stakeholder knowledge or controlled interruption.

    The question is not simply whether the system appears obsolete.

    The question is whether there is sufficient evidence and understanding to justify the judgment that its removal is safe.

    This connects retirement directly to Continuity.

    Continuity does not mean preservation of the object

    Continuity can easily be misunderstood as an argument for keeping things alive. It is not.

    The continuity that matters is continuity of what remains significant: intent, outcomes, responsibilities, knowledge and necessary relationships. A particular realization may cease to be the appropriate way of providing them.

    Sometimes maintaining Continuity therefore requires replacing a system. Sometimes it requires transferring responsibilities elsewhere. Sometimes the purpose itself has disappeared and nothing needs to replace it. And sometimes the correct decision is simply to switch the system off.

    The ability to make that decision confidently depends on understanding.

    Poor Continuity may not cause an old system to disappear. It may be precisely why nobody dares to switch it off.

    The portfolio implication

    This has consequences for portfolio management. Portfolio development is often associated with investment: selecting new products, approving initiatives and allocating resources to new opportunities.

    But a portfolio also develops through subtraction. Removing redundant elements releases resources, reduces complexity and risk, and allows investment to concentrate on elements that continue to contribute to portfolio intent.

    A mature portfolio-management capability therefore needs to understand its existing portfolio well enough to answer not only:

    What should we add?

    but also:

    What can we safely stop?

    This makes retirement capability an interesting indicator of portfolio understanding. An organization that continually adds new systems but cannot confidently retire old ones may not have a technology problem at all.

    It may have accumulated understanding debt at portfolio scale.

    And I think this one is particularly valuable because it produced a candidate generic insight for A:

    Sufficient understanding is required not only to develop and assess a subject, but also to determine when it can safely cease to exist.

  • Practice Note: The New Bottleneck

    As a consequence of using AI in my writing, the cost of writing has decreased dramatically. An idea that once required several evenings of outlining, drafting, rewriting and polishing can now become a coherent paper much faster. Arguments can be tested in different forms. Weak transitions can be repaired. Examples can be added. Alternative structures can be explored without starting again from scratch. For that, I am incredibly grateful.

    But one important cost has not decreased nearly as much: the cost of serious review. A reviewer still has to read the paper carefully. They still have to understand the argument rather than merely recognize the words. They may also use AI, but that’s not enough.

    They still have to compare the claims with their own experience, identify hidden assumptions, notice contradictions, challenge weak reasoning and decide whether the model is actually useful. That takes time. More importantly, it takes qualified attention.

    AI can help produce more documents, or more incremental versions of the same documents. It does not automatically create more people willing and able to judge whether those documents deserve to be trusted.This changes the bottleneck.

    Previously, writing itself limited how much material could be produced. If creating a paper took months, review requests were naturally infrequent. Now drafting is cheaper. A paper can be improved repeatedly, and new versions can appear almost whenever a new insight emerges. That sounds positive. Until every small improvement is sent to the same colleagues for another serious review.

    The cost of producing the new version may have become low. The cost imposed on the reviewer has not. That creates a new responsibility for the writer. Cheap drafting should not lead to expensive review churn.

    I may revise a paper privately many times. I may collect new examples, conceptual distinctions, field observations and corrections in a backlog. But a new version should only be published when those changes together create a significant improvement.

    Not merely better wording. Not one extra paragraph. Not version 1.04 because I had another thought on Tuesday. A new review should be worth the attention it asks for.

    This suggests a simple structure. Field notes can remain the exploratory layer. They capture observations while they are fresh. Several notes may begin pointing in the same direction. The stable insight then enters the backlog for the relevant paper. Only when enough important changes have accumulated does the formal paper absorb them and become a genuinely new version.

    The production cycle becomes faster. The release discipline should become stricter. This applies far beyond my own papers.

    Organizations can now produce reports, proposals, strategies, requirements, policies and presentations at unprecedented speed. Much of it will be polished, plausible and professionally written. But polished language is not the same as sound reasoning. And increased output does not create increased capacity for careful judgment.

    The danger is not only that AI will produce poor documents. It is that it will produce more documents than anyone can seriously assess. The scarce resource is shifting from creation to judgment.

    The cost of producing documents has collapsed. The cost of deciding whether they deserve to be trusted has not.

  • Practice Note: A Product Reference Model Through the Eyes of an Enterprise Architect

    When I first began thinking about a Product Reference Model, I imagined it as something new. Over time, I have become less convinced that it is.

    Perhaps I have simply been rediscovering ideas that Enterprise Architecture has explored for decades—but applying them at a different scale and with a different objective. Enterprise Architects rarely begin with source code. They think about relationships. Business capabilities support strategic objectives. Applications realize capabilities. Technology supports applications. Information flows between systems. The architecture is not merely a collection of artifacts. It is the set of relationships that makes those artifacts meaningful.

    That sounds surprisingly familiar. My Product Reference Model has gradually evolved into something that also emphasizes relationships. Business objectives relate to capabilities. Capabilities relate to features. Features relate to requirements. Requirements relate to BDD scenarios. BDD scenarios relate to implementation. Implementation relates to architecture. Architecture relates to operational procedures. Assessments relate back to business outcomes. Rather than replacing individual artifacts, the Product Reference Model attempts to make those relationships explicit.

    Perhaps that is exactly what Enterprise Architecture has always tried to achieve—only at enterprise scale. If that is true, then perhaps the Product Reference Model should not be viewed as a competing framework. Instead, it may simply be Enterprise Architecture viewed through the lens of a single product.

    The emphasis is different. Enterprise Architecture asks:

    How does this product fit within the enterprise?

    The Product Reference Model asks:

    How does every important aspect of this product fit together?

    That distinction may appear subtle, but it changes the audience. Enterprise Architects often think across portfolios, organizations and technologies. Product Owners, developers, testers and operations engineers think about one product. The underlying architectural principles remain remarkably similar.

    What also changes is the purpose. Traditional Enterprise Architecture often focuses on describing structure. The Product Reference Model attempts to preserve understanding.

    Every relationship should ultimately help answer one of the questions future teams inevitably ask: Why does this capability exist? Why was this architectural decision made? Why is this business rule still here? Where is the evidence that this requirement is implemented? Which assessment concluded that this capability was fit for purpose? How do all these artifacts relate to one another?

    Perhaps the Product Reference Model is therefore less concerned with documenting a product than with making the product understandable.

    It becomes a navigational model rather than merely a descriptive one. That observation also changes my own perspective. Instead of inventing another framework, perhaps I should learn more from Enterprise Architecture. Architects have already spent decades thinking about repositories, viewpoints, traceability, relationships, stakeholders and governance.

    The Product Reference Model may simply extend those principles into the daily life of a product team. Its contribution would not be another modeling language. Its contribution would be placing product understanding at the center.

    Perhaps the Product Reference Model can therefore be described quite simply:

    The Product Reference Model applies Enterprise Architecture principles to a single product, with particular emphasis on preserving product understanding throughout the product’s lifecycle.

    If Enterprise Architecture asks how an enterprise remains coherent…

    …perhaps the Product Reference Model asks how a product remains understandable.

  • Practice Note: A Product Reference Model Through the Eyes of a Product Owner

    When I first began thinking about a Product Reference Model, I assumed it would become another documentation framework.

    As a Product Owner, that was not particularly attractive. Most Product Owners already spend their days balancing stakeholder expectations, refining the backlog, making priority decisions and answering questions from delivery teams. Another repository sounded like another responsibility.

    But perhaps that is the wrong way to think about it. As Product Owners, we rarely inherit a greenfield product. We inherit decisions. Business rules. Architecture. Operational procedures. Quality concerns. Technical debt. And, perhaps most importantly, we inherit understanding—or the absence of it.

    One of the most common questions a Product Owner asks is remarkably simple:

    Why?

    Why does this capability exist? Why do these customers receive different treatment? Why was this integration introduced? Why is this feature impossible to remove? Why was this architectural decision made? Why is this quality requirement so important?

    Those answers rarely exist in one place. Some are hidden in Jira. Some in architecture documentation. Some in source code. Some in BDD scenarios. Some in assessment reports. Many remain only in the memories of people who happened to be there.

    The Product Reference Model begins to make sense when it is no longer viewed as documentation. Instead, it becomes a map of product understanding. The Product Owner continues owning the backlog. Architects continue owning architecture. Developers continue owning source code. QA continues owning assessments and quality strategy. Operations continues owning operational knowledge.

    Nothing changes. Except that all these pieces become visible to one another. The Product Owner is no longer expected to know everything. The Product Owner is expected to know where the understanding lives.

    That changes the role in an important way. The backlog is no longer the product. It is merely one viewpoint of the product. The Product Reference Model allows the Product Owner to navigate the complete product landscape without becoming responsible for maintaining every artifact personally. Perhaps that is the real value.

    The Product Owner becomes the steward of product understanding rather than merely the owner of the backlog.

    Stewardship is different from ownership. Ownership often implies creating and maintaining artifacts. Stewardship means ensuring that future Product Owners inherit enough understanding to continue making good decisions.

    The Product Reference Model therefore does not make the Product Owner responsible for more documentation. It makes the Product Owner responsible for ensuring that the important answers remain connected. Perhaps continuity is not ultimately about preserving software. Perhaps it is about ensuring that every new Product Owner can understand the product they inherit before deciding how it should evolve.