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 Organizations Cannot Use What They Know

    Organizations invest heavily in competence. They recruit specialists, establish communities of practice, develop methodologies and create dedicated functions to support delivery.

    But possessing competence and being able to use it are two different things.

    What if an organization’s greatest capability problem is its inability to make effective use of the capabilities it already possesses?

    A Project in Trouble

    Consider a software development project with more than ten predominantly junior developers, supported by one or two experienced leads.

    Testing is performed by a couple of QA specialists. Developers perform little meaningful testing themselves, and test automation is largely absent.

    As development progresses, testing becomes a bottleneck. Defects accumulate, regression effort grows, and delivery falls behind schedule.

    Management decides to add resources.

    Another developer seems the obvious choice. After all, the project is behind on software development.

    But additional developers produce more work requiring testing, while increasing the coordination and mentoring burden.

    What if another tester would improve delivery throughput more than another developer?

    Why does increasing development capacity seem like the natural response to delivery problems, while increasing testing capacity requires special justification?

    Perhaps the organization is managing the production of code rather than the delivery of acceptable functionality.

    Development capacity is not the same as delivery capability.

    When Knowledge Cannot Influence Decisions

    The people working in the project recognize problems and develop ideas for improvement.

    They may even discuss these in agile retrospectives.

    But if staffing, priorities and practices are decided elsewhere, what can they actually change?

    The organization has implemented the ceremony of continuous improvement without necessarily establishing the conditions that make improvement possible.

    It has competence, information about its problems, and people willing to address them.

    But the knowledge has no effective path to action.

    Suppose management responds by adding more developers.

    Testing becomes an even greater bottleneck. Coordination overhead increases. Defects and rework consume more time.

    The project falls further behind.

    More resources are added.

    The organization has monitored progress, recognized problems and taken action.

    Yet its interventions have reinforced the conditions responsible for poor delivery.

    And if the next project follows the same pattern, what has the organization learned?

    An organization can be highly responsive to problems while remaining remarkably incapable of learning from them.

    The Missing Capability

    Perhaps organizational knowledge management needs to distinguish between three things:

    • Possessing knowledge: Having people who understand relevant problems and mechanisms.
    • Sharing knowledge: Making their observations and expertise available.
    • Using knowledge: Enabling that knowledge to influence decisions, interventions and organizational behaviour.

    Organizations invest considerable effort in the first two.

    But the third requires more than documentation, communication and knowledge-sharing activities.

    It requires mechanisms for recognizing evidence, mobilizing expertise, challenging assumptions, authorizing interventions and evaluating their effects.

    This is itself an organizational capability.

    And like other capabilities, it can be assessed and developed.

    The relevant evidence would not be the number of retrospectives conducted, lessons learned documented or improvement initiatives launched.

    It would be whether those activities actually influence how the organization operates.

    Because an organization can be full of competent people and still make systematically poor decisions.

    Perhaps the knowledge required to improve already exists.

    The question is whether the organization is capable of acting on what it knows.

  • Practice Note: Everyone Becomes a Team Lead

    Until recently, becoming a team lead usually meant being given responsibility for other people.

    Now you can become a team lead without having a single person reporting to you.

    You might have twenty AI agents instead.

    The question is no longer just whether you can do the work.

    It’s whether you can organize, direct and assure the work of others.

    From Doing Work to Directing Work

    Consider a software developer.

    Traditionally, the developer writes code, investigates problems, implements changes and tests the results.

    With AI agents, the developer might delegate these activities.

    One agent investigates a defect. Another proposes a solution. A third implements it. A fourth develops tests.

    Meanwhile, the developer coordinates their activities, evaluates their results and decides what happens next.

    The work hasn’t disappeared.

    But the developer’s role has changed.

    Instead of performing every activity personally, the developer is increasingly responsible for organizing work performed by others.

    And that requires a somewhat different set of skills.

    The New Team

    Managing a team involves more than assigning tasks.

    Someone must establish objectives, explain expectations, distribute responsibilities, coordinate dependencies and evaluate results.

    These responsibilities don’t disappear because the team members happen to be AI agents.

    In some respects, they become more important.

    An AI agent may produce a convincing result without having understood the objective.

    It may make assumptions that were never agreed upon, overlook relevant constraints or optimize something that wasn’t particularly important.

    And unlike a human colleague, it may not recognize when it should challenge the assignment.

    Giving an agent a task is therefore not necessarily the same as ensuring that the task is understood.

    The person directing the work must provide sufficient context, establish boundaries and determine how the result will be evaluated.

    That sounds remarkably like management.

    Delegating Work, Not Accountability

    There is another interesting consequence.

    When you perform work yourself, you develop an understanding of it through the process of doing it.

    You encounter difficulties, make decisions, discover assumptions and gradually build confidence in the result.

    When an agent performs the work, much of that experience is no longer yours.

    You receive the result without necessarily having experienced the reasoning and decisions that produced it.

    This creates a challenge.

    How do you know whether the work is good?

    You might review the result yourself. You might ask another agent to evaluate it. You might establish automated checks or require evidence supporting particular conclusions.

    But none of these mechanisms removes the need for judgment.

    An agent reviewing another agent’s work may simply reproduce the same misunderstanding.

    And a result that satisfies every predefined check may still fail to achieve its intended purpose.

    The responsibility for deciding whether the work is acceptable remains with the person directing it.

    We can delegate execution much more easily than we can delegate accountability.

    The Importance of Knowing What Good Looks Like

    This raises a question about professional competence.

    If an AI agent can perform an activity better or faster than you can, do you still need to understand that activity?

    Perhaps not to the same depth.

    But you do need sufficient understanding to establish meaningful expectations and evaluate the outcome.

    A team lead doesn’t necessarily need to be the best programmer, architect or tester on the team.

    But they need to understand enough about the work to organize it, recognize problems and make informed decisions.

    The same applies when the team consists of AI agents.

    In fact, the ability to define what good looks like may become more important than the ability to produce it personally.

    This doesn’t eliminate professional expertise.

    It changes where that expertise creates value.

    Everyone Becomes a Team Lead

    We often discuss AI in terms of productivity.

    How much faster can someone write code, produce documents, analyze information or prepare presentations?

    But perhaps productivity is only part of the story.

    AI agents allow individuals to coordinate work that previously required several people.

    A consultant might direct agents conducting research, analyzing evidence, developing recommendations and preparing deliverables.

    A tester might coordinate agents generating test ideas, executing checks, investigating failures and documenting findings.

    A manager might use agents to collect information, monitor developments and prepare decisions.

    In each case, the individual becomes responsible for a small system of delegated work.

    And the effectiveness of that system depends increasingly on their ability to direct and assure it.

    Perhaps we should therefore think differently about AI competence.

    Learning to use an AI tool is useful.

    Learning to manage work performed by AI agents may be considerably more important.

    Because when everyone can have a team, everyone needs to learn something about leading one.

    The future professional may not be the person who can do the most work, but the person who can make the most work happen — without losing control of its quality.

  • Practice Note: How Testing Became Quality Management Without Leaving Testing Behind

    Testing has changed considerably over the years.

    What once focused primarily on evaluating software products has expanded into test automation, quality assurance, quality engineering, process improvement, and increasingly organizational capability development.

    We have moved upstream, becoming involved in requirements, architecture, development practices, and organizational ways of working.

    Yet we still tend to describe much of this work as testing.

    Perhaps we have expanded the discipline without reconsidering what the discipline has become.

    Following Quality Upstream

    Testing provides information about products.

    When something doesn’t work as expected, testing helps us discover it, investigate it, and understand its consequences.

    But many problems discovered through testing originate elsewhere.

    Ambiguous requirements, architectural decisions, inadequate development practices, or insufficient organizational capabilities may all become visible through testing.

    Improving testing alone does not necessarily address these problems.

    So we started moving upstream.

    We became involved in requirements reviews, development practices, risk management, process improvement, and eventually organizational assessments.

    The underlying motivation remained the same: improving our ability to achieve quality.

    But the subject of our attention gradually changed.

    We were no longer concerned only with evaluating products. We were increasingly concerned with understanding and improving the organizational mechanisms that produce them.

    From Testing to Quality Management

    This development introduced a collection of overlapping concepts.

    Quality Assurance, Quality Control, Quality Engineering, Test Management, and Quality Management are frequently used in ways that make their responsibilities difficult to distinguish.

    Perhaps the problem is not primarily terminology.

    Perhaps we have been trying to accommodate an increasingly broad set of responsibilities within a discipline originally organized around testing.

    A useful distinction might be:

    • Testing investigates products and provides evidence about their behaviour and characteristics.
    • Quality Control evaluates whether products satisfy relevant quality expectations.
    • Quality Assurance provides confidence that the ways of working used to achieve quality are adequate.
    • Quality Engineering develops and applies engineering practices that help achieve quality.
    • Quality Management provides the organizational mechanisms for directing, evaluating, and improving the ability to achieve quality.

    These are not necessarily competing disciplines.

    They address different aspects of the same challenge.

    And testing remains an essential part of that challenge.

    Assessing More Than Products

    Organizations routinely evaluate their products.

    They test software, inspect deliverables, monitor performance, and investigate defects.

    But how systematically do they evaluate the organizational capabilities responsible for producing those products?

    When testing repeatedly reveals poor requirements, do we assess the organization’s requirements engineering capability?

    When defects originate in architectural decisions, do we examine the architecture capability?

    When problems recur across projects, do we investigate the organizational mechanisms that should enable learning and improvement?

    Often, we address the immediate problem without systematically evaluating the capability behind it.

    This suggests an interesting extension of Quality Management.

    Just as product assessment provides evidence about products, capability assessment could provide evidence about the organization’s ability to achieve intended outcomes.

    And just as product development responds to findings about products, capability development could respond to findings about organizational capabilities.

    Quality Management would then concern itself not only with whether quality is achieved, but also with whether the organization has the capabilities required to achieve it repeatedly.

    Without Leaving Testing Behind

    None of this makes testing less important.

    Testing remains one of our most valuable sources of evidence about whether products behave as intended.

    It also provides an important perspective on the consequences of decisions made elsewhere.

    But testing cannot compensate indefinitely for weaknesses throughout the organization.

    Nor should it be expected to.

    Moving upstream does not mean abandoning testing. It means recognizing that the information testing provides can lead us toward questions that testing alone cannot answer.

    And perhaps that is how testing gradually led us toward Quality Management.

    Not because testing became something else, but because understanding quality required us to look beyond testing.

    Quality is created throughout the organization. Quality Management makes that creation intentional, coordinated, and improvable.

  • Practice Note: When the KPI Prevents the Capability

    Organizations often have ambitions to develop their capabilities.

    They establish communities of practice, appoint capability owners, develop methodologies, and encourage knowledge sharing.

    At the same time, they may measure individual performance through KPIs that actively discourage these activities.

    Consider a consulting organization.

    A consultant who spends all their available time delivering to customers performs well according to utilization metrics.

    Another consultant spends part of that time developing methodologies, mentoring colleagues, or creating reusable knowledge.

    The first generates more directly attributable revenue.

    The second may be contributing more to the organization’s future ability to generate revenue.

    Yet according to the KPI, the first consultant is performing better.

    Measuring the Wrong Contribution

    There is nothing inherently wrong with measuring utilization. Consulting organizations depend on billable work.

    The problem arises when a metric designed to measure one aspect of performance becomes a general measure of individual contribution.

    Utilization measures billable time. It does not measure the value someone creates for the organization.

    A consultant delivering an assignment creates value through their own work.

    A consultant developing an approach that enables twenty colleagues to deliver better assignments creates value through the work of others.

    The latter contribution may be substantially greater, but it is harder to observe, attribute, and measure.

    And what is difficult to measure is often difficult to reward.

    The Capability Paradox

    Capability development requires investment.

    Someone must examine existing practices, identify improvements, develop better approaches, and help others adopt them.

    All of this takes time that could otherwise have been spent on billable work.

    The organization wants its capabilities to improve, but evaluates the people responsible according to criteria that reward them for spending their time elsewhere.

    Capability development becomes something to do when there is time left over.

    And in an organization optimizing utilization, there may be very little time left over.

    The organization has made capability development dependent on the availability of a resource it is simultaneously trying to eliminate: unused capacity.

    The resulting behaviour is entirely predictable.

    Yet the organization may interpret the lack of capability development as insufficient engagement, ownership, or initiative.

    Perhaps people are simply responding exactly as the organization has instructed them to.

    From Productivity to Leverage

    Individual productivity concerns what someone accomplishes through their own work.

    Organizational capability concerns what the organization can accomplish repeatedly, independently of particular individuals.

    Developing that capability means making knowledge, methods, and practices available beyond their original creators.

    Its value is often indirect, distributed, and delayed.

    A methodology developed today may improve dozens of assignments over several years.

    But those improvements will appear in the performance of the consultants using it, not necessarily in the performance indicators of the person who developed it.

    The organization benefits without necessarily recognizing where the benefit originated.

    If we measure individual contribution primarily through direct output, how do we recognize contributions that improve the output of others?

    What Are We Actually Optimizing?

    The obvious response might be to introduce additional KPIs for capability development.

    But counting methodologies, knowledge-sharing sessions, or reusable assets does not necessarily tell us whether organizational capabilities have improved.

    We would simply be measuring more activities.

    Perhaps the more important question is whether the organization’s management mechanisms support what it is trying to achieve.

    Maximizing utilization and developing organizational capability are different objectives. They compete for the same resources, and the organization must decide how to balance them.

    That balance cannot be established through strategic declarations alone. It must be reflected in how work is prioritized, capacity is allocated, and contributions are evaluated.

    Otherwise, capability development remains an ambition that the organization’s own management system works against.

    Perhaps the question is not whether we have the right KPIs, but whether we understand what our KPIs are preventing us from achieving.

  • Exploration: What Happens to the Knowledge Worker When AI Removes the Bottlenecks?

    I learned something useful from performance testing many years ago. When you remove a bottleneck from a system, another bottleneck usually appears.

    That does not mean the optimization failed. The performance of the whole system has increased. The next constraint simply became visible because the previous one no longer dominated.

    I wonder if this is a useful way to think about AI and knowledge work.

    Much of knowledge work is built around expensive activities: finding information, reading it, comparing it, writing, analyzing, programming, documenting, communicating and reviewing. Organizations have developed roles, processes, queues and handovers around those constraints.

    AI is now reducing the cost of several of those activities at once. The obvious conclusion is that fewer people will be needed. That may be true in some cases. But another possibility is that the bottleneck simply moves.

    If software implementation becomes dramatically faster, development capacity may stop being the main constraint. Then other constraints become more visible: deciding what is worth building, understanding customer needs, integrating changes, assuring quality, absorbing change in operations, or learning from what actually happens after release.

    The system may still become much faster overall. That matters because a role is not the same thing as the activities currently associated with it. A Product Manager may spend a lot of time managing a backlog because implementation capacity is scarce. A technical writer may spend a lot of time producing documents because creating and maintaining representations is expensive. A Quality Manager may spend a lot of time collecting and summarizing evidence because that work is slow and fragmented.

    If AI removes those frictions, the activity may shrink without the underlying function disappearing.

    That raises a more interesting question:

    If AI can perform many of the activities associated with a profession, were those activities actually the function of the profession, or merely the mechanisms through which that function happened to be realized?

    For a Product Manager, the deeper function may be understanding context and deciding what should change and why. For a technical writer, it may be preserving and making technical understanding available. For a Quality Manager, it may be maintaining enough understanding of quality, risk and evidence for the organization to make informed decisions. AI may therefore push roles upstream toward their underlying purpose.

    There is also another effect: when something becomes cheaper, we often use more of it.

    If software becomes cheaper to build, more software may become economically viable. If analysis becomes cheap, questions that were never worth investigating may suddenly be worth answering. If quality evidence can be gathered continuously, assurance may expand rather than simply become cheaper.

    So the future may not be today’s amount of knowledge work performed by fewer people.

    It may be far more knowledge work being performed, with different constraints determining where human attention is most valuable.

    And that is where the performance-testing analogy becomes useful again.

    The next bottleneck might be judgment. Or trusted evidence. Or customer attention. Or organizational ability to absorb change. Or something AI will also reduce later.

    The important thing is that removing one constraint does not tell us that the system is finished. It tells us where to look next.

    So perhaps the more useful question is not:

    Will AI replace the knowledge worker?

    But:

    Which bottlenecks currently shape this role, what happens when AI removes them, and what function remains when the old mechanisms are no longer necessary?