This article is part of the Applied Business Architecture Project at StephenKlahr.com, where I maintain the free Business Architecture Cookbook, field notes, tools, study resources, and practical material focused on applying business architecture in real organizations. Everything is available without registration.

Spend enough time around business architecture and you will eventually find yourself in a conversation about tools, frameworks, repositories, modeling conventions, capability maps, value streams, information concepts, governance, and the endless question of how all of those things should be connected. Those are legitimate concerns, and I spend plenty of time thinking about them myself, but some of the most useful tools I bring into stakeholder meetings have almost nothing to do with architecture software.

They come from a much stranger bookshelf.

Over the years, I have become increasingly interested in books about cold reading, comedy, improvisation, rhetoric, interviewing, persuasion, history, and human behavior. At first glance, many of those subjects have little to do with business architecture, but the connection becomes clearer when you consider what much of the work actually requires. Business architects spend a great deal of time trying to understand how people think about the enterprise, how they explain what they do, what they leave unsaid, where formal descriptions diverge from operational reality, and how groups arrive at decisions when authority, incentives, history, and organizational politics are all involved.

For that reason, I have come to think of stakeholder engagement as something more substantial than the “soft skills” category where communication is often placed. It is one of the primary means by which the architect acquires the information necessary to understand the enterprise. If the quality of the conversation is poor, the quality of the architecture built from it is likely to be poor as well.

Cold Reading Without the Crystal Ball

Ian Rowland’s Cold Reading for Business is one of the more unusual books I have found useful for thinking about stakeholder engagement. Cold reading is normally associated with psychics, mentalists, and performers, but once you remove the theatrical claims, much of the underlying technique is about observation, conversational hypothesis testing, and careful attention to how another person responds.

There is an ethical and practical version of that skill that I find extremely useful in stakeholder discovery.

When I meet with stakeholders, I am almost always developing provisional hypotheses about what is happening. I listen for the terminology they repeat, the distinctions they consider important, the subjects they move past quickly, the people they defer to, and the places where the formal description of a process begins to sound different from the way work is actually performed. I am also paying attention to where people correct one another because those corrections often reveal ownership boundaries, competing mental models, or important differences between policy and practice.

The key is to keep those observations provisional.

The danger in talking about “reading people” is that it can easily become a form of overconfidence. The business architect starts believing that a glance, a hesitation, or a particular phrase has revealed what another person really thinks. That is not the approach I find useful. I am interested in using observation to formulate better questions, not in pretending that observation can replace evidence.

Instead of relying entirely on broad questions such as, “Can you walk me through the process?” I may eventually offer a tentative interpretation. I might say, “It sounds like the system itself is not really preventing this. Is the larger constraint that only one group has the authority to approve it?”

If I am right, we have probably moved closer to the real problem. If I am wrong, the correction can be even more valuable because people tend to become much more specific when explaining why an interpretation is incomplete.

I have found that some of the best information in discovery comes from those corrections. When people answer broad questions, they often give you the official process because that is the easiest place to begin. When they correct an incomplete interpretation, they are often forced to explain the exceptions, relationships, constraints, and informal practices that make the enterprise work in reality.

A stakeholder might respond, “No, technically anybody can submit it, but operations will not act until regional finance approves the exception.”

That single correction can tell you something about decision rights, governance, process behavior, organizational dependencies, and the difference between what a system permits and what the operating model allows.

This is where an apparently quirky book becomes surprisingly relevant to architecture work.

What Joke Writing Can Teach a Business Architect

Another book on my recent reading list is Elliott Kalan’s Joke Farming: How to Write Comedy and Other Nonsense. Kalan, a former head writer for The Daily Show, approaches joke writing as a craft that can be studied, practiced, broken down, and improved. What interests me is not the prospect of becoming a comedian. I have no desire to turn a stakeholder session into open-mic night. What interests me is the machinery underneath the joke.

A joke depends on understanding what the audience thinks is happening. The writer has to know where the audience’s attention is going, which assumptions they are making, how much information they need, which words are carrying the idea, and when the moment is right to redirect their expectations. Structure, timing, wording, tone, and audience awareness all play a part, and relatively small changes can alter whether the whole thing works.

Those are useful things to study if you spend a significant portion of your professional life in rooms full of stakeholders.

When I am leading a meeting, I am paying attention to more than the literal content of what people are saying. I want to know whether the room is still with me, whether an explanation has landed, whether a stakeholder is becoming defensive, whether someone is waiting for permission to disagree, and whether everyone appears to recognize something that nobody has quite been willing to say aloud. A good facilitator needs some awareness of timing because the same question can produce a very different response depending on when and how it is asked.

Humor can occasionally help with this, provided it is used with some restraint. A well-timed observation can lower the temperature in a difficult conversation, acknowledge an absurdity that everybody already recognizes, or create enough human connection to get people out of the formal language they brought into the room. It can also tell you something about the group. What people laugh at, hesitate over, qualify, or suddenly become careful about often reveals something about the organization itself.

The useful lesson from comedy is therefore not “be funny.” It is to become more attentive to the audience and more deliberate about language.

A business architect who can explain the same concept three different ways, recognize that the second explanation is the one that connected, and adjust the rest of the conversation accordingly is doing something much more important than presentation polish. The architect is increasing the likelihood that the people in the room actually share an understanding of the thing being discussed.

The Meeting Starts Before the Meeting

The same philosophy shapes how I prepare for meetings. I do not believe the meeting should be the moment when the business architect begins thinking seriously about the problem. If I am asking people to give me an hour of their day, particularly if senior leaders or scarce subject-matter experts are involved, I should have done enough work beforehand to make that hour useful.

Before an important stakeholder session, I want to know who will be there, what roles they play, what authority they possess, what decisions have already been made, what terminology the organization uses, what previous analysis exists, and where the likely points of disagreement may be. If there are prior presentations, operating procedures, architecture artifacts, project materials, organizational charts, or decision records available, I want to review them before the meeting rather than asking everyone in the room to recreate the history for me.

I also try to develop what I think of as a theory of the meeting.

I want to understand what I am actually trying to learn and what would make the session successful. There may be ten questions I would like answered, but usually there are one or two that are substantially more important than the others. I want to know what those questions are before the meeting starts.

I also think about where the conversation is likely to become difficult, whether there is someone whose knowledge may be overlooked because of title or personality, and which subjects are likely to consume twenty minutes simply because everyone has an opinion about them. There are topics in every organization that function like conversational gravity wells. Once the room drifts into them, they can absorb the rest of the meeting regardless of whether they have anything to do with the decision at hand.

Good preparation makes it easier to recognize those moments and steer the discussion without appearing rigid.

In fact, the better prepared I am, the less attached I need to be to my original agenda. If I know the context and understand the problem, I can listen rather than waiting for my next opportunity to ask a prepared question. I can follow an unexpected line of discussion when it becomes more valuable than the topic I had planned to address next. I can recognize when an apparently minor comment has exposed an assumption that changes my understanding of the entire problem.

Preparation creates room for improvisation.

This is one reason I am interested in disciplines outside business architecture. Meetings rarely behave exactly as planned. People disagree in ways you did not anticipate, somebody introduces information that changes the problem, an executive joins halfway through, or the subject-matter expert you expected to rely on turns out to have a different view from the rest of the organization. The architect needs enough command of the material to adjust without losing the purpose of the session.

Be the Authority Without Performing Authority

When I convene a meeting, I want to be the authority in the room without behaving as though I am the most important person in it.

By authority, I do not mean organizational rank or superior knowledge of the business. In many stakeholder sessions, the business architect will have neither. I mean that if I have called the meeting, I should know why we are there, understand the problem well enough to guide the discussion, and be capable of keeping the conversation productive when it begins to drift.

People should feel that the meeting is in capable hands.

There is a certain confidence required for that. A facilitator who apologizes for every question, abandons the agenda whenever someone senior speaks, or allows the discussion to wander indefinitely is not really facilitating. At some point, someone has to be willing to say, graciously, that a topic deserves its own discussion or that the group needs to return to the decision in front of them.

Authority exercised poorly creates the opposite problem. The architect begins talking too much, correcting terminology unnecessarily, defending the model instead of listening to the business, or turning the session into a demonstration of architectural expertise. The meeting becomes about the architect rather than the enterprise.

The posture I prefer is closer to being a good host.

The Architect as Host

A good host prepares before people arrive, understands why everyone has been invited, notices who seems uncomfortable, pays attention to the flow of conversation, and makes sure one guest does not dominate everyone else. The host has responsibilities and clearly exercises some control over the gathering, but the gathering is not supposed to be about the host.

I think stakeholder engagement works much the same way.

When I am facilitating, I want to be gracious, accommodating, attentive, and firmly in control of the purpose of the meeting. I want people to feel comfortable challenging my interpretation because disagreement usually improves the architecture. I want the quiet subject-matter expert to have space to speak, particularly when the rest of the room is beginning to converge too quickly on an answer. I want senior leaders to know that I respect their time without allowing their presence to silence the people who understand the operational details better than anyone else.

I also try to listen continuously rather than merely waiting for the current speaker to finish. Sometimes the most important information is embedded inside an answer to a completely different question. Someone may casually mention that “we stopped doing that after the acquisition,” or that “technically this belongs to finance, but operations handles it now.” Those comments are easy to miss if you are preoccupied with getting through a list of questions, but they can point directly to the historical and organizational reasons the current state looks the way it does.

Being accommodating does not mean surrendering control. A good host can change the order of the evening without losing track of why everyone is there, and a good facilitator can do the same thing. I can allow an unexpected conversation to develop because it is producing useful information, while still recognizing when it has run its course. I can challenge an assumption without embarrassing the person who made it, and I can redirect someone senior without turning the redirection into a contest over status.

This balance helps avoid two common extremes in stakeholder engagement. One is the architect who dominates the room, treats every conversation like an oral examination, and leaves stakeholders with the impression that the purpose of the meeting was to demonstrate the architect’s expertise. The other is the architect who becomes so accommodating that the session has no structure left. Everyone talks, the conversation is pleasant, notes are taken, and nothing important is actually clarified.

The better position sits between them. The architect provides structure while keeping attention on the people who understand the enterprise.

Listening for the Organization Behind the Organization Chart

This is where the so-called soft skills begin to intersect directly with architecture.

Business architects work with formal structures constantly. We model capabilities, organizations, processes, governance, information, strategies, products, policies, value streams, and decision rights. Yet every organization also has an informal architecture operating alongside the formal one, and sometimes the informal architecture is more influential than the structure represented on paper.

You begin to notice it in meetings.

Who does everyone look at before answering a difficult question? Which team supposedly owns a capability but calls another department whenever something unusual happens? Which policy technically governs the work even though nobody has followed it consistently in years? Which executive possesses the formal decision right, and which manager can quietly prevent the decision from being implemented? Where does institutional memory live? Who knows why the workaround exists, who remembers the failed attempt to remove it, and who understands the operational consequences that are not written down anywhere?

An organization chart will rarely answer those questions, and neither will a process diagram.

You usually discover them through conversation, particularly once people become comfortable enough to stop reciting the official description of the enterprise and begin explaining how it actually functions.

This is why I have never been entirely comfortable with treating these abilities as secondary “soft skills.” The phrase can make them sound like interpersonal polish added after the analytical work is complete. In practice, they are part of the mechanism by which reliable analysis becomes possible.

If the architect cannot build enough trust to get beyond the official story, ask sufficiently precise questions, notice contradiction, manage a room, test assumptions without creating unnecessary defensiveness, and recognize where formal structures differ from operational behavior, those weaknesses will eventually appear in the architecture.

A beautifully constructed capability map based on shallow discovery is still a poor representation of the enterprise.

Build a Strange Bookshelf

Business architects should obviously study the formal discipline. We should understand capabilities, value streams, information concepts, strategy, organizational design, operating models, systems thinking, economics, technology, governance, and the industries in which we work.

I would also build a second bookshelf alongside the obvious one.

I would read about cold reading because it sharpens observation and conversational hypothesis testing. I would read about joke construction because it teaches something about expectations, wording, framing, timing, and audience response. I would read about improvisation because meetings do not follow scripts. I would read negotiation because positions and interests are rarely the same thing. I would read rhetoric because architecture eventually has to be explained to another human being.

I would also read history because organizations have histories whether they acknowledge them or not. They inherit processes, technologies, organizational boundaries, incentives, workarounds, terminology, and old compromises. An arrangement that appears irrational in the present may have been a perfectly sensible response to a problem that existed ten years earlier. Understanding why something came to exist is often the first step toward understanding whether it can safely be changed.

More broadly, I think architects benefit from reading outside the profession and asking a simple question: what can this teach me about understanding an organization?

Sometimes the answer will come from a strategy book, sometimes from an organizational theorist, and sometimes from Ian Rowland explaining cold reading or a former head writer for The Daily Show explaining how to construct a joke.

I am comfortable with all of those possibilities.

That philosophy is part of what I am trying to capture with the Business Architecture Cookbook at StephenKlahr.com. Applied business architecture rarely unfolds as a perfect sequence of methodology, modeling, analysis, and implementation. Real enterprises are considerably messier. Stakeholders disagree, information arrives incomplete, decision rights are complicated, tools have limitations, organizational history intrudes on theoretically elegant designs, and implementation has a way of exposing assumptions that looked perfectly reasonable on an architecture diagram.

Practitioners therefore need more than frameworks. We need a collection of techniques, habits, observations, and approaches that help us understand the enterprise as it actually exists and move conversations toward something useful.

Some of those techniques come directly from BIZBOK, TOGAF, strategy, systems thinking, and architecture practice. Others come from places we might not normally associate with architecture at all.

Eventually, though, every capability map, value stream, operating model, initiative decomposition, and strategy discussion comes back to a room full of people trying to understand one another well enough to make a decision.

Somebody has to know how to host the room.

About the Applied Business Architecture Project

The Applied Business Architecture Project at StephenKlahr.com is a free collection of applied business architecture field notes, tools, reference material, study resources, and practical approaches, including the Business Architecture Cookbook. The project is focused on applying business architecture in real organizations, where the work rarely fits as neatly as the diagrams suggest. Everything is available without registration and is intended for practitioners trying to make the discipline useful in practice.