Marcel van Oosterwijk

Category: Practice Notes

  • Practice Note: Transformation Is Not an Intervention

    A recent discussion about Agile transformation made me wonder whether “mindset shift” is really the right way to describe transformation.

    Mindset matters. But organizations do not transform simply because people start thinking differently.

    They transform when the organization becomes capable of behaving differently.

    And that changes how we should think about transformation itself.

    Introducing Change Is Not Transforming

    Organizations introduce new frameworks, methodologies, technologies, governance structures and operating models.

    They reorganize teams, establish new roles, implement tools and train employees.

    These activities may be necessary.

    But they are interventions, not transformations.

    An organization can adopt Agile terminology, introduce Scrum ceremonies and appoint Product Owners without becoming particularly capable of delivering value iteratively.

    It can migrate infrastructure to the cloud without becoming more adaptable.

    It can introduce AI tools without becoming better at using information or making decisions.

    The intervention has happened.

    But has the organizational capability changed?

    From Interventions to Capabilities

    Perhaps transformation should begin with a different question.

    Not “What should we introduce?”

    But “What must the organization become capable of doing?”

    That requires understanding the current capability, defining the desired capability and identifying what prevents the organization from achieving it.

    Only then can we determine which interventions might help.

    And those interventions rarely operate independently.

    Introducing a new development methodology may require changes in requirements management, architecture, governance, competence development and decision-making.

    Improving one practice without addressing the surrounding organizational mechanisms may accomplish surprisingly little.

    Transformation therefore becomes an exercise in orchestrating interventions toward a desired change in organizational capability.

    Did Anything Actually Change?

    There is another problem.

    Organizations often measure transformation through the completion of interventions.

    How many employees have been trained? How many teams have adopted the framework? Has the new operating model been implemented? Has the technology been deployed?

    These measures tell us whether activities have been completed.

    They do not necessarily tell us whether the organization has become more capable.

    To establish that, we need evidence.

    Can teams now make decisions they previously couldn’t? Can the organization respond more effectively to changing requirements? Can it deliver acceptable outcomes more reliably?

    And do these improvements persist after the transformation programme has ended?

    A temporary improvement achieved through extraordinary effort is not necessarily a sustained organizational capability.

    The transformation is not the framework, method or technology we introduce. It is the sustained change in organizational capability that those interventions produce.

    Transformation as a Learning Process

    This also suggests that transformation cannot simply be a predefined sequence of activities.

    We may have a clear understanding of the capability we want to develop, but we cannot always know in advance which interventions will produce the intended effects.

    We need to observe what happens.

    Did the intervention work? What changed? What remained unchanged? Did we discover new constraints or dependencies?

    The answers should influence what we do next.

    In that sense, transformation is an iterative learning process:

    Current capability → Desired capability → Interventions → Observed effects → Learning → Adjusted interventions.

    The interventions are hypotheses about how to develop the capability.

    Their effects provide evidence about whether those hypotheses were correct.

    And the transformation progresses as the organization uses that evidence to adjust its approach.

    What Are We Actually Transforming?

    Perhaps the most important question in any transformation initiative is deceptively simple:

    What will the organization be capable of doing afterward that it cannot do today?

    If we cannot answer that question, it becomes difficult to determine which interventions are necessary.

    And even harder to establish whether the transformation has succeeded.

    Because introducing change is relatively easy to observe.

    Establishing that the organization has become sustainably more capable is a different matter.

  • Practice Note: Tomorrow’s Questions Don’t Exist Yet

    We tend to preserve information because we believe someone might need it later.

    We write documentation, record decisions, create knowledge repositories and organize information so that it can be retrieved.

    But there’s a problem.

    We don’t know what questions people will ask in the future.

    And perhaps that should change how we think about preserving knowledge.

    A Question Nobody Could Have Anticipated

    Imagine AI had access to my complete photographic library.

    In 2040, I might ask:

    “Compare this photograph from 2009 with this one from 2030. How did my composition change?”

    Nobody could have prepared that answer in 2009.

    The question didn’t exist yet. Neither did half the evidence required to answer it.

    But because the photographs were preserved, the question can now be investigated.

    The photographs weren’t created to answer that particular question.

    They became useful because someone could relate them to evidence that emerged much later.

    Perhaps organizational knowledge works the same way.

    Preserving Answers or Preserving Evidence?

    Organizations accumulate enormous amounts of information.

    Documents, presentations, requirements, architectural decisions, source code, test results, incident reports and project deliverables.

    Much of this information is organized around the questions people were trying to answer when it was created.

    What should we build? How should we implement it? Did it work? What went wrong?

    But future questions may be entirely different.

    A consultant might want to compare approaches used across several projects.

    An architect might want to understand why a particular technology was selected.

    A quality manager might want to investigate whether recurring defects originate in weaknesses in organizational capabilities.

    Nobody necessarily anticipated these questions when the original information was created.

    And no single document may contain the answer.

    Understanding emerges from relating evidence that was created at different times, for different purposes.

    Making Knowledge Interrogable

    Recently, someone in a team chat asked whether colleagues had material that might help prepare a customer workshop.

    People responded with suggestions, questions and references to previous work.

    The knowledge existed.

    But the consultant still had to locate the material, understand its context and combine it into something useful.

    Then it struck me.

    The question was already a prompt.

    What if the consultant could ask the organization directly?

    “What relevant experience do we have?”

    “What approaches have we used?”

    “What problems did we encounter?”

    “Why is this project relevant?”

    “Show me the evidence.”

    AI could help make an organization’s accumulated knowledge interrogable.

    Not merely retrieving documents, but relating information across sources and helping construct answers to questions nobody anticipated when those sources were created.

    Of course, those answers must remain traceable to their sources.

    AI can help construct an interpretation. It should not become the authority for whether that interpretation is correct.

    Interrogating the Product

    Consider a consultant maintaining a software product in 2030.

    The original architect has retired.

    The consultant wants to know:

    “Why was this function built? Why Java? What tests cover it? What incidents has it caused? How is it actually used?”

    The answers may be scattered across requirements, architectural decisions, source history, tests, incident records and operational data.

    Perhaps nobody ever documented the complete explanation.

    But the evidence may still exist.

    And if it has been preserved, AI could help reconstruct the understanding.

    This suggests that preserving organizational knowledge is not simply about documenting what we currently know.

    It is also about preserving the possibility of understanding things we haven’t thought to ask about yet.

    Tomorrow’s Questions Don’t Exist Yet

    We cannot document every answer that future people might need.

    We don’t know their questions, their circumstances or what additional evidence will become available.

    But we can preserve the sources from which future understanding might emerge.

    That doesn’t mean keeping everything indefinitely. Information still needs context, provenance, appropriate retention policies and protection against becoming misleading or inaccessible.

    It means recognizing that the future value of information cannot always be determined by its immediate purpose.

    Perhaps AI changes the economics of organizational memory.

    Instead of requiring people to anticipate every future information need, we can increasingly preserve evidence and make it possible to interrogate that evidence when new questions arise.

    The Body of Knowledge supplies the material.

    AI helps relate it.

    Humans ask, challenge and judge.

    Because tomorrow’s questions don’t exist yet.

  • Practice Note: The Illusion of the Feedback Loop

    Most feedback loops aren’t loops.

    Imagine telling an employee in a supermarket that the price on the shelf doesn’t match the price at checkout.

    The employee apologizes. Perhaps they correct the price for you. They might even inform their supervisor.

    Problem solved?

    For you, perhaps.

    But will someone correct the shelf label? Will anyone investigate why the discrepancy occurred? And if it keeps happening, will the organization change anything?

    The organization has received feedback and responded to it.

    But has it learned anything?

    When Feedback Travels Backwards

    Organizations have developed countless mechanisms for collecting feedback.

    Customer complaints, retrospectives, quality metrics, incident reports, assessments and lessons learned.

    We collect information, discuss findings, make decisions and initiate improvement actions.

    We call these feedback loops.

    But information travelling backwards through an organization doesn’t automatically create a feedback loop.

    The information must be capable of influencing the subsequent behaviour of the system.

    That doesn’t mean every observation must result in a change. Sometimes feedback confirms that everything is working as intended.

    What matters is whether the system can respond when the evidence warrants it.

    Closing Actions Is Not Closing the Loop

    Consider an organization that identifies a recurring problem.

    An improvement action is agreed upon, assigned to someone and eventually marked as completed.

    The action has been closed.

    But did it solve the problem?

    Perhaps the intervention addressed a symptom rather than its cause. Perhaps it introduced new problems. Perhaps it worked in one situation but not in others.

    Unless someone evaluates the effect, the organization doesn’t actually know.

    And if the next occurrence of the problem leads to the same discussion and another improvement action, the organization may be repeating a process without learning from it.

    A feedback loop requires more than information and intervention.

    It requires evidence about the consequences of the intervention.

    Closing an action is not the same as closing a feedback loop.

    When Organizations Become Good at Responding

    There is an interesting paradox here.

    An organization can become highly effective at handling individual problems without becoming better at preventing them.

    Customer complaints are resolved quickly. Incidents are closed within agreed timeframes. Retrospectives produce action lists. Assessments generate improvement plans.

    Every mechanism appears to be working.

    Yet the same underlying problems continue to occur.

    The organization has optimized its ability to respond.

    But perhaps it hasn’t developed an equivalent ability to learn.

    This distinction matters because responding to a problem and changing the conditions that produced it are different capabilities.

    The first restores normal operations.

    The second improves the organization’s ability to operate.

    Both are valuable, but they shouldn’t be confused.

    Where Does the Loop Close?

    Perhaps we should evaluate feedback mechanisms differently.

    Instead of asking how much feedback we collect, how quickly we respond or how many actions we complete, we might ask:

    What can actually change as a result of this feedback?

    Can it challenge existing assumptions? Influence priorities? Change practices? Redirect investments? Improve organizational capabilities?

    And when something changes, do we evaluate whether the intended improvement was achieved?

    These questions concern more than the existence of feedback mechanisms.

    They concern the organization’s ability to use evidence to adapt its behaviour.

    Because a process doesn’t become a feedback loop merely because information travels backwards.

    Perhaps the loop doesn’t close when we act on feedback. It closes when we learn whether our response actually worked.

  • 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: Congratulations. You’re Now a Quality Manager.

    In a previous Practice Note, I suggested that AI agents might turn everyone into a team lead.

    You no longer need people reporting to you to have a team. You might have twenty AI agents performing work on your behalf.

    But there’s a problem.

    Having a team doesn’t mean you can trust its work.

    And when your team consists of AI agents, you may discover that you’ve acquired another responsibility.

    Congratulations. You’re now a Quality Manager.

    Delegating Work Is Easy. Trusting the Results Is Harder.

    Imagine you’re working with several AI agents.

    One investigates a problem. Another develops a solution. A third implements it. A fourth evaluates the result.

    Everything happens remarkably quickly.

    But how do you know whether the work is any good?

    The agents may produce convincing results. They may explain their reasoning, provide evidence and confidently report that their tasks are complete.

    They may also misunderstand the objective, overlook important constraints or make incorrect assumptions.

    You could review everything yourself.

    But if you have to repeat all the work to verify it, much of the benefit of delegation disappears.

    You need another approach.

    Welcome to Quality Management

    Before delegating work, you need to establish what you expect.

    What should be achieved? What constraints apply? What would constitute an acceptable result?

    You also need to decide how the work should be performed.

    Which activities can be delegated independently? Which require coordination? Where are the risks? What should be checked, and by whom?

    And once the work is complete, you need evidence that the results are acceptable.

    You might review deliverables, introduce automated checks, have agents evaluate each other’s work or require human approval for particularly important decisions.

    None of these mechanisms guarantees quality.

    But together, they can provide a more systematic basis for confidence.

    You’ve established expectations, organized work, managed risks and introduced mechanisms for evaluating results.

    Whether you intended to or not, you’re practicing Quality Management.

    Assessing Products and Capabilities

    There’s another distinction worth making.

    Suppose an agent produces an excellent result.

    Does that mean you can trust it to produce excellent results next time?

    Not necessarily.

    Evaluating an individual result tells you something about that result.

    It doesn’t necessarily tell you whether the agent can reliably produce similar results under different circumstances.

    For that, you need to understand the capability behind the result.

    Does the agent have access to the necessary information? Are its instructions adequate? Does it recognize situations it cannot handle? Are appropriate controls in place?

    You may discover that an agent produces good results only when given very specific instructions, or that it performs reliably for routine tasks but struggles with exceptions.

    This information helps you improve how work is delegated.

    And now you’re doing something beyond checking outputs.

    You’re assessing and developing the capability of your little AI organization.

    Quality Becomes Everyone’s Responsibility

    For decades, quality professionals have argued that quality cannot simply be delegated to a testing or quality assurance department.

    Quality depends on decisions and activities throughout the organization.

    Yet in practice, many professionals have been able to treat quality management as someone else’s responsibility.

    AI agents may change that.

    When you personally perform an activity, your expertise and experience provide some confidence in the result.

    When you delegate the activity to an agent, you need other ways to establish that confidence.

    You must become more explicit about expectations, evidence, risks and acceptance criteria.

    And as you delegate more work, you may need increasingly systematic mechanisms for managing its quality.

    Not because someone has introduced a new corporate quality initiative.

    But because you need to know whether you can trust the work being performed on your behalf.

    The Unexpected Quality Revolution

    We often discuss AI as a productivity revolution.

    People will produce more code, documents, analyses and decisions with less effort.

    Perhaps.

    But the more interesting development may be what happens to our responsibilities.

    As execution becomes easier to delegate, defining objectives, evaluating evidence and exercising judgment become increasingly important.

    And those are fundamental concerns of Quality Management.

    Perhaps AI will accomplish something that decades of quality professionals have struggled to achieve.

    It may make Quality Management everyone’s business.

    Not because we’ve finally convinced everyone of its importance.

    But because everyone suddenly needs it.