Field Notes from Quality & Delivery Transformations

Blog

  • Field Note: Agile Report Writing

    After reflecting on how recent assessment reports evolved, I realized that the process felt surprisingly familiar. Not because it resembled traditional report writing. Because it resembled Agile software development.

    The Waterfall Model of Reporting

    Most report writing follows a waterfall mindset. The process is typically assumed to be:

    1. Gather information
    2. Analyze findings
    3. Draw conclusions
    4. Write report
    5. Review report
    6. Deliver report

    The underlying assumption is that understanding precedes writing. First we figure out what we think. Then we document it. Writing is treated as the final step. The report becomes a container for conclusions that already exist. This model feels natural. It is also how many assessment reports have traditionally been produced.

    What Actually Happened

    My recent experience was very different. The report did not emerge from a completed analysis. The analysis evolved together with the report. A finding would be challenged. A recommendation would be reconsidered. An alternative explanation would emerge. A new perspective would change the interpretation. The assessment model itself might evolve.

    The report became less of a documentation activity and more of a learning process. The conclusions were not fully understood before writing began. They emerged during the process.

    A Familiar Pattern

    This should sound familiar to anyone who has worked with Agile software development. Traditional software development assumed that requirements could be understood completely before implementation started. Agile challenged that assumption.

    The Agile insight was simple:

    • Understanding emerges through iteration.
    • Requirements evolve.
    • Design evolves.
    • Architecture evolves.
    • The product evolves.
    • The team learns while building.

    The final solution cannot be fully understood at the start because the learning happens during development.

    The Same Principle Applied to Reporting

    I increasingly believe the same principle applies to assessment reports and other forms of knowledge work.

    The traditional reporting model assumes:

    Understand first, write later.

    An Agile reporting model assumes:

    Write, challenge, refine, learn, and repeat.

    The report becomes a vehicle for exploration rather than documentation. Each draft becomes an experiment. Each critique becomes feedback. Each revision increases understanding. The objective is no longer to document existing conclusions. The objective is to discover better conclusions.

    AI Changes the Economics

    Historically, this approach was difficult. Each review cycle required significant effort. Feedback was expensive. As a result, most reports received only a limited number of iterations.

    AI changes that equation. Ideas can be challenged immediately. Alternative interpretations can be explored continuously. Reasoning can be stress-tested throughout the process. The number of feedback loops increases dramatically. What was previously impractical becomes routine.

    A Working Hypothesis

    This leads me to a hypothesis:

    Reports should be developed the way Agile teams develop software.

    Not through a sequence of analysis followed by documentation. But through continuous cycles of exploration, feedback, learning, and refinement. The report is not the final step in the thinking process. The report is part of the thinking process.

    Perhaps the most important lesson from Agile was never about software. Perhaps it was about learning. And if that is true, then assessment reports, strategy documents, presentations, and even books may benefit from the same principle.

    They are not written once understanding is complete. They are iterated into existence.

  • Field Note: Reports Are Iterated Into Existence

    When I started using AI in assessment work, I assumed the primary benefit would be faster writing. I was wrong. The biggest change was not in writing. It was in iteration.

    Traditionally, an assessment report follows a familiar pattern:

    1. Information is collected.
    2. Findings are analyzed.
    3. A report is written.
    4. One or two review cycles take place.
    5. The report is updated.
    6. The report is delivered.

    In this model, the report is largely created before feedback arrives. Feedback improves the report, but only at the margins. The quality of the result depends heavily on the quality of the initial analysis. That is how I have worked for most of my career.

    A Different Process

    Recently, I noticed something fundamentally different. Instead of developing findings in isolation and reviewing them later, I began testing ideas continuously.

    1. A finding would emerge.
    2. I would challenge it.
    3. An alternative explanation would be explored.
    4. Underlying assumptions would be questioned.
    5. Evidence would be re-examined.
    6. The wording would change.
    7. The model would evolve.
    8. The recommendation would be refined.
    9. Then the cycle would start again.

    Not once. Not twice. Sometimes hundreds of times. The report was no longer something I wrote and then reviewed. The report developed through the review process itself.

    The Report Does Not Exist Yet

    The most interesting realization was that many of the strongest conclusions were not present at the beginning. They were discovered along the way.

    The traditional view assumes that the consultant already possesses the insight and simply needs to express it clearly.

    My experience was different. The initial insight was often incomplete. Sometimes it was partially wrong. Sometimes it pointed in the right direction without explaining why. The real value emerged through repeated challenge and refinement. The final conclusion was often something that neither existed nor was fully understood at the start. It emerged through iteration.

    Feedback as a Discovery Mechanism

    This changed how I think about feedback. Feedback is usually viewed as a quality assurance activity. A way to catch mistakes. A way to improve wording. A way to strengthen an already completed deliverable.

    But feedback can also be a discovery mechanism. Each challenge forces deeper thinking. Each alternative explanation reveals hidden assumptions. Each refinement creates opportunities for new insights to emerge. The purpose is not merely to improve an existing idea. The purpose is to discover a better one.

    Why AI Changes the Equation

    The significance of AI is not that it writes reports. The significance is that it makes hundreds of critique cycles economically feasible.

    Historically, each review cycle required another person, another meeting, another scheduling exercise, and another investment of time. As a result, feedback was scarce.

    Today, an idea can be challenged immediately. The cost of critique approaches zero. The number of iterations increases dramatically. And with enough iterations, something interesting happens. The deliverable stops being drafted and polished. It starts being discovered.

    A Working Hypothesis

    This leads me to a hypothesis that I find increasingly difficult to ignore:

    High-quality reports are not written and then reviewed.

    They are iterated into existence.

    The value does not come from producing a perfect first draft. It comes from creating an environment where ideas can be challenged, refined, and transformed repeatedly. The report is not the starting point. The report is what remains after hundreds of iterations have shaped the thinking behind it.

  • Field Note: Books as a Side Effect

    For much of my career, I assumed that books were the result of a plan. An author decides to write a book. Chooses a topic. Creates an outline. Conducts research. Writes chapters. Eventually, a book emerges. That process certainly exists.

    Lately, however, I have started to wonder whether some books emerge differently.

    Starting with Questions

    Over the past months, I have found myself collecting observations. Questions about quality. Assessment. Expertise. Learning. Thinking.

    Most of these observations are small. Too small for an article. Certainly too small for a book. Yet they seem worth capturing. Not because I know where they lead. Because I do not.

    The Humble Field Note

    This is one reason I like the idea of a field note. A field note makes a modest claim.

    It does not say: Here is the answer.

    It says: Here is something I noticed.

    That distinction matters. A field note allows an idea to exist before it is fully understood. It creates space for exploration.

    Looking for Patterns

    What happens next is interesting. A single observation is rarely significant. Several observations pointing in the same direction are harder to ignore. A note about seniority. A note about operational experience. A note about capability and energy. Individually, they seem unrelated. Together, they begin to reveal a larger theme.

    Not because I planned it. Because the pattern emerged.

    Thinking in Public

    Traditionally, a blog is often seen as a place to report conclusions. I am becoming interested in a different possibility. What if a blog can also be a place to develop ideas? Not polished frameworks. Not final answers. Working thoughts. Observations. Questions. Connections. A public record of learning.

    The goal becomes less about publishing expertise and more about making thinking visible.

    The Unexpected Destination

    Perhaps this is why I have stopped thinking about books as objectives. A book is too far away. Too abstract. Too easy to force.

    A field note, on the other hand, can be written today. One observation. One question. One idea worth exploring.

    If enough of those accumulate, larger things may emerge. Pages. Articles. Frameworks. Maybe even a book.

    But those become consequences rather than goals.

    An Open Reflection

    I still like the idea of writing a book someday. What has changed is my understanding of how such a book might come into existence. Not through a grand plan. Not through a decision to become an author.

    But through years of paying attention. Capturing observations. Following recurring questions. And allowing ideas to develop at their own pace.

    Perhaps books are not always written. Sometimes they are discovered. One field note at a time.

  • Field Note: Who Is the Author?

    This morning, I found myself looking at a collection of field notes that had emerged from a conversation with AI. There were more than I expected. Ideas about quality, assessments, seniority, capability and energy, thinking through dialogue.

    As I looked at them, an uncomfortable question appeared. Who actually wrote these?

    The Obvious Answer

    The obvious answer seems straightforward. The AI generated the text. Paragraphs appeared within seconds. Observations became essays. Half-formed thoughts acquired structure. From that perspective, the answer appears simple. The AI wrote them.

    At least, that is what it looks like.

    A Different Perspective

    But something about that explanation feels incomplete. Because when I look more closely, the ideas themselves did not appear out of nowhere. They came from experiences: assignments, conversations, successes, mistakes. Questions that had been lingering in the back of my mind for years.

    The observation about seniority emerged from reflecting on my own career. The observation about dialogue emerged from noticing how I think. The observation about capability and energy emerged from concerns about the types of assignments I am willing to accept.

    The AI did not live those experiences. I did.

    Thinking Partners

    This led me to another comparison. Suppose I spend two hours discussing an idea with a colleague. The colleague asks questions. Challenges assumptions. Suggests alternative interpretations.

    At the end of the conversation, a new insight emerges. Who owns the idea? Most people would not say that the colleague authored it. Nor would they say that it appeared entirely independently. The insight emerged through interaction. The conversation became part of the thinking process. Perhaps something similar is happening here.

    The Role of Dialogue

    Recently, I have started to suspect that many of my ideas emerge through dialogue rather than solitary reflection. The conversation helps expose assumptions. Reveal contradictions. Connect observations. The thinking happens in the interaction.

    If that is true, then the question becomes more complicated. If I think through dialogue, and AI participates in that dialogue, where exactly does authorship begin and end? I am not sure there is a clean answer.

    The Source of the Idea

    One way of looking at it is to separate ideas from expression. The experiences are mine. The observations are mine. The questions are mine.

    The AI helps articulate them. It provides language, structure and perspective.

    Without the conversation, some of the ideas might never become visible. Without the experiences, there would be nothing to explore. Both seem necessary. Neither seems sufficient on its own.

    An Unexpected Conclusion

    Perhaps the question itself assumes the wrong model. Perhaps authorship is not always a solitary activity.

    Many ideas emerge from discussions. Workshops. Mentoring relationships. Research communities. Professional networks. We rarely insist on identifying a single source. We recognize that thinking is often collaborative.

    Maybe AI simply introduces a new kind of collaboration. Not a replacement for human thought. Not an independent source of insight. A participant in the dialogue through which ideas are developed.

    An Open Reflection

    I still sign my name under the field notes. Not because every sentence originated with me. But because the experiences, observations and questions are mine.

    At the same time, it would feel dishonest to pretend that the dialogue played no role. The field notes emerged from interaction. Neither entirely human. Nor entirely machine.

    Perhaps the most accurate description is also the simplest. I am the author. But I am no longer writing alone.

  • Field Note: The Difference Between Capability and Energy

    For a long time, I assumed that the things I was good at would also be the things I enjoyed doing. Experience has taught me otherwise. Some activities seem to generate energy. Others consume it.

    The surprising part is that capability and energy do not always align.

    A Simple Assumption

    When evaluating a role or an assignment, we often ask: can I do it? It seems like a reasonable question. If the answer is yes, then the assignment should be a good fit. At least in theory.

    Yet many experienced professionals have encountered a strange phenomenon. They can perform a task successfully. They can even perform it well. And still feel drained by it.

    The Wrong Conclusion

    When this happens, it is tempting to conclude: maybe I am not good at this.

    But that is not always the case. Sometimes the issue is not capability. Sometimes the issue is energy. A person can be perfectly capable of performing an activity while finding it deeply uninspiring.

    The two dimensions are independent.

    Four Quadrants

    Thinking about assignments this way creates a useful distinction.


    		High EnergyLow Energy
    High CapabilityStrengthsCompetent but draining
    Low CapabilityGrowth opportunitiesAvoid if possible

    Most career advice focuses on capability. Become better. Acquire skills. Gain experience. Develop expertise.

    Less attention is given to energy. What activities make us curious? Which activities make time disappear? Which activities leave us energized rather than exhausted? Those questions matter too.

    The Competence Trap

    The most dangerous quadrant may actually be the one where capability is high and energy is low. These are the activities we can perform successfully. Managers trust us with them. Customers appreciate the results.

    Yet we gradually become less engaged. Because the work relies on strengths we possess, but not necessarily on strengths we enjoy using. The better we become, the more often we may be asked to perform it. That is the trap.

    Learning from Discomfort

    This does not mean we should avoid low-energy activities altogether. In fact, some of the most valuable learning happens there. Activities that consume energy often expose gaps in our understanding. They force us to develop new skills. They help us appreciate the realities faced by others.

    The goal is not to eliminate every draining task. The goal is to understand what role those tasks play in our development. An assignment can be worthwhile even when it is not energizing.

    Looking Beyond Capability

    Recently, I have started asking a different question when evaluating work.

    Not only: Can I do this?

    But also: What kind of energy does this create?

    The answer often reveals more than capability alone. Some activities align with our natural interests and strengths. Others draw on skills we possess but do not particularly enjoy exercising.

    Both have value. The important thing is recognizing the difference.

    An Open Reflection

    Perhaps career development is not only about becoming more capable. Perhaps it is also about becoming more aware. Aware of where we create value. Aware of how we learn. Aware of the activities that energize us and those that merely demonstrate competence.

    Capability determines what we can do. Energy influences how long we can do it well. The distinction seems obvious once noticed. Yet I suspect many of us spend years confusing the two.