Marcel van Oosterwijk

Category: Knowledge & AI

How knowledge and understanding are created, represented, preserved, synthesized, transferred, and developed, including the changing role of AI in knowledge work.

  • Practice Note: Let’s Put the Secretary Back in Our Meetings

    Once upon a time, important meetings had secretaries.

    They prepared agendas, recorded decisions, documented commitments and helped ensure that one meeting could build on another.

    Of course, not everyone was important enough to have a secretary.

    The boss’s meetings had a secretary. The rest of us had to manage our own meetings.

    And somehow, we ended up with calendars full of meetings without clear purposes, agendas, decisions or minutes.

    We saved money on secretaries.

    I’m not entirely convinced we saved money.

    What Did the Secretary Actually Do?

    Meeting minutes weren’t simply records of what was said.

    They preserved decisions, established accountability and provided continuity.

    What did we decide last time? Why? Who was supposed to do what? What remained unresolved?

    Secretaries also helped organize meetings, prepare material and follow up on commitments.

    When dedicated secretarial support became less common, those responsibilities didn’t disappear. They were redistributed to professionals who weren’t necessarily trained to perform them.

    The meeting organizer became the implicit chairperson. Someone was expected to take minutes. Sometimes nobody did.

    Meanwhile, eight highly paid professionals could spend an hour in a meeting without a clear purpose, only to schedule another meeting because nothing was decided.

    We eliminated an identifiable cost while accepting a distributed one.

    Meet Ada, Our New AI Secretary

    Now imagine everyone could have a secretary.

    An AI secretary.

    Let’s call her Ada.

    Ada could help prepare agendas, record decisions, identify actions and keep track of unresolved questions.

    She could remind us what happened last time and help us prepare for the next meeting.

    Afterward, she could produce meeting minutes for participants to review and confirm.

    This isn’t science fiction. Tools such as Microsoft Teams, Zoom and AI-powered transcription services already provide much of the necessary functionality.

    What’s changed is the economics.

    We can now make secretarial support available to meetings that could never justify dedicating another person to them.

    And Ada isn’t a particular product. She represents a role that different AI services can fulfill.

    Why Stop at Important Meetings?

    Consider one-to-one conversations, sales meetings, requirements refinement sessions or incident investigations.

    These activities produce knowledge: expectations, assumptions, observations, decisions and commitments.

    Yet much of it disappears when the conversation ends.

    Ada could help preserve it.

    And why stop at conversations?

    Consider exploratory software testing.

    A tester investigates a system, observes its behaviour, develops hypotheses and follows interesting leads.

    Documenting the investigation interrupts it.

    Now imagine Ada observing the screen while listening to the tester explain what they’re investigating.

    “That’s strange. I expected the customer status to change after saving, but it didn’t. Let’s try changing the account type first.”

    Ada could associate that observation with the relevant screen state, actions and subsequent results.

    Instead of merely recording a conversation, she helps preserve the investigation: what was attempted, what was observed, why it mattered and what happened next.

    The tester remains responsible for interpreting the results.

    Ada takes care of much of the documentation.

    From Meeting Minutes to Organizational Memory

    Now imagine that Ada’s records don’t simply become documents stored somewhere.

    They contribute to an accessible body of organizational knowledge.

    Decisions remain connected to their rationale. Investigations remain connected to their evidence. Observations remain available for future work.

    People could ask:

    Why did we choose this solution?

    Have we encountered this problem before?

    What did we learn last time?

    Of course, Ada needs some guidance.

    Like any secretary, she needs to understand what matters, what to document and what to leave out. We can coach her by reviewing her work and providing feedback.

    She also needs to respect privacy and confidentiality. Participants should know when she’s present, and unnecessary recordings or personal details shouldn’t be retained. Her minutes should capture the substance of discussions rather than reproduce every word.

    The goal isn’t to record everything.

    It’s to preserve what matters.

    Let’s Give Everyone a Secretary

    Ada won’t automatically make meetings productive.

    A meeting without a purpose doesn’t become useful simply because someone writes excellent minutes.

    But she could make good meeting practices easier to follow, reduce the administrative burden on participants and preserve information that would otherwise be lost.

    So here’s a suggestion.

    At your next meeting, bring Ada.

    Use your phone, Teams, Zoom or whichever AI transcription service your organization supports.

    Make sure participants are informed and the service is appropriate for the conversation.

    Let everyone concentrate on the discussion while Ada takes the notes.

    Review the minutes, confirm the decisions and agree on the actions.

    Give Ada feedback. Tell her what to do differently next time.

    And wherever appropriate, make this your default way of working.

    Let’s put the secretary back in our meetings.

    This time, let’s give everyone one.

  • Practice Note: The Death of PowerPoint

    We learned to eliminate the bullets. Perhaps it’s time to eliminate PowerPoint altogether.

    For years, we’ve been told that PowerPoint presentations are killing our meetings.

    Too many slides. Too much text. Too many bullet points.

    Death by PowerPoint.

    So we learned to make better presentations. We reduced the number of bullets, introduced visual storytelling, and encouraged presenters to engage their audiences.

    But perhaps we’ve been solving the wrong problem.

    What if the problem isn’t how we use PowerPoint, but that we’re using PowerPoint in the first place?

    The Meeting That Could Have Been a Document

    Consider a typical management meeting.

    A group of experienced professionals gathers around a table. Someone opens a PowerPoint presentation and starts explaining what everyone needs to know.

    For the next 30 minutes, the participants listen. Or at least pretend to.

    Some already know the material. Others struggle to follow. A few are checking their emails.

    Then, with ten minutes remaining, the presenter reaches the final slide:

    Questions?

    And that’s when the meeting could finally become interesting.

    Unfortunately, we’re almost out of time.

    We’ve spent most of our collective time transferring information and left very little for actually doing something with it.

    What If We Started by Reading?

    Jeff Bezos once described an alternative approach used at Amazon.

    Instead of PowerPoint presentations, meeting organizers prepare written narratives, often six pages long.

    At the beginning of the meeting, everyone reads the document silently.

    Yes, silently. Like in a classroom.

    The reason is refreshingly pragmatic: if you send material beforehand, some people will read it and others won’t.

    So instead of pretending everyone has prepared, the meeting begins by ensuring that everyone actually has.

    Then the discussion starts.

    And here’s the important difference:

    The meeting isn’t used to present the information. It’s used to think about it.

    PowerPoint Makes It Too Easy

    There is another problem with PowerPoint.

    It makes it remarkably easy to create the appearance of structured thinking.

    Put five statements on a slide. Add a heading. Perhaps an arrow or two.

    Suddenly, it looks like an argument.

    But are the statements actually related? Does one support another? Are there assumptions between them? Is there evidence?

    A PowerPoint slide doesn’t necessarily require us to answer those questions.

    Writing a coherent narrative does.

    You cannot simply place five unrelated statements next to each other and assume that the reader will construct the reasoning for you.

    Well, you can. But it becomes much more obvious that something is missing.

    PowerPoint helps us organize information. Writing forces us to organize our thinking.

    That’s an important distinction.

    Stop Fixing the Audience

    When people lose attention during presentations, we often blame the audience.

    People have short attention spans. They check their phones. They multitask. They don’t prepare.

    So we introduce meeting rules.

    Close your laptops. Put away your phones. Pay attention.

    But what if the audience isn’t the problem?

    What if we’ve designed a meeting that requires people to remain passive for 45 minutes, and then complain when they behave like passive participants?

    The Amazon approach doesn’t solve this by demanding better behaviour.

    It changes the mechanism.

    Everyone reads. Everyone starts with the same information. Everyone can participate in the discussion.

    Instead of trying to make people pay attention to a poorly designed process, redesign the process to make their attention useful.

    Kill the Presentation, Not the Discussion

    Of course, there are situations where presentations are valuable.

    A visual demonstration. A compelling story. An explanation that genuinely benefits from images, diagrams, or animation.

    But how often is that what we’re actually doing?

    How often are we simply displaying information on a screen while someone reads or paraphrases it?

    And why do we need ten people sitting in a room to watch someone do that?

    If the purpose is to distribute information, distribute it.

    If the purpose is to make a decision, provide the evidence and create the conditions for discussion.

    If the purpose is to solve a problem, bring people together to solve it.

    Stop confusing presenting information with working together.

    The Death of PowerPoint?

    Perhaps PowerPoint doesn’t need to die.

    But its position as the default mechanism for meetings probably should.

    We’ve spent decades improving our presentations.

    Perhaps it’s time to improve what happens instead of presenting.

    And that starts with a rather uncomfortable question:

    If we removed PowerPoint from tomorrow’s management meeting, what would we actually do with the time?

    If the answer is think, discuss, challenge assumptions, and make decisions, perhaps we should have killed it years ago.

  • 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?

  • Practice Note: When AI Removes the Implementation Friction

    Several years ago, I started experimenting with controlling a model railway through a Roco Z21 command station.

    Looking back, I was really trying to solve three problems at once.

    I wanted to show that coding could be easy and fun by using it to control something physical. I wanted to make a complicated German-language protocol specification more accessible to an international audience by explaining it in English. And I wanted to learn Python and refresh my own coding skills.

    That meant implementing the Z21 protocol was not just scaffolding.

    It was part of the purpose of the exercise.

    My first experiment was simple: retrieve the Z21 serial number. But even that meant understanding the protocol, byte ordering and UDP communication, then translating all of it into Python.

    As the project grew, so did the scaffolding. Incoming packets could contain multiple messages, so I needed to split them. Different messages needed dispatching. Some information arrived asynchronously. Feedback modules reported track occupancy. Locomotive control introduced another protocol carried through the Z21 protocol.

    Along the way I also started experimenting with functional programming, refactoring, behavioral examples and automated tests.

    All of that was useful. But I was simultaneously learning the protocol, learning Python, designing the software, debugging it, documenting it and trying to automate a railway.

    Returning to the same problem

    Several years later, I came back to the project.

    The railway has not fundamentally changed. Neither has the protocol.

    The development environment has.

    Today I can give AI the Z21 protocol specification and ask how to retrieve the serial number. It can find the relevant section, interpret it, explain the request and response and produce a candidate implementation.

    But code generation is only a small part of what changed.

    I could also give AI my old implementations. It found bugs in code I had written, compared my interpretation with the specification, suggested improvements and helped reconstruct what I had been trying to do.

    Where I had previously become stuck, it could suggest possible ways forward.

    When I wanted to develop without depending on the physical command station, it helped design a small Z21 simulator over UDP on localhost.

    When I wanted to return to automated testing, it could help translate acceptance criteria into Python unittest tests.

    And when an answer looked questionable, I could challenge it.

    That matters. AI was not always right. I corrected its reconstruction of the history of some of my old experiments, and I questioned its interpretation of parts of the protocol.

    The point is not that AI provides trustworthy answers automatically.

    The point is that it removes a great deal of friction.

    Three problems that largely disappeared

    The contrast with the original project is striking.

    Previously, I wanted to make coding accessible, translate a German specification for an international audience and learn Python while refreshing my programming skills.

    Today, none of those needs to be a prerequisite for the real experiment.

    Roco published the specification finally in English. AI can help produce and inspect Python. If I encounter a language feature or protocol detail I do not understand, I can investigate it at the moment it becomes relevant.

    Technical knowledge has not disappeared. AI can supply implementation proposals on demand, but my understanding of what good software looks like becomes what allows me to direct, challenge and improve those proposals.

    But much of it has moved from being a prerequisite to being an on-demand resource.

    That changes where I can spend my attention.

    Before, the path often looked like this:

    intent → documentation → technical understanding → implementation → debugging → experiment

    Now it can look more like this:

    intent → user story → acceptance criteria → automated tests → implementation → experiment → observation and learning

    All AI assisted. The implementation is still there. So is the technical knowledge behind it. But they no longer need to dominate the work.

    That leaves more room for the questions I actually care about:

    What am I trying to achieve?

    What behavior do I require?

    How will I know that it works?

    What assumptions am I making?

    What did I learn from the result?

    Not just programming

    I recognize the same pattern when working with AI on Practice Notes and other documents.

    I bring intent, observations and source material. AI helps analyze, retrieve, compare, synthesize and draft. I inspect the result, challenge it, provide more evidence and iterate.

    The artifact may be prose instead of Python, but the pattern is similar:

    intent → AI-assisted interpretation → AI-generated candidate artifact → judgment → evidence → revision

    For software, some of that evidence can be executable. User stories preserve intent. Acceptance criteria describe expected behavior. Automated tests make those expectations executable. A simulator provides a controlled test environment. Eventually, the physical model railway layout provides another form of evidence.

    AI can help throughout that chain without becoming the authority on whether the result is correct.

    From implementation to intent

    The first time around, implementing the Z21 protocol was part of the exploration.

    I wanted to understand it, explain it and learn how to implement it.

    This time, I do not particularly need to rediscover how to implement a binary railway protocol.

    I want to explore what I can do with it.

    Earlier, I explored how to implement the Z21 protocol.

    This time, I can explore what I want to do with it.

    And perhaps that is the broader lesson:

    AI does not merely make implementation faster. It can move implementation knowledge from a prerequisite toward an on-demand resource, allowing more attention to move toward intent, evidence, judgment and learning.

  • Practice Note: Reference Model as the Antidote to Understanding Debt?

    This morning I woke up with a rather practical question.

    Since my laptop is getting older but is still considered rather capable, I wondered how suitable it is to run a language model locally on this machine. And I wondered what a local LLM could be used for. A specific use case came up quickly:

    Organizations accumulate enormous amounts of material over time: architecture descriptions, requirements, decision records, source repositories, project documentation, incident histories, assessments, reports, presentations, and wikis. Could a local LLM collect, analyze, and synthesize such material into a body of knowledge that could then be interrogated?

    We had already explored the idea that this might reduce the need to keep producing new documents simply to carry existing insights into another context. Instead of anticipating every future question and writing a document to answer it, perhaps we could maintain the knowledge and construct the answer when somebody actually asks.

    There is an attractive side effect to this. Documents start aging almost as soon as they are published. If the underlying body of knowledge changes instead, the same question asked six months later can produce an answer based on what is known six months later. The emphasis shifts from periodically republishing knowledge to maintaining something that can continuously be interrogated.

    Reconstructing a Product Reference Model

    I had already been thinking about this in relation to Product Reference Models. An existing product tends to leave a substantial trail of evidence behind it: architecture, requirements, code, decisions, incidents, operational information, and many other artifacts. Rather than manually recreating an understanding of the product from scratch, perhaps AI could work across those existing sources and help reconstruct a Product Reference Model.

    The interesting part would not simply be collecting links. A useful model would also need the relationships between those sources and, particularly, the rationale for their inclusion. Why does this architecture repository matter? What does this incident history tell us about the product? Why is an old decision record still relevant? Where do different sources contradict each other, and where are there white spots for which no useful evidence appears to exist?

    A list of artifacts gives us information. The relationships and rationale between them begin to give us understanding.

    Such a Product Reference Model would not necessarily need to become another physical document. It could remain connected to its underlying sources and be synthesized when required. If a production incident exposed a previously unknown dependency, or a new business need resulted in changes to architecture and code, the evidence available to the model would change with it. The next interrogation could therefore reflect a different understanding of the product without somebody first having to rewrite a reference document.

    From products to capabilities

    That thought made me look differently at another Reference Model I had been working with.

    In parallel, I had been developing a concept Quality Assurance Capability Reference Model. Unlike the rather distributed Product Reference Model I was imagining, this one is very tangible: a spreadsheet with multiple views of the capability, including dimensions and maturity characteristics, stakeholder perspectives, an evidence landscape, indicators, anti-patterns, and example practices. It is intended to support both capability assessment and capability development.

    If a Product Reference Model could become interrogable, why couldn’t this one?

    An assessor could ask what stronger capability looks like in a particular dimension, which stakeholder perspectives might be relevant, or what evidence could challenge an emerging interpretation. Someone working with capability development could interrogate the same model from a different perspective. The spreadsheet might remain useful for maintaining the model, but it would no longer have to be the primary way in which people consume it.

    There is an additional twist here. Assessment and development do not only use the Reference Model; they also generate evidence about the subject it describes. An intervention may succeed, fail, or work for entirely different reasons than expected. Repeated assessments may reveal a pattern that the existing model does not explain particularly well.

    So a Reference Model is not simply a stable body of knowledge from which answers are retrieved. It participates in a loop. The model helps us interpret evidence, while evidence can support, extend, or challenge the model. The Reference Model therefore becomes part of a learning loop.

    And that started to connect the local-LLM thought experiment with another idea we had already been approaching: stewardship.

    From management to stewardship

    Management disciplines such as product management and portfolio management necessarily spend considerable attention on the things associated with their subject: decisions, processes, plans, repositories, ownership structures, and other artifacts. But even when those things are managed well, the organization can still gradually lose its accumulated understanding of the subject itself.

    Stewardship suggests a different concern:

    Can the organization continue to understand a subject as people leave, evidence accumulates, and reality changes?

    That question exposes something slightly awkward. Where does persistent organizational understanding actually exist?

    Some of it exists in people’s heads, some in documents and systems, some in evidence, and a great deal of it exists in the relationships between those things. We had already suspected that Reference Models might play a foundational role in stewardship, but I think the reason for that is now becoming clearer.

    Reference Model = Understanding?

    We normally describe a Reference Model as a representation of our understanding.

    Perhaps that distinction is unnecessary.

    If a Reference Model maintains what matters about a subject, how things relate, why they matter, what evidence supports them, where uncertainty remains, and how all of that changes as we learn, then what separate thing are we calling “the understanding”?

    Perhaps the Subject Reference Model is the maintained organizational understanding of the subject.

    That does not mean every fact or artifact needs to be contained inside it. The Product Reference Model demonstrates why. Much of its detailed knowledge can remain in the sources to which it refers. Knowing that a source matters, understanding why it matters, and maintaining its relationships to other parts of the subject can itself be part of the model.

    A Capability Reference Model may encode much more of its domain knowledge explicitly. The physical forms are different because the subjects are different, but the fundamental function may be the same.

    A Product Reference Model is maintained product understanding. A Capability Reference Model is maintained capability understanding.

    More generally:

    Subject Reference Model = Subject Understanding

    And that connects to a problem we have encountered from an entirely different direction.

    Understanding debt

    We have been using the term understanding debt for something that documentation alone does not seem to solve. Organizations are extraordinarily good at accumulating information while gradually losing the context, relationships, and rationale that make the information understandable.

    The architecture document remains, but nobody remembers why the architecture was chosen. The old system remains, but nobody is entirely sure what depends on it. A practice continues long after its original purpose has disappeared from organizational memory. A decision can still be found, but the alternatives that were considered and the reasons they were rejected are gone.

    Nothing necessarily went undocumented. There may be more documentation than ever.

    What disappeared was the understanding that connected it.

    If the Subject Reference Model is maintained understanding, then understanding debt becomes easier to describe. It is the gap between what the organization needs to understand about a subject and what its maintained Subject Reference Model actually allows it to understand.

    Seen that way, Reference Models become rather more important than useful assessment frameworks, maturity models, or knowledge structures. They become a mechanism for allowing organizational understanding to persist beyond the people who happen to hold it at a particular moment.

    AI may make Reference Models more important, not less

    It would be easy to assume that increasingly capable AI makes Reference Models less important. If an AI can read everything, why bother maintaining a model?

    I suspect the opposite may be true.

    Giving AI access to everything gives it information: twenty years of documents, code, incidents, presentations, abandoned decisions, obsolete descriptions, and contradictory claims. Without some maintained conception of what matters and how it fits together, the AI has to reconstruct an understanding from that history every time we ask a question.

    A stewarded Reference Model gives that information meaning and continuity. AI, in turn, may make it practical to reconstruct such models from existing evidence, interrogate them rather than continually publishing new documents, and help keep them aligned with new evidence as the organization learns.

    The interesting role of AI may therefore not be producing more organizational knowledge at all. It may be helping us maintain the understanding underneath it.

    If Subject Reference Model = Subject Understanding, then stewardship of Reference Models is stewardship of organizational understanding.

    And that may make the Reference Model our best antidote yet to understanding debt.