How to Ask Better Questions

Part 6 · Navigating the Territory

The fastest way to contribute to an architecture conversation, regardless of your title, is not to have the answer. It is to ask the right question. A good question does work that a statement cannot: it surfaces what is hidden without requiring you to be the expert, it shifts the conversation without claiming authority, and it lets the room arrive at an insight rather than receive it. This chapter is about the questions that demonstrate EA-level thinking — the ones a junior person can ask that change the direction of a senior conversation.

The questions in this chapter are not clever or adversarial. They are the plain, structural questions that architectural thinking naturally produces, and their power is precisely that anyone can ask them.

Why Questions Beat Statements

A statement asserts; it puts your credibility on the line and invites agreement or rebuttal. A question opens; it puts a consideration into the room without requiring you to defend it, and it lets the people with the authority and the information do the work of answering. For someone without the title, this asymmetry is everything.

A junior person who states “this is a point-to-point integration problem” is making a claim they may have to defend against more senior people, and the social cost of being wrong is high. The same person who asks “are we creating another direct connection here — and what happens when it breaks?” has put the identical consideration into the room at almost no risk, and has invited the experts to confirm or correct it. If the concern is real, it surfaces; if it is not, the asker has lost nothing. The question is the low-risk, high-value move, and it is available to everyone.

Good questions also do something statements cannot: they let the room own the insight. People defend conclusions they reached themselves and resist conclusions pushed at them. A question that leads the room to see the unowned decision or the hidden dependency lets them arrive at it, which makes them far more likely to act on it. The architect’s influence, as Chapter 32 argued, often comes not from being right out loud but from asking the question that lets others be right.

The Questions That Show Architectural Thinking

A handful of questions, asked at the right moment, reliably demonstrate architectural thinking and reliably improve decisions. They map directly onto the concepts of this book.

“What problem are we actually solving?” The vision question (Chapter 22). Asked when a conversation has jumped to solutions, it surfaces whether the problem has been agreed. It is disarming because it sounds naive and is in fact the most senior question in the room.

“What does this depend on, and what depends on it?” The dependency question (Chapters 24, 35). It surfaces the hidden connections that wreck plans. Asked of any proposed change, it routinely reveals the dependency nobody mapped.

“Who owns this decision?” The governance question (Chapters 28, 37). Asked of any decision point that seems to be floating, it surfaces the ownership void that is the classic process pathology. It is the question the Meridian business analyst asked of the referral process, to great effect.

“Do we already have something that does this?” The portfolio question (Chapter 27). Asked before any procurement, it prevents duplication. It sounds like common sense because it is — common sense that organisations routinely skip.

“What happens when this fails?” The failure question (Chapter 36). Asked of any integration or interaction, it surfaces the failure modes that happy-path thinking ignores. In a clinical context it is often a safety question wearing a technical one’s clothes.

“What does this cost us if we don’t do it?” The cost-of-inaction question (Chapters 26, 44). Asked of any deferred decision, it surfaces decision latency and reframes inaction as a choice with a price.

“Are we treating this the way its maturity warrants?” The evolution question (Chapter 40). Asked of any build-versus-buy decision, it surfaces whether the organisation is building what it should buy or bespoke-managing what it should consume as a utility.

None of these requires expertise to ask. All of them require architectural thinking to recognise when to ask. That recognition is what this book has been building.

Timing and Tone

A good question asked at the wrong moment or in the wrong tone fails. Two disciplines make the difference.

Timing. The dependency question lands when a change is being proposed, not after it has been agreed. The vision question lands when the conversation has rushed to solutions, not after the solution is being implemented. The right question at the right moment opens the conversation; the same question after the decision is made sounds like second-guessing and closes it. Reading the conversation (Chapter 47) is what tells you when the moment is open.

Tone. The questions are genuinely powerful, which means they can easily sound like traps or challenges, especially from a junior person to a senior one. “Who owns this decision?” can be a contribution or an accusation depending entirely on tone. The discipline is to ask from genuine curiosity rather than gotcha — to want the answer rather than to expose the gap. A question asked to help the room think is welcomed; the identical question asked to demonstrate the asker’s cleverness or to corner someone is resented and ignored, however valid. The intent is audible, and it determines whether the question contributes or costs.

Meridian: The Junior Question That Changed Direction

Meridian’s EPR consolidation conversation, early on, is heading toward a decision that would have been a mistake — consolidating to the larger of the two EPRs simply because it was larger, without addressing patient identity first. The room is senior, the momentum is toward “pick the big one and migrate,” and the EA, newly in post, has not yet established the standing to simply override it.

A junior member of the team — a data analyst, not an architect, in the room mostly to take notes — asks a question. Not a clever one. She asks: “When we merge the records, how will we know which patient is which if the two systems identify people differently?”

It is the dependency question and the failure question fused into one plain sentence, asked from genuine puzzlement rather than challenge. And it stops the room. Because nobody has a good answer. The two EPRs do identify patients differently, there is no master, and the merge she is asking about would, without an identity foundation, produce exactly the silent record-mismatching that is a patient-safety catastrophe. Her question surfaces, in fifteen words, the dependency that reorders the entire programme: identity must be resolved before consolidation, which becomes Wave 3 of the roadmap.

The EA’s later reflection is the chapter’s point exactly. The analyst had no authority, no architecture title, and no framework vocabulary. She had architectural thinking — she saw the dependency and the failure mode — and she expressed it as a question rather than a claim, at the right moment, from real curiosity. The question did what the EA’s seniority could not yet do: it let the room discover the problem for itself, which meant the room owned the conclusion. The most consequential architectural contribution in the early EPR conversation came from the most junior person present, through a single well-timed question. That is not a heart-warming anecdote; it is the operating model this book is recommending.

Translator Panel

A junior person worries: “I can’t say anything — I’m not the expert and I don’t know all the terms.” > What that means: They are assuming contribution requires expertise and authority. It does not. A well-timed question, asked from genuine curiosity, puts a consideration into the room at no risk and lets the experts do the answering. The question requires architectural thinking to know when to ask, not expertise to defend.

A skilled contributor asks: “How will we know which patient is which if the systems identify them differently?” > What that means: A plain question that fuses the dependency and failure questions, surfacing a programme-altering issue without any claim to authority. Its power is that it lets the room discover the problem itself — and people act on what they discover far more readily than on what they are told.

The Key Idea

The fastest way to contribute to an architecture conversation without the title is to ask the right question, because a question does what a statement cannot: it surfaces what is hidden at almost no risk to the asker, it shifts the conversation without claiming authority, and it lets the room own the insight rather than resist being told. A handful of plain, structural questions reliably demonstrate architectural thinking and improve decisions — what problem are we solving, what does this depend on, who owns this decision, do we already have one, what happens when it fails, what does inaction cost, are we treating this as its maturity warrants — and none requires expertise to ask, only architectural thinking to know when. Timing and tone are decisive: the right question at an open moment, asked from genuine curiosity rather than gotcha, contributes; the same question mistimed or weaponised costs. The most consequential contribution in a senior conversation can come from the most junior person present, through a single well-timed question.

Next: Chapter 49 completes the arc — how to make your architectural contribution visible and valued before you have the title or the authority.