Blog

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

  • Field Note: The Fear of Losing Touch

    A thought has been bothering me recently. Not because it is new. Because it keeps returning.

    I have spent much of my career moving toward advisory, assessment and strategic work. Over time, this has changed how I spend my days. Less execution. More analysis. Less operational responsibility. More conversations about capability, governance, direction and change.

    On most days, I consider this a natural consequence of experience. On some days, however, another question appears. Have I drifted too far away from the work?

    The Distance Created by Experience

    Experience creates perspective. That is one of its greatest benefits. Patterns become visible. Connections emerge. Problems that once seemed isolated begin to reveal common causes. This ability to zoom out is valuable. It allows us to see things that are difficult to observe from within the daily flow of work.

    But every advantage has a trade-off. The further we zoom out, the further we move away from the details. And sometimes those details matter.

    The Expert’s Dilemma

    This creates an interesting tension. To become an expert, we often need to move beyond execution. To remain relevant, we need to stay connected to it.

    Too much focus on day-to-day activities can make it difficult to see the bigger picture. Too much distance can make the bigger picture detached from reality. Neither extreme is ideal. The challenge is finding the right balance.

    A Question of Comfort

    When I examine this more closely, I am not actually worried that I have forgotten how things work. What I notice instead is that I have not spent enough time in operational roles recently to feel entirely comfortable there. That is a different concern.

    Not capability. Familiarity.

    Not knowledge. Proximity.

    The distinction matters. Because the solution is not necessarily to abandon strategic work.

    The solution may simply be to remain connected to execution often enough that reality continues to challenge assumptions.

    Staying Close Enough

    Perhaps expertise requires a certain distance. But perhaps it also requires a periodic return. A chance to experience the constraints, frustrations and trade-offs that practitioners face every day.

    Not because we need to perform those roles permanently. Because those experiences keep our thinking grounded. They provide friction. And friction is often where learning happens.

    An Open Question

    I am still thinking about this. How close to the work should an expert remain? How much distance is useful? How much distance is dangerous?

    I do not have an answer. What I do know is that expertise seems to involve a constant balancing act. We need enough distance to see patterns. And enough proximity to ensure those patterns still reflect reality.

    Perhaps the goal is not to choose between strategic thinking and operational experience. Perhaps the goal is to keep one foot in each world.

  • Field Note: The Seniority Paradox

    For a long time, I believed that seniority was largely about perspective. The more experience you gained, the further ahead you could see. You recognized patterns earlier. You connected seemingly unrelated issues. You developed a broader view of systems, organizations and change. This understanding is not wrong.

    But recently I have started to suspect that it is incomplete.

    The Traditional View of Seniority

    Many professional careers appear to follow a familiar trajectory:

    Operational → Tactical → Strategic

    Early in our careers, we focus on execution. Later, we coordinate and manage. Eventually, we become responsible for strategy, direction and long-term thinking.

    The implicit assumption is that seniority means operating at increasingly higher levels of abstraction. The higher you operate, the more senior you are. At least, that is what I used to think.

    Seeing Further

    Experience does bring perspective. An experienced consultant, architect or manager often sees things that others do not. Patterns emerge more quickly. Root causes become easier to recognize. The consequences of decisions become easier to anticipate.

    This is one of the rewards of experience. You learn to see further. The problem is that seeing further can become a habit.

    The Trap

    Once you become accustomed to thinking strategically, it is tempting to view every problem through that lens. A process issue becomes a governance discussion. A delivery challenge becomes an operating model question. A local problem becomes a transformation initiative.

    Sometimes this is exactly what is needed. Sometimes it is not. The customer may simply need help solving the problem directly in front of them. In those moments, the broader perspective can become a distraction rather than an advantage. Not because it is wrong. Because it is arriving at the wrong time.

    A Different View of Seniority

    This led me to a realization. Perhaps seniority is not primarily about operating at the highest level of abstraction. Perhaps it is about moving between levels of abstraction.

    The truly valuable expert can discuss strategy in one conversation and execution in the next. They can connect long-term objectives to immediate actions. They can explain the bigger picture without losing sight of today’s challenges. Most importantly, they know which perspective is needed in a particular moment. That is a different skill altogether.

    Meeting People Where They Are

    Looking back, some of the most effective experts I have worked with shared a common trait. They did not feel compelled to demonstrate how much they knew. They did not constantly elevate discussions to the highest possible level.

    Instead, they seemed remarkably good at meeting people where they were. If a strategic discussion was needed, they could provide it. If a practical solution was needed, they could provide that too. Their expertise was visible not because they operated above everyone else, but because they could connect different perspectives effortlessly.

    The Paradox

    This is where the paradox appears. Many people assume seniority means seeing further. I increasingly believe that true seniority means seeing further without losing sight of what is immediately in front of you.

    The challenge is not reaching a higher level of abstraction. The challenge is knowing when to use it. And perhaps the most senior thing you can do is not demonstrate how far ahead you can see. Perhaps it is helping others take the next meaningful step.

    An Open Reflection

    I am still thinking about this. Partly because it challenges my own assumptions about expertise. For years, I associated growth with moving upward: from operational concerns toward strategic ones.

    Today, I am beginning to suspect that maturity may look different. Not a ladder. More like a range. The ability to move freely between perspectives. To understand the larger pattern. And at the same time, remain fully engaged with the problem that is right in front of you.

    That seems like a more useful definition of seniority. And perhaps a more difficult one as well.

  • Field Note: Thinking Through Dialogue

    For most of my life, I assumed that thinking happened before conversation. First, you form an opinion. Then you discuss it. First, you develop an idea. Then you explain it.

    Recently, I have started to suspect that my own process works differently. In many cases, I do not seem to know what I think until I begin talking about it.

    The Myth of the Blank Page

    There are people who appear capable of sitting down with a blank sheet of paper and generating ideas. I have always admired that ability. I have also spent a considerable amount of time waiting for it to happen.

    More often than not, it doesn’t. If I sit alone with a problem, I can certainly analyze it. I can gather facts. I can organize information. But genuinely new ideas seem to emerge elsewhere. They emerge in interaction.

    Ideas Hidden in Conversation

    Looking back, many of the ideas I consider valuable did not appear during solitary reflection. They appeared during discussions. A colleague asked an unexpected question. A customer challenged an assumption. A workshop revealed a pattern. A conversation connected two concepts that had previously seemed unrelated.

    The idea was not fully present beforehand. The conversation helped create it. This realization has gradually changed how I think about thinking. Perhaps dialogue is not something that happens after reasoning. Perhaps, for some people, dialogue is part of the reasoning itself.

    The Role of Friction

    One possible explanation is that conversations introduce friction. A statement is challenged. An assumption is exposed. A contradiction becomes visible. A vague intuition is forced into words. Something that felt obvious suddenly turns out to be difficult to explain.

    That friction is productive. It pushes thinking forward. Many of the insights I value most emerged not when someone agreed with me, but when they asked a question I could not immediately answer.

    A New Kind of Dialogue Partner

    Recently, I have found myself having more of these exploratory conversations with AI. That statement is easy to misunderstand. The interesting part is not that AI provides answers. Nor is it that AI replaces expertise. In fact, many of the observations, experiences and patterns still come from my own work.

    What has changed is that there is now an always-available dialogue partner. A half-formed idea can be explored immediately. An observation can be challenged from different angles. A concept can be reformulated until it becomes clearer. A pattern can be tested against examples from other domains.

    The value is not that the AI discovers the idea. The value is that the dialogue helps reveal it.

    Dialogue as a Thinking Tool

    The more I reflect on this, the less I see conversation as a way of communicating finished thoughts. Instead, I increasingly see it as a way of creating them. This applies equally to discussions with colleagues, customers, friends and AI. The common factor is not the participant. The common factor is the interaction.

    Ideas become visible when they encounter another perspective. Even if that perspective exists only to ask questions, challenge assumptions or suggest alternative interpretations.

    An Unexpected Realization

    For years, I believed that I needed to become better at brainstorming. Perhaps that was the wrong goal. Perhaps my mind simply works differently. Perhaps my strongest ideas are not generated in isolation. Perhaps they emerge through dialogue.

    If that is true, then conversations are not interruptions to thinking. They are one of the ways thinking happens. And in a world where AI can participate in those conversations, the opportunity may not be that we can get answers faster.

    The opportunity may be that we can explore ideas more deeply, more frequently and with less friction than before. I am still trying to understand the implications of that. But the observation itself feels increasingly difficult to ignore.

    Some people think by writing. Some people think by reflecting. I appear to think by talking.

  • Field Note: Two Kinds of Blogs

    I recently realized that I have been thinking about blogs in the wrong way. For most of my professional life, I assumed that writing followed a simple sequence:

    Think → know → write

    The purpose of a blog was to communicate something that had already been figured out. You learned something. You formed an opinion. You developed a framework. Then you wrote about it. The blog was a publishing mechanism. Nothing more.

    The Reporting Blog

    This is the type of blog most professionals write. Its purpose is to report existing knowledge. Examples include:

    • Lessons learned from a project
    • Explanations of a methodology
    • Reviews of a framework
    • Conference summaries
    • Practical advice

    The underlying assumption is: I know something that may be useful to others.

    There is absolutely nothing wrong with this. In fact, most professional blogs should probably do exactly that. But recently I discovered another possibility.

    The Discovery Blog

    The second type of blog serves a completely different purpose. Instead of communicating conclusions, it helps generate them. The process looks more like this:

    Observation → writing → reflection → insight

    The author does not necessarily know where the idea will lead. Writing becomes part of the thinking process. The blog becomes a laboratory rather than a broadcasting platform. This was a surprising realization for me.

    Thinking Through Dialogue

    The insight became even more interesting when I connected it to something I have noticed about my own way of thinking. I have never been particularly good at sitting alone and brainstorming. Many people seem able to start with a blank page and generate ideas. My mind does not appear to work that way.

    Instead, most of my useful ideas emerge through dialogue. A conversation introduces a question. An observation triggers a response. A challenge reveals an inconsistency. A pattern suddenly becomes visible. The thinking happens in the interaction. Only afterwards do I realize what I think.

    This explains why some of my most valuable insights have emerged from discussions rather than solitary reflection. The dialogue itself becomes part of the reasoning process.

    Writing as a Dialogue

    Perhaps that is why the idea of a discovery-oriented blog feels so appealing. Writing does not have to be the final step. Writing can become another form of dialogue. Not necessarily with other people. Sometimes with oneself. Sometimes with future readers. Sometimes with an idea that has not fully formed yet.

    A field note captures an observation. The act of writing clarifies the observation. New questions emerge. Those questions lead to new field notes. Over time, a line of thinking begins to develop. The blog becomes part of the conversation.

    A Different Relationship with Uncertainty

    The discovery blog also changes the role of uncertainty. In a reporting blog, uncertainty can feel like a weakness. The expectation is that the author knows the answer.

    In a discovery blog, uncertainty is often the starting point. A good field note can begin with:

    I noticed something.

    Or:

    I am not sure why this keeps appearing.

    Or:

    These two things seem related, but I do not yet understand how. The goal is not to provide closure. The goal is to make progress.

    An Unexpected Possibility

    The most surprising realization is that a blog may be useful long before there is anything important to report. In fact, it may be most useful before that point.

    Instead of documenting finished ideas, it can help create them. A field note becomes a record of an investigation. A collection of field notes becomes a trail of reasoning. And occasionally, several observations converge into something larger. A hypothesis. A framework. Perhaps even a genuinely new idea.

    I used to think that blogs existed to share what we know. I am beginning to suspect that some blogs exist to help us discover it.

  • Field Note: What If Testing Is Just a Form of Assessment?

    Over the past few weeks, while working on assessment models for QA capability and Data Quality, I stumbled upon an idea that has been difficult to shake off.

    The observation itself is surprisingly simple: the structure of a QA capability assessment and a system test is essentially the same. The only thing that changes is the object being assessed.

    At first, this felt like an interesting analogy. The more I thought about it, however, the more it began to feel like something more fundamental.

    Starting with System Testing

    Most of us who have worked in testing have been taught a familiar model:

    • Requirements define what the system should do.
    • Test cases verify those requirements.
    • Defects are reported.
    • A release decision is made.

    Nothing controversial there.

    But viewed through a different lens, the process can be described in another way:

    • Requirements define a reference model.
    • Testing is an assessment process.
    • Test results are evidence.
    • Defects are findings.
    • The test report is an evaluation.
    • The release recommendation is decision support.

    In other words, system testing can be described as a quality assessment of a software system. That may sound like a semantic distinction, but it has interesting consequences.

    Looking Beyond Testing

    Around the same time, I was working with assessment models for QA capability and Data Quality.

    Those assessments typically look like this:

    • Define a reference model.
    • Gather evidence through interviews, reviews and metrics.
    • Identify gaps.
    • Evaluate current capability.
    • Recommend improvements.

    Structurally, the process is identical. The only difference is that the object being assessed is no longer a software system. Instead of assessing a product, we assess:

    • A QA organization
    • A data platform
    • An operating model
    • A security posture
    • An architecture

    The pattern remains the same:

    Object → reference model → assessment activities → evidence → findings → evaluation → decision support

    Once you see it, it becomes difficult to unsee.

    Is QA Already Solving This?

    One could argue that Quality Assurance and later Quality Engineering have already attempted to broaden testing into something larger. There is certainly truth in that:

    Testing evolved from defect detection. QA expanded the focus toward process quality. Quality Engineering expanded it further toward prevention, automation and quality built into delivery. Yet even Quality Engineering remains largely anchored in the vocabulary of testing:

    • Test automation
    • Test coverage
    • Test strategy
    • Test management
    • Test environments

    The underlying mental model often remains:

    Software → testing → quality

    What if the model should instead be:

    Object → assessment → evidence → quality evaluation

    That is a subtle but important shift.

    A Different Perspective on Testing

    If assessment becomes the primary concept, testing becomes one assessment technique among many.

    Consider the following examples:

    ObjectAssessment Technique
    Source CodeUnit Testing
    Software SystemSystem Testing
    ArchitectureArchitecture Review
    Data PlatformData Profiling
    Security PosturePenetration Testing
    QA OrganizationInterviews and Document Review

    Different techniques, same assessment pattern.

    This perspective also changes the questions we ask.

    Instead of how many test cases have we executed, we ask: have we collected sufficient evidence?

    Instead of what is our test coverage, we ask: which quality attributes have been assessed?

    Instead of how many defects remain, we ask: what is our confidence level and residual risk?

    These are fundamentally different conversations. They are also conversations that executives tend to understand much better than traditional testing metrics.

    A Broader Quality Assessment Framework?

    Perhaps the most interesting implication is organizational rather than technical. Many consulting organizations offer services such as:

    • System testing
    • Data quality assessments
    • Security reviews
    • Architecture assessments
    • QA capability assessments

    These are often positioned as separate offerings with separate methodologies.

    But what if they are all instances of the same underlying discipline? A generic quality assessment framework could potentially provide:

    • A common assessment model
    • A common reference model structure
    • A common evidence model
    • A common reporting approach
    • A common maturity model

    The assessed object changes. The assessment pattern does not.

    An Open Question

    I do not yet know whether this idea is genuinely new or merely a reframing of concepts that already exist within Quality Engineering.

    What I do know is that it has changed the way I think about testing. For years, I viewed testing as a discipline concerned with finding defects.

    Today, I increasingly see testing as one technique for generating evidence about quality. That may sound like a small distinction. I suspect it is not.

    If the observation holds, then perhaps testing is not the overarching discipline after all. Perhaps quality assessment is. And testing is simply one of its most visible techniques.

  • Field Note: Revisiting Quality

    For a long time, I have had a somewhat complicated relationship with the word “quality.” Like many people who started their careers in testing and QA, I gradually became uncomfortable with the label. Not because quality is unimportant, but because the term often seemed too narrow.

    When people hear “quality,” they frequently think about testing. When they hear “testing,” they often think about defects. And when they think about defects, the conversation quickly becomes operational rather than strategic.

    Over time, I found myself increasingly interested in topics that appeared to sit outside the traditional quality domain:

    • Architecture
    • Data
    • Governance
    • Operating models
    • Organizational capability
    • Decision-making

    These seemed like larger and more interesting questions. Or so I thought.

    An Unexpected Observation

    Recently, while working with different kinds of assessments, I started noticing a recurring pattern. The object being assessed varied considerably:

    • A software system
    • A data platform
    • An organizational capability
    • A process
    • An architecture

    Yet the assessment itself always seemed to follow the same structure.

    First, there was an idea of what “good” looked like. Then there was a way of collecting evidence. Then findings were identified. Finally, a judgment was made about fitness, capability, risk or readiness. The terminology changed, but the pattern did not.

    The Question Behind the Question

    At first, I thought I was moving away from quality. Now I am no longer sure. Perhaps I was not moving away from quality at all. Perhaps I was moving away from a narrow interpretation of quality. Traditional quality discussions often focus on products:

    • Does the software work?
    • Does it meet requirements?
    • How many defects remain?

    Important questions, certainly. But they are not the only quality questions.

    We also ask:

    • Is the architecture sustainable?
    • Is the data trustworthy?
    • Is the organization capable?
    • Is the process effective?
    • Is the operation resilient?

    These are quality questions too. We simply tend to classify them differently.

    Quality as Fitness for Purpose

    The more I think about it, the more useful the classic definition of quality becomes:

    Fitness for purpose.

    The phrase is deceptively simple. It does not limit quality to software. It does not limit quality to testing. It does not even limit quality to technology. Anything can be evaluated in terms of fitness for purpose:

    • A system.
    • A dataset.
    • A process.
    • An organization.
    • An operating model.
    • An architecture.

    The assessed object changes, but the underlying question remains remarkably consistent.

    Assessment as the Missing Link

    This realization led me to another thought: perhaps quality is not primarily about testing. Perhaps quality is primarily about assessment. Assessment is the mechanism through which we determine fitness for purpose.

    Testing is one assessment technique. Reviews are another. Interviews are another. Metrics analysis is another. Profiling is another.

    The specific techniques matter less than the purpose they serve. They generate evidence. That evidence supports an evaluation. That evaluation supports a decision.

    Viewed this way, testing becomes part of a much larger family of activities.

    A Wider Perspective

    Ironically, the more I tried to move away from quality, the more frequently I encountered it. Not the operational version of quality, but the broader version. The version concerned with evidence, confidence, risk and fitness for purpose. The version that appears whenever people need to make informed decisions about systems, data, organizations or processes.

    Perhaps quality is not a niche after all. Perhaps it only appears that way when viewed through the lens of testing.

    When viewed through the lens of assessment, quality seems to show up almost everywhere.

    An Open Thought

    I am not yet sure where this line of reasoning leads. It may turn out to be nothing more than a useful way of organizing ideas. Or it may suggest that testing, quality assurance, data quality, architecture reviews and capability assessments are all manifestations of the same underlying pattern. For now, I am content to leave that question open.

    What I find interesting is that an attempt to move beyond quality has unexpectedly led me back to it. Only this time, it looks much bigger than before.

  • Field Note: Assessment Requires Two Forms of Expertise

    One of the most interesting observations from recent assessment work is that high-quality assessments rarely emerge from domain expertise alone. Nor do they emerge from assessment methodology alone.

    The best outcomes seem to arise from the combination of both.

    The Domain Expert

    Every assessment requires people who understand the subject being assessed. They understand the context, the technology the operational realities. They know where the complexity lives.

    Without this expertise, important signals are easily missed. Recommendations risk becoming generic. Conclusions risk becoming detached from reality. Domain expertise provides depth.

    The Assessment Expert

    At the same time, domain expertise alone is often insufficient. Understanding a system is not the same as assessing it. Assessment requires a different set of capabilities:

    • Structuring observations.
    • Evaluating evidence.
    • Identifying patterns.
    • Separating symptoms from root causes.
    • Testing assumptions.
    • Developing findings and recommendations.
    • Maintaining consistency and traceability.

    Assessment expertise provides structure.

    The Limitation of Either Role Alone

    A domain expert working alone may possess deep knowledge but struggle to transform observations into a coherent assessment. The result can become anecdotal, incomplete, or difficult to communicate.

    An assessment expert working alone may apply a rigorous methodology but lack sufficient understanding of the domain. The result can become superficial or disconnected from operational reality.

    Both forms of expertise are valuable. Neither is sufficient on its own.

    A Productive Tension

    What makes the combination powerful is the interaction between the two perspectives. The domain expert challenges the assessment model with reality. The assessment expert challenges the domain expert’s assumptions with evidence and structure.

    One contributes understanding. The other contributes evaluation.

    One asks:

    What is happening?

    The other asks:

    What does it mean?

    The dialogue between the two often produces insights that neither would have reached independently.

    Assessment as a Discipline

    This observation has broader implications. Many organizations treat assessments primarily as a domain activity. As a result, assessments are often led exclusively by subject matter experts.

    Yet assessment itself appears to be a professional discipline. Just as facilitation, coaching, architecture, and auditing require specific skills, assessment requires its own capabilities.

    Methodology matters.

    Evidence matters.

    Reasoning matters.

    Structure matters.

    A Working Hypothesis

    This leads me to a hypothesis:

    The quality of an assessment is determined not only by the quality of domain expertise, but by the quality of the interaction between domain expertise and assessment expertise.

    The strongest assessments do not emerge from either role alone. They emerge from collaboration between people who understand the system and people who understand how to assess it.

    Understanding provides insight. Assessment provides rigor. Both are required.