Category: Field Notes

  • Field Note: The Suit Did Not Become Less Beautiful

    I recently bought a made-to-measure suit. It is not bespoke in the strictest sense. It was adapted from established patterns and standard sizes rather than designed entirely from scratch. Even so, the difference from an ordinary off-the-rack suit is noticeable. The jacket follows my body more closely. The shoulders, sleeves and waist relate properly to one another. The trousers fall cleanly. The outfit appears coherent rather than merely assembled.

    A good suit does something unusual to the male body. It strengthens the shoulders, clarifies the chest, narrows the waist and creates a continuous line through the trousers. The lapels, shirt collar and tie direct attention toward the face. Differences in physique are not removed, but reorganized into a more deliberate silhouette.

    The result is not accidental. The classic suit has been refined over generations to make a man appear balanced, composed and intentional.

    When I wear mine, I look better in it than I do in most ordinary clothes. I also feel better in it. That should be sufficient reason to wear it. Yet if I wore it to the office on an ordinary working day, I would probably have to explain myself. Someone might ask whether I had an important client meeting, a job interview, a wedding or perhaps a funeral. A suit is no longer interpreted simply as clothing. It is evidence that something unusual must be happening.

    The strange part is that I have watched this reversal take place during my own working life.

    Ready to meet the client

    When I began working in the Netherlands around thirty years ago, the professional norm was a suit and tie—or at least a jacket with straight trousers. The clothing communicated readiness.

    In consulting, the assumption was that one should be able to meet a client. The suit was therefore not necessarily a claim of exceptional importance. It was the normal condition of being professionally prepared.

    Casual clothing carried the more specific message. A deliberately casual outfit could indicate that someone expected to remain in the office and would not be meeting clients that day. The deviation from the norm required a reason. Formality did not.

    The tie was part of that system, although it also became the first part to create noticeable friction. On warm days, in particular, it could feel unnecessary and uncomfortable. People began to question why a narrow strip of fabric around the neck should be required to demonstrate professional competence.

    Once the tie became negotiable, the rest of the system gradually became negotiable too. The jacket remained, but increasingly without the tie. Straight trousers gradually lost ground to jeans. Formal leather shoes were replaced by more casual alternatives. The professional uniform did not disappear in one decisive moment. It loosened one element at a time.

    When I moved to Sweden, I encountered a reference model that had already shifted considerably further. The tie was the exception rather than the rule. Jeans had largely replaced tailored trousers. A more restrained and informal style communicated social ease and cultural fit. The same clothing that had signalled professional readiness in the Netherlands could now risk signaling distance, rigidity or excessive formality. I even suspect that wearing a tie may once have contributed to my not surviving an assignment interview. I cannot prove it, and other factors may have been more important. But the possibility itself is revealing.

    A garment that had once demonstrated that I understood professional expectations may have suggested that I did not understand them. The tie had not changed. The reference model around it had.

    The webcam-ready professional

    Then Covid arrived and accelerated changes that were already underway. For many people, work moved into the home. The professional person was reduced to the part visible through a webcam. Clothing no longer needed to present a complete person in a shared physical environment. It needed to produce an acceptable rectangle on a screen.

    The new minimum was something like be sufficiently dressed above the waist, do not appear to have just left bed, look representative enough for a video call. What happened below the camera was largely outside the available evidence.

    Even after offices reopened, much of the old dress logic did not return. The standard became less a matter of being formally prepared and more a matter of avoiding obvious inappropriateness. One should perhaps wear slightly more than shorts and a Hawaiian shirt because clients might visit the office, but the distance between minimum acceptability and considered elegance had become enormous.

    Some managers continued to dress somewhat more formally. So did some people who perhaps wished to become managers. This gave the remaining formal clothing an additional meaning. A jacket or suit could now be interpreted not only as professional preparation, but as a performance of rank, authority or ambition.

    That makes the choice more socially complicated. A man may wear a suit because he likes how it looks and feels. Others may interpret it as an attempt to appear more important than they are. The clothing remains the same. The social explanation changes.

    What makes an outfit good?

    In two earlier field notes, I compared my Apple Watch with my Victorinox I.N.O.X. Automatic. The Apple Watch won on accuracy, functionality, adaptability, information and integration with the digital world. The Victorinox won on physical presence, materials, craftsmanship, visual depth and attachment. The watches occupied the same wrist but represented different ideas of value.

    The comparison depended on the reference model: the set of qualities against which the watches were judged. Change the criteria, or change the weight assigned to them, and the result changes too.

    Clothing reveals a similar conflict, but at a larger scale. A watch occupies a small part of the body. An outfit occupies almost the entire visible person. I can wear only one primary outfit at a time, which means that competing definitions of good clothing must fight for the same physical territory.

    The classic suit performs exceptionally well against one reference model. It provides structure, proportion, visual coherence, dignity and formality. It communicates care and preparation. A well-fitted suit can make an ordinary male body appear more balanced and commanding without becoming overtly decorative.

    Earlier conventions of menswear placed considerable weight on these qualities. Clothing helped distinguish public from private life, work from leisure and formal occasions from ordinary ones. Appearing properly dressed was part of participating in the situation. The wearer accepted a degree of inconvenience in exchange for elegance, ceremony and social clarity.

    The contemporary reference model places greater weight elsewhere. Clothing should be comfortable. It should be easy to wash, easy to combine and suitable for several different situations. It should tolerate changes in body shape and require little specialist knowledge from the wearer. It should work in an office, on public transport, in a café and at home. Ideally, it should not require ironing, polishing, specialist cleaning or careful storage. It should also avoid making the wearer appear overdressed.

    These are not irrational requirements. They represent genuine forms of value. A garment that looks elegant but feels restrictive, requires maintenance and appears inappropriate in most everyday environments may perform poorly against the realities of modern life. The suit can therefore remain aesthetically successful while becoming practically unsuccessful.

    The disappearing weight of elegance

    The change is not simply that comfort became more important. It is that elegance became less decisive. Imagine a reference model for menswear containing several dimensions:

    visual proportion;

    elegance;

    comfort;

    flexibility;

    ease of maintenance;

    affordability;

    social appropriateness;

    personal expression.

    A suit may score very highly on proportion and elegance. Depending on its fabric and construction, it may also perform reasonably well on comfort. But it will usually cost more, require greater care, tolerate fewer sizing errors and carry stronger social meaning than casual clothing.

    A contemporary casual outfit may score less strongly on silhouette and visual coherence, but better on comfort, flexibility, washability and social neutrality.

    Neither assessment requires anyone to deny that the suit looks better. The outcome changes because the dimensions receive different weights.

    Thirty years ago, appearing professionally prepared carried enough weight to justify the inconvenience of a jacket and tie. Today, comfort and ease often dominate the decision before appearance is seriously considered. Elegance remains desirable, but only after the clothing has passed several other tests.

    The suit did not lose because its ability to improve the male silhouette disappeared. Its strongest quality simply became less important to the judgment.

    One body, one choice

    The competition for the wrist is severe because most people wear only one watch at a time. The competition for the body is more severe still. A mechanical watch and a smartwatch compete for one relatively small physical slot. A suit competes with every other possible way of dressing the whole body.

    Each morning becomes a small assessment.

    What will I be doing?

    How warm will it be?

    Will I need to walk or cycle?

    Will I be sitting for long periods?

    How will everyone else be dressed?

    Will the suit communicate confidence, or create distance?

    Will I look elegant, or merely overdressed?

    The answer is rarely determined by appearance alone.

    This makes casualization self-reinforcing. When suits are common, wearing one attracts little attention. When suits become rare, wearing one becomes conspicuous. The same garment that once allowed a man to conform now causes him to stand apart.

    That changes its practical value. A man may admire suits and still avoid wearing one because he does not want to explain the choice. He may not want colleagues to assume he has an interview, an important presentation or some ceremonial obligation. He may not want to look more formal than his manager or appear to be claiming a status that has not been assigned to him.

    The reference model is therefore not entirely personal. It is also social. An outfit must not only satisfy the needs of the wearer. It must interact with the expectations of everyone who sees it. Comfort can be experienced individually. Formality exists between people.

    The coordination problem

    Many men may look better in jackets, tailored trousers and properly fitted shirts. They may even agree that they do. But no individual man controls the dress code of the environment around him. If everyone else dresses casually, the first person to return to formal clothing pays a social cost. He becomes the exception before the potential aesthetic improvement can become normal again.

    The suit once benefited from a shared convention. Men did not need to justify wearing one because the surrounding culture had already justified it for them. When that convention weakened, the suit lost more than popularity. It lost the social infrastructure that made wearing it effortless.

    Casual clothing now benefits from that infrastructure. It is not merely physically comfortable. It is socially comfortable. It rarely requires explanation. It does not imply that the wearer considers the occasion more important than everyone else does. It does not visibly demand that others respond with the same degree of formality.

    Nobody asks a colleague in jeans and trainers:

    Why are you dressed casually today?

    But a colleague wearing a suit may immediately be asked:

    What is the occasion?

    That asymmetry reveals which reference model has become dominant.

    Casual clothing is treated as neutral. Dressing well has become an event.

    Better according to what?

    The suit exposes a recurring problem in assessment. We often speak as though a product, capability or practice is simply good or bad. But every judgment depends on some conception of the required, intended or expected state.

    A classic suit may be better than casual clothing when the objective is to create a structured and elegant male silhouette. Casual clothing may be better when the objective is to maximize comfort, simplify maintenance and move easily between different contexts. The disagreement cannot be resolved by examining the garments more carefully. It originates in the reference model.

    Even the evidence may be accepted by both sides. A person can agree that the suit improves proportion, that knitwear feels more comfortable, that trainers are easier to walk in and that tailored clothing requires more care.

    The dispute begins when those qualities are weighted and combined into a final judgment. This also means that a changing assessment outcome does not necessarily indicate a change in the subject itself. The suit may be much the same garment it was before. Its shoulders still create structure. Its lapels still frame the chest and face. Its trousers still lengthen the visible line of the legs. Its visual logic has not stopped functioning.

    What changed was the required state around it. A garment designed to satisfy an earlier understanding of public appearance now enters a world that expects clothing to satisfy a different combination of needs. The subject remained capable. The environment revised the criteria.

    Progress or exchange?

    It is tempting to describe the change as straightforward progress. Modern clothing is less restrictive. Dress codes are more flexible. People can express themselves more freely and move between professional and private life without changing clothes. Garments are easier to maintain, and formal appearance is less closely tied to respectability or professional legitimacy. Those are real gains.

    But progress in one reference model may conceal losses in another. The average outfit may have become more comfortable while becoming less flattering. It may be easier to maintain while offering less structure and visual coherence. It may allow greater individuality while also making indifference easier.

    Freedom from formal rules does not guarantee that the replacement will be equally considered. Casualization therefore need not be interpreted as either decline or liberation. It is an exchange between qualities. We gained convenience, flexibility and social ease. We gave up some ceremony, visual discipline and shared understanding of what it meant to dress well in public. Whether that exchange represents improvement depends, once again, on the reference model.

    From conformity to choice

    There is one important difference between wearing a suit now and wearing one thirty years ago. Then, the suit was largely conformity. Now, it can be choice.

    When everyone was expected to wear a suit, doing so revealed relatively little about the individual. The garment communicated professional membership more than personal preference.

    Today, wearing one voluntarily may communicate something more personal. It may say that appearance matters. That the wearer enjoys structure, materials and proportion. That comfort is not the only quality worth optimizing. That an ordinary working day can be a sufficient occasion for dressing well.

    The simplest explanation may also be the most honest:

    It looks better, and I feel better wearing it.

    That statement should be unremarkable. Yet in the current environment, it may sound surprisingly assertive. It openly admits that appearance matters and that the wearer has deliberately chosen the more elegant option.

    Modern male dress often permits considerable effort, provided that effort remains disguised. Expensive trainers, carefully selected casual clothing, fitness regimes and subtle status objects may all require attention and money. But saying that one has chosen a suit because it looks better makes the intention explicit.

    The suit no longer needs to justify what it does to the male silhouette. The wearer must justify why he still values it.

    Losing the body

    My made-to-measure suit has not become obsolete in the same way that unsupported software or discontinued hardware becomes obsolete. It still performs the function for which it was designed. It may even perform that function better than most contemporary alternatives. When I put it on, it still improves my proportions. It still creates a unified silhouette. It still makes me appear more deliberate and composed.

    But it must now compete against an expanded definition of what clothing is expected to provide. Comfort matters. Washability matters. Flexibility matters. Social neutrality matters. The ability to dress without thinking too much about clothing may matter most of all.

    The suit can win the aesthetic comparison and still lose the morning decision. That is the extension of the contest between my watches. The Apple Watch and Victorinox compete for one wrist while representing different value systems. Formal and casual clothing compete for the entire body while representing different ideas of everyday life.

    The crucial difference is that clothing is not merely an object I carry. It becomes the visible surface through which I enter a social environment. Choosing an outfit therefore means choosing not only which qualities I value, but which relationship I want to establish with the people around me.

    I began my career in a world where dressing casually required an explanation. Thirty years later, wearing the suit does. The suit did not fall from grace because it ceased to be beautiful.

    It lost because beauty, structure and elegance no longer carry enough weight to defeat comfort, convenience and social neutrality every morning. The better-looking outfit does not lose the assessment. It loses the body—because we are no longer assessing clothing primarily by how good it makes the body look.

  • Field Note: A Product Reference Model Through the Eyes of an Enterprise Architect

    When I first began thinking about a Product Reference Model, I imagined it as something new. Over time, I have become less convinced that it is.

    Perhaps I have simply been rediscovering ideas that Enterprise Architecture has explored for decades—but applying them at a different scale and with a different objective. Enterprise Architects rarely begin with source code. They think about relationships. Business capabilities support strategic objectives. Applications realize capabilities. Technology supports applications. Information flows between systems. The architecture is not merely a collection of artifacts. It is the set of relationships that makes those artifacts meaningful.

    That sounds surprisingly familiar. My Product Reference Model has gradually evolved into something that also emphasizes relationships. Business objectives relate to capabilities. Capabilities relate to features. Features relate to requirements. Requirements relate to BDD scenarios. BDD scenarios relate to implementation. Implementation relates to architecture. Architecture relates to operational procedures. Assessments relate back to business outcomes. Rather than replacing individual artifacts, the Product Reference Model attempts to make those relationships explicit.

    Perhaps that is exactly what Enterprise Architecture has always tried to achieve—only at enterprise scale. If that is true, then perhaps the Product Reference Model should not be viewed as a competing framework. Instead, it may simply be Enterprise Architecture viewed through the lens of a single product.

    The emphasis is different. Enterprise Architecture asks:

    How does this product fit within the enterprise?

    The Product Reference Model asks:

    How does every important aspect of this product fit together?

    That distinction may appear subtle, but it changes the audience. Enterprise Architects often think across portfolios, organizations and technologies. Product Owners, developers, testers and operations engineers think about one product. The underlying architectural principles remain remarkably similar.

    What also changes is the purpose. Traditional Enterprise Architecture often focuses on describing structure. The Product Reference Model attempts to preserve understanding.

    Every relationship should ultimately help answer one of the questions future teams inevitably ask: Why does this capability exist? Why was this architectural decision made? Why is this business rule still here? Where is the evidence that this requirement is implemented? Which assessment concluded that this capability was fit for purpose? How do all these artifacts relate to one another?

    Perhaps the Product Reference Model is therefore less concerned with documenting a product than with making the product understandable.

    It becomes a navigational model rather than merely a descriptive one. That observation also changes my own perspective. Instead of inventing another framework, perhaps I should learn more from Enterprise Architecture. Architects have already spent decades thinking about repositories, viewpoints, traceability, relationships, stakeholders and governance.

    The Product Reference Model may simply extend those principles into the daily life of a product team. Its contribution would not be another modeling language. Its contribution would be placing product understanding at the center.

    Perhaps the Product Reference Model can therefore be described quite simply:

    The Product Reference Model applies Enterprise Architecture principles to a single product, with particular emphasis on preserving product understanding throughout the product’s lifecycle.

    If Enterprise Architecture asks how an enterprise remains coherent…

    …perhaps the Product Reference Model asks how a product remains understandable.

  • Field Note: A Product Reference Model Through the Eyes of a Product Owner

    When I first began thinking about a Product Reference Model, I assumed it would become another documentation framework.

    As a Product Owner, that was not particularly attractive. Most Product Owners already spend their days balancing stakeholder expectations, refining the backlog, making priority decisions and answering questions from delivery teams. Another repository sounded like another responsibility.

    But perhaps that is the wrong way to think about it. As Product Owners, we rarely inherit a greenfield product. We inherit decisions. Business rules. Architecture. Operational procedures. Quality concerns. Technical debt. And, perhaps most importantly, we inherit understanding—or the absence of it.

    One of the most common questions a Product Owner asks is remarkably simple:

    Why?

    Why does this capability exist? Why do these customers receive different treatment? Why was this integration introduced? Why is this feature impossible to remove? Why was this architectural decision made? Why is this quality requirement so important?

    Those answers rarely exist in one place. Some are hidden in Jira. Some in architecture documentation. Some in source code. Some in BDD scenarios. Some in assessment reports. Many remain only in the memories of people who happened to be there.

    The Product Reference Model begins to make sense when it is no longer viewed as documentation. Instead, it becomes a map of product understanding. The Product Owner continues owning the backlog. Architects continue owning architecture. Developers continue owning source code. QA continues owning assessments and quality strategy. Operations continues owning operational knowledge.

    Nothing changes. Except that all these pieces become visible to one another. The Product Owner is no longer expected to know everything. The Product Owner is expected to know where the understanding lives.

    That changes the role in an important way. The backlog is no longer the product. It is merely one viewpoint of the product. The Product Reference Model allows the Product Owner to navigate the complete product landscape without becoming responsible for maintaining every artifact personally. Perhaps that is the real value.

    The Product Owner becomes the steward of product understanding rather than merely the owner of the backlog.

    Stewardship is different from ownership. Ownership often implies creating and maintaining artifacts. Stewardship means ensuring that future Product Owners inherit enough understanding to continue making good decisions.

    The Product Reference Model therefore does not make the Product Owner responsible for more documentation. It makes the Product Owner responsible for ensuring that the important answers remain connected. Perhaps continuity is not ultimately about preserving software. Perhaps it is about ensuring that every new Product Owner can understand the product they inherit before deciding how it should evolve.

  • Field Note: The Anatomy of a Product Reference Model

    When I first imagined a Product Reference Model, I thought of it as another repository for product knowledge. I no longer think that is the right mental model.

    A product already contains many repositories:

    • The Product Owner maintains the backlog.
    • Enterprise Architects maintain architecture models and Architecture Decision Records.
    • Developers maintain source code.
    • QA maintains assessments, test strategies and quality evidence.
    • Operations maintains runbooks and operational procedures.
    • Security teams maintain security documentation.

    Every discipline already has tools and repositories that support its own work. The Product Reference Model should not replace them. Instead, it should index them. For every significant artifact, it should make clear:

    • What is this artifact?
    • Where can it be found?
    • Who owns it?
    • Why does it exist?
    • How does it relate to the rest of the product?
    • Who depends on it?
    • Can everyone who needs it access it?

    The detailed knowledge remains within the artifact itself. The Product Reference Model provides the shared navigation structure through which that knowledge can be discovered and understood.

    This distinction is important. The Product Reference Model is not another documentation repository.

    It is a lightweight knowledge architecture.

    Perhaps Enterprise Architecture provides the right inspiration. Enterprise Architects have spent decades thinking about repositories, viewpoints, relationships, governance and traceability across an enterprise.

    The Product Reference Model applies many of those same principles at the scale of a single product. Rather than describing how an enterprise fits together, it describes how one product remains understandable throughout its lifecycle.

    Preserve knowledge where it belongs

    The Product Reference Model should duplicate as little information as possible. Every artifact should preserve its own knowledge.

    Requirements should explain the need behind them. Architecture Decision Records should preserve the trade-offs behind important decisions. BDD scenarios should preserve expected behavior. Operational procedures should explain the situations they were created for.

    Whenever an artifact already contains sufficient rationale, the Product Reference Model simply links to it. Whenever the rationale is missing, the Product Reference Model becomes the place where that missing understanding is preserved.

    The objective is therefore not more documentation. The objective is preserving understanding.

    A federated knowledge model

    The Product Reference Model also changes how I think about collaboration. Initially I believed that every stakeholder simply contributes information and everyone benefits.

    That is true, but incomplete: every stakeholder already possesses unique understanding. The Product Owner understands business intent. Architects understand structural decisions. Developers understand implementation. QA understands quality and evidence. Operations understands behavior in production.

    No single discipline possesses the complete understanding of the product. The Product Reference Model therefore creates a federated knowledge model.

    Each stakeholder maintains ownership of their own artifacts while making that understanding discoverable to everyone else. Ownership remains distributed. Understanding becomes shared.The Product Owner does not become an architect. The architect does not become a tester. QA does not become an operations engineer. Every discipline remains responsible for its own expertise.

    The Product Reference Model simply allows everyone to benefit from the expertise maintained by every other discipline.

    Knowledge amplification

    This also reveals the true value of the Product Reference Model. It does not create new knowledge. It amplifies the value of knowledge that already exists. Without the Product Reference Model, every discipline works largely within its own information space. With the Product Reference Model, each discipline gains visibility into the understanding maintained by all the others. The Product Owner better understands architectural constraints. The architect better understands business intent. QA better understands operational realities. Operations better understands the reasons behind design decisions. Developers better understand business priorities.

    Collective understanding increases without requiring everyone to become an expert in every discipline. Its value is therefore not additive. It is multiplicative. Every additional viewpoint increases the value of all the others.

    A practical implementation

    The Product Reference Model could simply exist as a structured wiki or similar workspace. Rather than storing all product knowledge itself, it provides a consistent structure through which stakeholders expose the artifacts they already own. Each section contains references to relevant artifacts together with any rationale that is missing from those artifacts themselves. The Product Reference Model therefore becomes the product’s navigation layer rather than its documentation repository.

    A simple definition

    Perhaps the Product Reference Model can be summarized as follows:

    The Product Reference Model is a federated knowledge architecture that indexes the significant artifacts of a product, preserves their relationships and rationale, and amplifies collective understanding by allowing every stakeholder to contribute the understanding they already possess while gaining access to the understanding maintained by every other stakeholder.

    Design principles

    • The Product Reference Model should contain as little duplicated information as possible.
    • Knowledge remains with the artifact that owns it.
    • Understanding is created by connecting those artifacts.
    • Every significant artifact should preserve not only what it contains, but also why it exists.
    • Every stakeholder contributes local understanding.
    • Every stakeholder gains systemic understanding.
  • Field Note: Pluribus and the Preservation of Knowledge

    While watching the TV-show Pluribus, one particular idea stayed with me long after the story ended.

    The series imagines that the accumulated knowledge of an individual could be transferred into something larger than themselves. In the story, this becomes a collective intelligence. Whether such a future is desirable is another discussion entirely.

    What fascinated me was the question behind it: How much of what a person knows disappears when that person dies?

    A few months before my mother passed away, we discussed a question that has remained with me ever since:

    “How can I dump everything in my head into something external so that it will survive me?”

    We were not talking about books or photographs. We were talking about understanding. The memories. The explanations. The reasons behind decisions. The connections between seemingly unrelated events. The answers to questions nobody had yet thought to ask.

    Since then I have begun noticing the same pattern everywhere. When my parents died, many possessions remained, but not always the stories that explained why they mattered. In software, source code often survives while the business rationale disappears. Organizations inherit systems but lose the people who understood them.

    Perhaps this is not really a software problem. Perhaps it is a human problem. Pluribus imagines one possible answer: preserve everything. Reality is unlikely to offer such a perfect solution.

    Yet perhaps we do not need to preserve everything. Perhaps we simply need to become better at preserving the answers to the important questions while the people who know those answers are still able to tell them.

    Artificial intelligence may eventually become the interface to that preserved understanding. But it cannot preserve what was never recorded. That responsibility still belongs to us.