Organizations constantly invest in improving capabilities. Testing becomes inconsistent, so an improvement initiative is launched. Requirements quality declines, so new templates, training and governance are introduced. Architecture loses direction, so a maturity program begins. Security, DevOps, business analysis and many other disciplines follow the same pattern.
The sequence is familiar. A problem is identified, an assessment is performed, interventions are designed, people are trained, practices are changed, tools are introduced and new ways of working are established.
Eventually the initiative ends. The consultants leave. The project team dissolves. The transformation roadmap is closed. Everyone returns to normal work.
A few years later, the same capability is often under discussion again. Testing has become inconsistent. Requirements quality has deteriorated. Architectural direction has weakened. Another maturity initiative is needed.
This raises a simple question. Perhaps capability improvement is not the same thing as capability management.
Improvement Has an End Date
Improvement initiatives are temporary by design. They exist because the organization has identified a gap between its current ability and the ability it believes it needs. Their purpose is to create change.
That makes them valuable, but it also gives them a natural ending. Once the new practices have been introduced, the training delivered and the immediate objectives achieved, the initiative can reasonably be considered complete.
The capability, however, is not complete. The environment continues to change. New technologies appear. People leave. New people join. Products evolve. Business priorities shift. Practices that once worked well become less appropriate. Dependencies on neighboring capabilities change. Lessons accumulate. Organizational ability therefore continues to evolve long after the improvement project has ended.
Improvement projects change organizations.
Capability Management sustains organizational ability.
Those are different responsibilities.
What Happens After Improvement?
Organizations often recognize this problem informally. When testing becomes a recurring concern, someone eventually hears:
“You are now responsible for testing.”
The intention is sensible. Somebody should make sure the organization does not lose what it has just improved. But the statement hides a difficult question. What exactly has that person become responsible for? The testing process? Testing tools? Competence development? Communities of practice? Governance? Quality assurance? Hiring? Methodology?
Trying to answer the question by listing artifacts and activities quickly becomes problematic, because none of them is the capability itself. A capability is the organizational ability that those arrangements collectively enable.
The more useful responsibility may therefore be neither ownership of a process nor control of every specialist activity. It may be stewardship of the organizational ability.
Managing the Capability, Not Its Realization
A capability can be realized in many different ways. Practices can change. Tools can change. Organizational structures can change. Governance can become more or less formal. Responsibilities can move between teams. New technologies may make previously important activities unnecessary. If a Capability Management becomes attached too strongly to one of those realizations, it risks preserving the current solution rather than the underlying ability.
The responsibility should instead remain connected to the capability itself. What organizational ability do we need? Why do we need it? Under which conditions must it work? What evidence tells us that the ability actually exists? Where is it becoming weaker? What changes in the environment require it to evolve? What have recent experiences taught us?
Those questions operate on a longer timescale than an improvement project. They concern continuity.
A Parallel with Product Management
This begins to resemble Product Management. Product Management does not need to own every specialist discipline contributing to a product. Architecture remains architecture. Engineering remains engineering. Testing remains testing. Operations remains operations.
What Product Management provides is continuity around the product itself. It maintains the connection between why the product exists, what it needs to become, what is currently being built, what evidence returns from use and what should change next. Specialist knowledge remains distributed, but the subject does not disappear between projects.
Organizational capabilities may require something similar. Capability Management would not replace the specialists who realize the capability. It would maintain continuity around the capability while those specialists continue to contribute their expertise.
That is a different proposition from appointing someone to “own testing.” It suggests a management discipline rather than merely a role.
When Nobody Manages the Capability
The absence of such stewardship may help explain another recurring pattern. Capabilities often expand into neighboring areas. Testing begins improving requirements because poor requirements make testing difficult. Architecture becomes involved in operational concerns because architectural decisions repeatedly create operational problems. Security begins governing development practices because insecure development creates security risk.
These interventions may be entirely reasonable. Capabilities are interdependent, and specialists should influence the conditions that affect their ability to succeed.
But there is an important difference between influence and accidental ownership. Testing should be able to challenge weak requirements. That does not necessarily mean Testing should become responsible for Requirements Engineering. Security should influence development practices. That does not automatically mean Security should become the organization’s steward of software engineering.
When nobody is responsible for maintaining a capability over time, the consequences of its weakness do not remain contained. They appear elsewhere, and another capability begins compensating for the gap. The vacuum does not stay empty.
From Influence to Accidental Ownership
This distinction becomes useful because capability boundaries are rarely clean. Testing depends on requirements. Architecture depends on product direction. Security depends on engineering practices. Operations depends on architecture. Product Management depends on business analysis.
Capability Management should therefore not attempt to isolate capabilities from one another. It should make the dependencies visible and preserve appropriate responsibility across them.
One capability may legitimately influence another. It may identify weaknesses, provide evidence, recommend changes or participate in improvement. But influence should not silently become permanent stewardship simply because nobody else is holding the responsibility. Otherwise organizational capabilities can gradually absorb one another’s problems until their boundaries become difficult to understand.
Improvement Becomes Part of a Longer Lifecycle
Seen this way, capability improvement becomes one activity within a longer lifecycle. An assessment may reveal that the current capability is insufficient. Capability Management helps interpret what that means for the future. A transformation or improvement initiative may then introduce deliberate changes. Reassessment provides evidence about whether those changes actually improved the organizational ability.
But once the intervention ends, Capability Management continues. It preserves the intent, observes the realized capability, incorporates learning and determines when further development is needed.
The lifecycle therefore does not end with transformation. It continues through stewardship.
Capability Ownership as a Realization
This also changes how the idea of a Capability Owner should be understood. If Capability Management is the discipline, a Capability Owner is one possible organizational realization of it. In some organizations, one person may hold that responsibility explicitly. In others, it may be distributed across a leadership group, community or existing management role. Different capabilities may require different arrangements. The organizational design is secondary. What matters is that somebody, or some mechanism, maintains continuity of the capability.
The responsibility is not necessarily to own every process, document, specialist or decision associated with the capability. It is to ensure that the organization continues to possess and deliberately develop the required ability. That is a much more durable responsibility.
A Portfolio of Capabilities
Once individual capabilities are viewed this way, another level becomes visible. Organizations possess many capabilities. Testing, Requirements Engineering, Architecture, Security, Business Analysis, Product Management, Data Management and countless others coexist and depend on one another.
Each may be strong or weak. Each may evolve at a different pace. Each may compensate for gaps elsewhere. Each consumes investment and management attention. This begins to look less like a collection of isolated improvement disciplines and more like a portfolio of organizational capabilities.
Capability Management concerns the continuity of an individual capability while Capability Portfolio Management would ask a different question: whether the organization possesses the right capabilities, in the right relationships, for what it is trying to accomplish.
That is a broader question and deserves treatment of its own. But it reinforces the same point: capabilities are not merely things organizations improve when they become problematic. They are organizational assets that require ongoing stewardship.
Reflection
Organizations are often quite good at launching capability improvement initiatives. They are less consistent at preserving responsibility once the initiative has done its work. That may be why the same capability problems return in cycles. The intervention succeeds, but continuity remains weak.
If that is true, then the missing discipline is not another improvement method. It is the management of organizational ability between improvements.
Assessment tells us where the capability is. Transformation helps change it. Capability Management ensures that somebody continues asking where it needs to go next.
Improvement projects change organizations.
Capability Management sustains organizational ability.
Leave a Reply