Category: Reflections

I have now reached eighty posts.

At the end of the previous retrospective, I wrote that the subjects were changing while the method did not. At the time, that already felt important. The Practice Notes had moved well beyond software quality into watches, clothing, memory, writing, AI and organizational continuity, yet the same underlying questions kept returning. What I had not expected was what would happen next.

During the last twenty posts, the body of knowledge began to do more than connect existing observations. It started generating new ones.

The Body of Knowledge Became a Subject

The first part of this cycle was less about extending the theory and more about understanding what had already accumulated. As the number of Practice Notes increased, a new problem appeared. Writing had become cheap. Reviewing, synthesizing and maintaining all of the resulting representations had not.

That led to a shift in how I thought about the notes themselves. Perhaps the objective was not to keep producing more polished documents about the same underlying knowledge. Perhaps the notes could become the primary body of evidence, while papers, models, guidance and other publications became derived representations.

That idea changed the role of AI as well. Instead of using AI only to help write individual notes, it could help search across them, connect them, identify recurring patterns and synthesize different views of the same body of understanding.

The notes were no longer merely outputs. They had become material for further inquiry.

From Experience to Pattern

That made another change possible. Professional experience usually arrives as cases. A difficult assessment. A strange organizational behavior. A successful intervention. A failed transformation. A watch that reveals something unexpectedly useful about reference models.

Individual cases matter, but their greater value may lie in what becomes visible when several of them are compared. A practitioner who has seen the same underlying mechanism repeatedly may begin to recognize it in very different situations.

This does not mean that experience produces automatic answers. It produces better hypotheses.

That distinction became increasingly important during this cycle. The blog began moving from recording what happened toward asking what different experiences might have in common. Once that happened, the theory started becoming more active.

When the Theory Began to Extrapolate

Several recent notes were no longer straightforward abstractions from direct experience. They were consequences of ideas that had already developed elsewhere.

If organizational capabilities persist after improvement projects end, perhaps improvement is not enough. Perhaps they require continuing Capability Management.

If major transformations change several capabilities at the same time, perhaps transformation can be understood as the coordinated evolution of a capability portfolio rather than primarily as the implementation of a framework.

If individual subjects can all be strong while the collection as a whole is poorly composed, perhaps the portfolio itself is also a subject with its own reference, development and assessment.

And if Product Management and Capability Management appear to contain the same recurring architecture of reference, development, assessment, learning and stewardship, perhaps they are two specializations of something more general.

For now, I have called that possibility Subject Management. That last idea is deliberately speculative. In fact, several notes in this cycle received question marks for exactly that reason.

I have enough experience and theory to see why the idea might make sense. I do not have enough to claim that it does. That distinction has become more important as the theory has grown.

The Difference Between Observation and Extrapolation

One useful correction happened while writing Returning to the Same Organization.

The original draft tried to connect the experience directly to loss of organizational understanding. But that was not actually what I had observed.

What I had observed was simpler. I had returned to several very large organizations after roughly ten years and found that they had become remarkably different organizations. The company was still there. The organization I remembered largely was not.

That led to the idea of an organizational generation, and to a question about how continuity is preserved when organizational generations may be much shorter than human generations.

That was enough. The note became better when I stopped trying to make the observation prove more than it actually did. This may be one of the most important developments in this cycle.

As the theory becomes more ambitious, the need to distinguish between experience, interpretation and speculation becomes more important as well.

Knowing When to Stop

That same concern appeared more explicitly in Knowing When to Stop.

I have always been inclined to keep asking Why. One explanation usually leads to another question, and another, until the underlying principle starts becoming visible.

But there is a limit. Sometimes the evidence simply runs out. At that point, further reasoning may stop producing understanding and start producing speculation. There is an important difference between saying that there is no answer and saying that I cannot justify an answer. The second is often the more honest conclusion.

That idea later returned in a more professional form: assessment requires curiosity. But curiosity must be disciplined. The assessor should keep asking when something does not make sense, but should also stop when the evidence no longer supports another conclusion.

That led to one of the clearest propositions of this cycle:

Assessment is disciplined curiosity directed toward justified judgment.

A Method in the Madness

The biggest surprise, however, may not have been any one of the theoretical ideas. It was recognizing something about the way those ideas are being produced.

Across quality management, capability assessment, Product Continuity, watches, dress codes, organizational change and even a fictional Swiss engineer called Hans Hexagon, I seem to keep following the same pattern.

It begins with Why.

Then Why behind the Why.

And often another Why behind that.

The questioning continues until the visible practice, product, process or artifact starts giving way to the purpose beneath it. Once that purpose becomes clearer, inconsistencies become easier to see.

The process no longer performs the function it was intended to perform. The framework has become more important than the capability it was meant to create. The implementation has become the reference. The visible What has drifted away from the underlying Why. And once that inconsistency becomes visible, the direction of development often becomes clearer. A compact version of the pattern is:

Reveal the Why → Reveal the Inconsistencies → Reveal the Path

I have started calling this the Recursive Why. I do not yet know whether it is anything more than a description of how I personally tend to think. But that question itself is now interesting.

The Theory Is Beginning to Talk Back

Earlier Practice Notes mostly captured observations. Later notes connected those observations into recurring concepts. Those concepts gradually became a theory. During this cycle, something changed again.

The theory began suggesting what I should look at next. Capability Continuity suggested Capability Management. Capability Management suggested capability-portfolio thinking. Portfolio thinking changed how transformation could be interpreted. Product and Capability Management suggested the possibility of a common management architecture.

The theory was no longer only organizing the past. It was generating hypotheses about things I had not originally set out to investigate. That feels like an important threshold.

It is also dangerous. A theory that can generate new ideas can also generate very convincing nonsense. Which is why the other development in this cycle matters just as much. Keep asking. But do not claim more than the evidence allows.

Perhaps the Recursive Why and disciplined curiosity belong together. One keeps the inquiry moving. The other keeps it honest.

What Comes Next?

I am less certain than ever that I know. That is not necessarily a problem. The Practice Notes increasingly seem to work best when they preserve observations before I know exactly where those observations belong.

Some will become part of Reference Model Theory. Some may contribute to Capability Management or Product Management. Some may belong in a future theory of Assessment as a Professional Discipline. Some may disappear during later synthesis because they turn out to add very little. And some speculative ideas may simply be wrong. The important thing is that their status remains visible.

The notes are becoming a record not only of conclusions, but of how those conclusions emerged, changed and occasionally failed. That may become valuable in its own right.

Reflection

At sixty posts, I wrote that the subjects were changing while the method remained the same. At eighty, I think I am beginning to see part of that method. The progression so far looks something like this:

Observation → Pattern → Theory → Extrapolation → Method

The next question may be whether the method itself can be understood well enough to test. Is the Recursive Why simply one person’s habit of thought? Or is there something more general in it?

I do not know. Which, after the last twenty posts, feels like exactly the right answer. For now.

I have now completed sixty posts.

The first retrospective examined the writing process. The second examined the emerging theory of product quality assessment. This time, the most interesting development may not be found inside any individual field note. It is found in the relationships between them.

What Happened?

During this cycle, the field notes moved across a much wider range of subjects. Some continued the work on product reference models, Product Ownership and assessment. Others explored system continuity, understanding debt, documentation and the preservation of knowledge. Then the notes wandered into watches, clothing, writing, storytelling and AI-assisted thinking.

At first glance, this might look as though the blog had started losing focus. Instead, something almost opposite happened. The same ideas began appearing in different places. A watch collection became an example of portfolio capability. A suit became an example of how an object can remain unchanged while its environment changes. A watch strap showed how changing a boundary changes what we perceive as the object. Inherited possessions became a way to understand the loss of system context. A comparison between two watches exposed the danger of replacing a reference model with a reference object.

The subjects changed. The method did not.

What Surprised Me?

The biggest surprise was that everyday observations did not merely illustrate ideas already developed in the papers. They generated new ideas.

The distinction between a reference model and a reference object emerged through a discussion about whether a Seiko could function as a dress watch. A Rolex may be one implementation of a dress watch. It is not the definition of one. Comparing another watch directly with it risks turning its particular design choices into assessment criteria.

The same mistake appears in transformation projects when the new system is expected to look and work like the old system. The old system becomes the reference object. And not even an obviously good one. It is the system that must be replaced.

That simple watch example made the software problem easier to see: We call it transformation, but make resemblance to the past the acceptance criterion.

The field note then produced a refinement that belongs back in the more formal work: A reference model describes required behavior and characteristics. A reference object shows one possible implementation of them. When the reference object replaces the reference model, one implementation quietly becomes the requirement. And QA verifies the implementation rather than the required behavior. The field notes have therefore become more than a way to communicate the theory.

They have become a way to develop it.

What Became Clearer?

Several recurring patterns are becoming visible.

The first is the separation of purpose from implementation. Requirements should describe required behavior, not merely reproduce an existing solution. Testing should verify behavior, not bind itself unnecessarily to implementation. Capability assessments should assess capabilities, not prescribe particular processes. Reference models should describe characteristics, behaviors and capabilities, not require resemblance to one preferred example.

The second pattern is continuity of understanding. A system can survive while the reasons behind it disappear. Source code, documents and tickets may remain available, while the organization gradually loses the ability to explain why a business rule exists, why a trade-off was accepted or whether an unusual behavior is deliberate.

This led to the idea of understanding debt: the accumulated gap between what the product embodies and what the organization can still explain with justified confidence.

The third pattern concerns communication. Facts do not automatically form an argument. Sentences do not automatically form a thought. Documents do not automatically preserve knowledge. Structure, context and story are not decoration added after the “real work” is complete. They help make meaning reconstructable.

The Field Notes Are Beginning to Reinforce One Another

During the previous cycle, I noticed that the product-quality notes formed a chain. This time, the effect became broader. A note about documentation strengthens a note about understanding debt. A note about understanding debt strengthens the case for Product Continuity. A note about reference objects strengthens the distinction between capability and process. A note about storytelling explains why the more conceptual notes become easier to understand when they begin with watches, clothing or inherited possessions.

Each note can still stand on its own. But later notes increasingly change how earlier ones are understood. The backlog is therefore no longer merely a queue of separate posts. It is becoming a body of work.

What Changed in the Writing?

The strongest recent notes often begin with something concrete and apparently insignificant. A watch. A suit. A photograph frame. An inherited object. A paragraph.

The reader can follow the observation without knowing anything about assessment, Quality Management or transformation. Only after the principle has become visible does the note pivot toward software or organizations. That pivot is often where the note acquires its real meaning.

Starting with transformation theory would require the reader to accept an abstraction. Starting with a watch allows the reader to discover the abstraction first. The professional problem is then judged by a principle the reader has already understood.

This may be becoming the characteristic form of these field notes:

Begin with an object.
Discover a distinction.
Follow it into another domain.
End by revealing that the original subject was never really the subject.

What Remains Unproven?

The growing coherence is visible to me because I have followed every conversation and written every note. It is not yet clear whether it is equally visible to a reader encountering the posts individually.

Several questions remain:

• Can readers recognize the recurring method without being given a map?
• Should related field notes be connected through synthesis pages or thematic collections?
• Can the new concepts be incorporated into the assessment, Product Continuity and transformation papers without making those papers unnecessarily broad?
• Do the everyday analogies clarify the professional ideas, or will some readers remember only the watches?
• Do these distinctions improve actual assessment and transformation work?

The theory is becoming richer. It must still become usable.

What Comes Next?

The next phase should probably combine continued exploration with more deliberate consolidation. The field notes can continue to capture new observations. There is no shortage of material.

But several ideas now deserve to be carried back into the formal papers:

• the distinction between reference models and reference objects;
• the danger of confusing required behavior with one existing implementation;
• understanding debt as the inability to explain what a product embodies;
• documentation as the preservation of reconstructable meaning;
• and field observations as a method for testing and refining conceptual models.

The blog itself may also need stronger thematic routes through the material. The chronological stream shows when the ideas appeared. It does not necessarily show how they belong together.

Conclusion

After the first twenty posts, I discovered a writing process. After forty, I could see an emerging theory. After sixty, I am beginning to see the method connecting subjects that initially appeared unrelated.

I thought I was collecting observations about quality, assessment, software, watches, clothing, writing and memory. Perhaps I was doing something else. Perhaps I was repeatedly asking the same questions:

• What is this really for?
• What characteristics matter?
• What should remain stable when the implementation changes?
• What knowledge must survive?
• How can we make the reasoning visible enough for someone else to continue it?

The individual field notes are becoming stronger. But their real strength may be that they are no longer entirely individual.

.

I completed the next twenty posts, bringing the total to forty. Since I agreed with myself to pause for a retrospective after every twenty posts, here is the second one. It feels as though I have completed an initial theoretical loop around product quality assessment.

During this cycle, the investigation moved through several connected questions:

• What distinguishes assessment from testing, QA and quality engineering?
• What must exist before meaningful assessment is possible?
• What belongs in a product reference model?
• Who owns and maintains that model?
• How should evidence support judgement?
• How does assessment continue after deployment?

The final field notes brought many of these questions together in Product Quality Assessment as a Continuous Discipline.

What Surprised Me?

The biggest surprise was the growing importance of the product reference model. It began as the reference against which a product could be assessed. It gradually became something closer to a shared description of what the product is intended to achieve, what good looks like, which constraints matter and what evidence is needed.

A second surprise was the emergence of Product Ownership as the continuity mechanism connecting business intent, engineering interpretation, release judgement and operational learning.

A third surprise was that the field notes began reinforcing one another. Ideas that appeared speculative in isolation became more credible when placed into a coherent chain.

What Became Clearer?

Several propositions now seem reasonably stable:

• Quality is the integrity of the chain from business intent to realised outcome.
• Testing can be understood as a form of assessment, but product quality assessment is broader than testing.
• Meaningful assessment requires an explicit reference model.
• The reference model must guide implementation as well as evaluation.
• Assessability and evidence need to be designed in.
• Product quality cannot be fully understood at release. Operational evidence must complete the judgement.

These are still working propositions, but they increasingly appear to form a coherent whole.

What Remains Unproven?

The theory has not yet been validated as an operational model. Important questions remain:

• Can a useful product reference model be maintained without becoming bureaucratic?
• What is its minimum viable form?
• Can product quality assessment become part of normal delivery rather than a separate governance process?
• Does it lead to better findings, decisions and priorities in practice?

The business-intent side also needs more development. Much of the thinking so far has focused on engineering, testing, evidence and reference models.

What Comes Next?

The next step is probably not another rapid expansion of the theory. I want to begin consolidating the existing thinking around one master theme:

Quality from Business Intent to Outcome

Supporting themes may include:

1. Testing as Assessment
2. The Product Reference Model
3. Product Ownership and Quality Judgement
4. Continuous Product Quality Assessment

These should be treated as evolving synthesis pages rather than finished statements.

For the field notes, I first want to propose a conceptual table of contents for the product reference model. After that, I expect to return to assessment itself: the assessment model, the relationship between evidence and judgement, and perhaps a few conceptual capability models.

I also want to revisit a historical assessment and see whether the emerging approach produces better or simply different findings.

Conclusion

The first retrospective asked what was happening to the writing process. This retrospective asks what has happened to the subject itself.

Product quality assessment began as an attempt to describe testing differently. It expanded into questions about reference models, Product Ownership, evidence, operational learning and governance.

The result is not yet a proven method. But it is becoming a coherent discipline. The next step is to find out whether it can also become concrete, usable and valuable in practice.

What Happened

I wrote 20 posts for this blog, including 18 field notes. I think it is time to evaluate the process before I will continue.

What Surprised Me?

The pace of writing turned out to be extremely high. I produced the 18 field notes in two mornings, during some downtime while doing other things.

Ideas for new field notes kept appearing. With the help of AI, those ideas matured and turned into actual blog posts. The friction between a conceptual idea and a finished post ready for publication all but disappeared. That experience itself became the source of several new field notes.

I decided to maintain a publishing cadence of one post per day to avoid burning out. This pace of writing may not be sustainable, and I want to avoid creating pressure to write merely to maintain the cadence.

The publishing cadence also creates time between writing a post and committing to it. I can still revise or retract a scheduled post before publication if new insights emerge.

What Worked Well?

The process of generating ideas, developing them through dialogue and turning them into publishable posts worked remarkably well.

The title and description I chose for the blog at the beginning also still seem to fit the material I have created so far. The subjects have expanded, but they remain within the territory of quality and delivery transformations.

What Did Not Work Well?

I set up this WordPress blog from scratch, added an “About Marcel” page and immediately started writing posts. I paid very little attention to the layout, theme or functionality of the site.

I have also not started using categories and tags. The site still uses the default theme, which may not be the most inspiring choice, and it contains links and elements that I do not use and probably never will.

The content has developed much faster than the structure around it.

What Will I Change?

Besides continuing to develop new field notes, I will clean up the site. I will add categories and tags, evaluate alternative themes and remove unused links and elements.

As the number of field notes grows, I may also create overview pages that connect related posts. These could make the emerging themes more visible and provide other ways into the material beyond the chronological list and the “About Marcel” page.

For now, I will continue with the next set of 20 posts and then conduct another retrospective.

The first cycle has shown that generating material is not currently the main challenge. The next challenge is to give that material enough structure, distance and editorial attention as the blog develops.

This wasn’t supposed to happen.

A few weeks ago, all I wanted was a better CV.

After many years in software development, testing, quality engineering and organisational assessments, my CV had become what many long careers become: a chronological list of projects, responsibilities and technologies. Accurate enough, but not particularly insightful. So I asked an AI to review it.

I expected editorial assistance. Better wording. Better structure. Perhaps a few suggestions on what to remove or emphasize. Instead, something rather unexpected happened.

The conversation moved from my CV to my LinkedIn profile. From there, it became a discussion about recurring themes in my career and what seemed to distinguish me from others with similar backgrounds. Then came a SWOT analysis. Then conversations about positioning and professional identity. Then questions about what kind of work I genuinely enjoy, where I add the most value and, perhaps more importantly, where I don’t.

Somewhere along the way I realised we were no longer talking about my CV at all. We were talking about me. Or more specifically, about the story my career told when viewed as a whole rather than as a sequence of individual jobs.

The discussion became increasingly reflective. If I have another decade or so left in my professional career, how do I actually want to spend it? What do I want to be known for? What kind of problems do I most enjoy solving? Where can I contribute something that isn’t simply another pair of experienced hands?

What surprised me most wasn’t that AI could rewrite sentences or suggest bullet points. It was that it could synthesize years of information, recognise patterns across them and offer perspectives that I hadn’t previously articulated myself. Sometimes it asked excellent questions. Sometimes it challenged my assumptions. Sometimes it proposed interpretations that immediately resonated.

Not every suggestion was right. Many weren’t. But enough of them were insightful that they changed the direction of the conversation. And, in a very real sense, they changed the direction of my thinking.

Eventually, the discussion turned into ideas for articles. Then themes. Then potential series of posts. And eventually, almost without noticing it, I found myself planning a blog. That’s why you’re reading this.

This won’t be a blog about AI, although AI will undoubtedly appear from time to time. It’s a blog about software delivery, quality engineering, organizational assessments and continuous improvement. It’s about understanding complex systems, identifying patterns and helping organisations become better at building software.

Ironically, that’s also what happened to me. An exercise that started with improving a CV became an assessment of something much larger: my own experience, strengths, motivations and direction. It also left me with a hypothesis that I suspect will appear repeatedly in future posts.

The most interesting outcomes don’t necessarily come from humans or AI working in isolation. They come from the interaction between the two. I started the conversation expecting editorial assistance. I ended it with a clearer understanding of my own career and a completely new set of ideas about where to take it next.