Category: Field Notes

As a consequence of using AI in my writing, the cost of writing has decreased dramatically. An idea that once required several evenings of outlining, drafting, rewriting and polishing can now become a coherent paper much faster. Arguments can be tested in different forms. Weak transitions can be repaired. Examples can be added. Alternative structures can be explored without starting again from scratch. For that, I am incredibly grateful.

But one important cost has not decreased nearly as much: the cost of serious review. A reviewer still has to read the paper carefully. They still have to understand the argument rather than merely recognize the words. They may also use AI, but that’s not enough.

They still have to compare the claims with their own experience, identify hidden assumptions, notice contradictions, challenge weak reasoning and decide whether the model is actually useful. That takes time. More importantly, it takes qualified attention.

AI can help produce more documents, or more incremental versions of the same documents. It does not automatically create more people willing and able to judge whether those documents deserve to be trusted.This changes the bottleneck.

Previously, writing itself limited how much material could be produced. If creating a paper took months, review requests were naturally infrequent. Now drafting is cheaper. A paper can be improved repeatedly, and new versions can appear almost whenever a new insight emerges. That sounds positive. Until every small improvement is sent to the same colleagues for another serious review.

The cost of producing the new version may have become low. The cost imposed on the reviewer has not. That creates a new responsibility for the writer. Cheap drafting should not lead to expensive review churn.

I may revise a paper privately many times. I may collect new examples, conceptual distinctions, field observations and corrections in a backlog. But a new version should only be published when those changes together create a significant improvement.

Not merely better wording. Not one extra paragraph. Not version 1.04 because I had another thought on Tuesday. A new review should be worth the attention it asks for.

This suggests a simple structure. Field notes can remain the exploratory layer. They capture observations while they are fresh. Several notes may begin pointing in the same direction. The stable insight then enters the backlog for the relevant paper. Only when enough important changes have accumulated does the formal paper absorb them and become a genuinely new version.

The production cycle becomes faster. The release discipline should become stricter. This applies far beyond my own papers.

Organizations can now produce reports, proposals, strategies, requirements, policies and presentations at unprecedented speed. Much of it will be polished, plausible and professionally written. But polished language is not the same as sound reasoning. And increased output does not create increased capacity for careful judgment.

The danger is not only that AI will produce poor documents. It is that it will produce more documents than anyone can seriously assess. The scarce resource is shifting from creation to judgment.

The cost of producing documents has collapsed. The cost of deciding whether they deserve to be trusted has not.

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.

.

Is, let’s say, a Seiko Presage Sharp Edged suitable as a dress watch? One way to answer that question is to find an undisputed dress watch—perhaps a Rolex—and compare the Seiko against it. The Rolex may be thinner. More restrained. Its dial may be simpler, its case less assertive, its overall appearance more traditional. Conclusion: the Seiko is not a dress watch.

But something has gone wrong. We did not assess whether the Seiko was suitable as a dress watch. We assessed whether it resembled the Rolex.

The Rolex became a reference object.

That matters because a Rolex is not the definition of a dress watch. It is one implementation of a dress watch. Its proportions, materials, dial layout and styling are particular design choices through which it realizes certain characteristics. By comparing the Seiko directly with the Rolex, we quietly turn those choices into assessment criteria.

We are no longer asking:

Does the Seiko possess the characteristics of a dress watch?

We are asking:

Does the Seiko implement those characteristics in the same way as the Rolex?

A better approach is to define the typical characteristics of a dress watch.

Perhaps:

• restrained proportions;
• an elegant case;
• a leather strap;
• limited complications;
• an appearance that complements rather than dominates formal clothing;
• and the ability to fit comfortably beneath a shirt cuff.

Now we have something closer to a reference model.

Against those characteristics, the answer becomes more interesting. The Seiko may not be the purest or most traditional dress watch. Its case and dial may be more expressive than the classical ideal. But it satisfies enough of the relevant characteristics that it can reasonably function as one. So yes: perhaps it is at least kind of a dress watch.

The assessment changed because we stopped comparing to a reference object and started measuring against a reference model.

Now turn to software. What are the requirements for the new system?

“We don’t really have proper requirements. We don’t have the time, money or capability to define them. But the new system should look and work like the old system.”

So the old system becomes the reference object. The same old system that must be replaced.

Now, with considerably more money at stake, we make exactly the same mistake again. The old system is one implementation of the required business behavior. But instead of identifying that behavior, we copy the implementation. Its screens become requirements. Its workflows become requirements. Its terminology and data structures become requirements. Even its limitations, workarounds and historical accidents risk becoming requirements.

Apparently, the old system is not good enough to keep—but its implementation is good enough to copy. The irony is difficult to miss.

A transformation project begins because the current system is no longer suitable, then uses that same system as the model for the future. We call it transformation, but make resemblance to the past the acceptance criterion.

Of course, the old system can still be useful. It may contain valuable examples, business terminology, accumulated knowledge and behaviors that must not be lost. But it should help us discover the reference model, not replace it.

The real questions remain:

• What must the new system enable?
• Which outcomes must it support?
• Which behaviors must remain possible?
• Which characteristics must it possess?
• Which constraints still matter?
• Which parts of the old system were merely consequences of one particular implementation?

A reference model describes the 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.

For years I tried to make my reports correct. Then I tried to make them complete. Eventually, I realized I wanted something else: I wanted them to be skön att läsa—enjoyable to read. At first, that sounded almost inappropriate. A report is supposed to be factual, objective and complete. It isn’t supposed to compete with a novel. Or is it?

Looking back over years of writing reports and giving presentations, I noticed a pattern. Of the many presentations I have delivered, those that received the strongest engagement were rarely the ones in which I tried hardest to explain every fact. They were the ones in which I unintentionally told a story. Not fiction. A real story.

Those presentations felt different. I was more relaxed. I wasn’t constantly wondering whether I had forgotten a fact or whether someone would misunderstand a definition. I simply invited the audience to walk the same path that had led me to the insight. The audience seemed to enjoy that journey as much as I did.

Only recently did I realize that the same principle applies to writing. Many technical reports feel like collections of facts. Everything is correct. Everything is complete. Yet reading them feels like climbing a staircase while carrying boxes. Every page asks the reader to do more work. What if the facts themselves are not the problem? What if the problem is that they have no journey to travel on?

The reader keeps asking:

“Why are you telling me this?”

A story answers that question naturally.

Ironically, storytelling may be one of the most effective ways to communicate technical ideas. Not because it simplifies them. But because it makes understanding feel effortless. A story does not replace facts. It gives the facts somewhere to live.

Yet storytelling and style are often treated as luxuries for which professional work has no time.

“Don’t waste my time. Just give me the facts.”

But facts without a story do not eliminate the work of creating meaning. They merely leave that work to the reader. Making a report skön att läsa takes time. Framing a presentation as a story takes time.

So does trying to understand a report whose writer decided that readability was a luxury.

So does trying to make sense of a presentation that is merely a wall of facts.

Yesterday I wanted to spend a few hours at the beach. That should have been one of the simplest decisions of the day. Instead, I found myself choosing between watch configurations. Not watches. Watch configurations. If you’re not interested in watches, you’ve probably just rolled your eyes. Bear with me. This gets worse before it gets better.

The strange thing about owning more than one watch is that you eventually stop choosing between watches. You start choosing between combinations. First, there are different watch types. Dress watches. Dive watches. Field watches. Pilot watches. GMT watches. Chronographs. Smartwatches. Then there are different case materials. Steel. Titanium. Gold. Ceramic. Carbon. Then come the straps and bracelets. Leather. Steel. Rubber. Silicone. NATO. Milanese. And finally there are the occasions. Business meetings. Client workshops. Traveling. Black tie. Dinner. Walking. Hiking. Swimming. Beach holidays. Working from home.

Some combinations work beautifully. Others feel completely wrong. A dress watch on a rubber strap. A dive watch with a crocodile leather strap. A smartwatch with a dinner jacket. Technically possible. Practically… questionable.

Yesterday’s shortlist looked like this:

• Victorinox on its steel bracelet.
• Victorinox on the rubber strap that I still intend to buy.
• Apple Watch Ultra with the titanium Milanese Loop.
• Apple Watch Ultra with a silicone strap.

Leather straps never even made the shortlist. Swimming eliminates leather before the discussion begins.

At this point normal people have probably stopped reading. Or they’re wondering why anyone would willingly complicate something as simple as going to the beach. That is a fair question. I wondered the same thing.

Then I realized I wasn’t really choosing a watch. I was performing an assessment.

Hidden beneath the madness

Without consciously thinking about it, I had already established the context. The occasion was:

• Swimming.
• Sunbathing.
• Casual leisure.
• Warm weather.
• Activity tracking would be useful.

The occasion had quietly defined the reference model. Once that happened, the rest became surprisingly structured. Leather disappeared immediately because it failed a mandatory criterion. The remaining candidates all satisfied the essential requirements. The Victorinox on its steel bracelet would have worked perfectly. The Apple Watch Ultra with the silicone strap would also have worked perfectly.

In the end I chose the Apple Watch Ultra with the titanium Milanese Loop. Why? Because it already met every important criterion. It works well in the water. It tracks my activity. The Milanese Loop is surprisingly comfortable for swimming. And it was already on the watch.

Changing to the silicone strap might have produced a tiny improvement. Not enough to justify changing it. The decision wasn’t about finding perfection. It was about recognizing that several options were good enough.

Then something even stranger happened

Choosing a watch for today turned out not to be the most interesting assessment. The more interesting question was what this decision said about the collection itself. Suppose I repeatedly discover that no existing watch configuration works well for a certain type of occasion.

Now I have evidence. Not evidence that I need another watch. Evidence that I may be missing a capability. That is an entirely different conclusion. Buying another dive watch because I like dive watches merely enlarges the collection. Buying a watch that enables a capability I genuinely lack expands the capability of the collection.

Those are not the same thing. A larger collection is not necessarily a more capable collection. Someone with twelve dive watches may actually have fewer capabilities than someone with four carefully chosen watches covering formal occasions, everyday wear, outdoor activities and sports.

That distinction only becomes visible once you assess the portfolio rather than admire the individual items.

From watches to organisations

At this point you may have forgotten that this story started with a trip to the beach. So had I. Because somewhere along the way I realized that this wasn’t really about watches. It was about assessment. Start with the context. Make the reference model explicit. Identify mandatory criteria. Eliminate unsuitable options. Compare the remaining candidates. Accept that several answers may be equally valid. Observe recurring patterns over time. Identify capability gaps. Invest where capabilities are missing rather than where enthusiasm happens to be highest.

That is exactly the same reasoning I use when assessing software products, organizational capabilities, consulting practices or transformation initiatives. The domain changes. The thinking does not.

Method in the madness

From the outside this probably looked like an enthusiast overthinking a trivial decision. Perhaps it was. But what looked like madness turned out to have a surprisingly coherent method.

The interesting part is not that I own several watches. The interesting part is that once enough dimensions are involved—watch types, materials, straps, occasions and personal preferences—the number of possible combinations grows remarkably quickly. The world quietly becomes more complicated than our intuition comfortably manages.

That is the moment when methods become valuable. Not because they make the world more complicated. But because they help us navigate complexity without having to rethink everything from first principles every single time. Yesterday I happened to use that method to choose a watch for the beach. Tomorrow I might use exactly the same method to assess a software product, a wardrobe, an organisation or an investment portfolio.

The watches were never really the story. They were simply the easiest place to see the method hiding in the madness.