- Duration: 60 minutes
- Prerequisites: Module 01: Advanced Discovery
- Primary Metric: Jargon-Free Test
- Frameworks: 4 (Cognitive Load, Empty Whiteboard, Level-Setting Visuals, Visual Hierarchy)
Open each image at full size or download the editable draw.io source. The Azure services are consistent; the audience model changes.
The mixed-audience steering committee
You walk into a room with the CFO, the CTO, and the VP of Engineering. They each need a different abstraction layer of the same architecture. You either pre-built three diagrams: or you watch one of them disengage in the first ten minutes.
The recovery deal you inherited
Predecessor handed the customer a 47-component diagram. Customer asked for "a simpler version" and the deal stalled. Your first move is not a redesign: it is the Concept-layer diagram that gets the CFO oriented in 60 seconds without your narration.
The discovery session before the design session
The temptation is to bring your reference architecture. The discipline is to bring a marker and an empty whiteboard. What the customer draws first: and what they leave out: is the most valuable signal in the engagement.
Common Misconceptions About This Module
- "More detail equals more credibility." The opposite is true with executives. Detail signals that you have not done the work of subtraction. The diagram that survives a CFO review has fewer elements than the one you started with, not more.
- "My diagram is fine: I just need to walk them through it." A diagram that requires narration to be intelligible is a diagram that fails when forwarded over email. The test is silence: can the diagram do its job without you?
- "Empty Whiteboard wastes time when I already know the answer." You may know an answer; you do not yet know whether it solves the customer's actual mental model of the problem. Skipping discovery to save 20 minutes routinely costs four weeks of rework.
- "One diagram for all audiences is more efficient." A single diagram designed for everyone communicates to no one. Three audience-calibrated variants take 30% more time to build and convert at materially higher rates.
- "Visual hierarchy is decoration." Visual hierarchy is what tells the eye where the decision lives. Without it, every box has equal weight, which means no box has weight, which means the audience has to do the prioritization work you should have done.
Cognitive Load Theory
Every diagram taxes the viewer’s working memory. Architects habitually over-encode: too many boxes, too many arrows, too many acronyms, too many layers of abstraction in a single view. Cognitive Load Theory says the diagram that shows only what the audience needs to make a decision:nothing more:is the most powerful one. The discipline is subtraction: what can you remove without losing the decision-relevant signal?
Working memory holds roughly four chunks of unfamiliar information at a time. A diagram with 25 elements puts the audience past their cognitive ceiling before the conversation begins: they will either ask for "a simpler version" (delay) or nod along while comprehending nothing (worse). Subtraction is the only respectful option.
Apply the audit before any executive-level review. Apply 40% subtraction when a diagram has more than 10 elements. Apply this discipline before you "just walk them through it": that instinct is the warning sign.
Empty Whiteboard Strategy
Start a technical discussion by handing the customer a marker and asking them to draw the problem. You learn how they mentally model the system, what they think is important, and where their gaps and assumptions are:without exposing your own assumptions or losing control of the narrative. The blank whiteboard is the most underused discovery tool in architecture. Every pre-drawn diagram you bring into the room is an opportunity you lost.
What customers draw first reveals what they actually believe is important. What they leave out reveals their blind spots. Both signals are unavailable when you walk in with a finished diagram. The whiteboard inverts the power dynamic for the first 15 minutes: and the customer adopts your eventual recommendation more readily because it was added to their drawing.
The first discovery session of any new engagement. Recovery deals where the previous architect over-presented. Any meeting where the customer's mental model differs materially from yours and you don't yet know how.
Level-Setting Visuals
Different audiences require different abstraction levels. A developer needs the data flow and the API contract. A CTO needs the capability map and the integration surface. A CFO needs the risk-and-cost summary and the business outcome. Level-Setting Visuals are pre-built diagram variants, calibrated to each audience, so you are never caught showing a Layer 3 network diagram to the board. Build all three before the meeting. Use only the right one in the room.
Three audience-calibrated variants take 30% more preparation time and convert at substantially higher rates. The premium is paid by the audience that no longer has to translate. The architect who walks in with the right layer for the room signals respect for the audience's time and earns the right to speak about deeper layers later.
Any executive-level review. Mixed-audience steering committees. Any time you find yourself saying "the same diagram works for everyone": that is the moment to build the variants.
Visual Hierarchy
The most important element in a diagram should be the most visually prominent: larger, brighter, more central, or more isolated. Visual Hierarchy is the discipline of designing diagrams so the eye moves naturally to the decision:the migration boundary, the risk zone, the new capability:not to the implementation detail. If everything in your diagram is the same size and color, nothing is important.
The eye scans before the brain reads. Hierarchy delivers the headline before the audience consciously processes the diagram. Without it, the audience has to do the prioritization work: and they will prioritize incorrectly or give up.
Any diagram intended for an audience above the engineering layer. Whenever the diagram's purpose is to drive a decision rather than document a system. Whenever the answer to "what is the one thing this diagram has to communicate?" is something other than "everything."
A 47-component diagram, a stalled deal, and a CFO who asked for "a simpler version"
Situation
Regional health system, $2.4M Azure landing zone deal, inherited from an architect who left the account. CTO's prior C-suite review ended with a 47-component diagram on screen and the CFO checking her phone. The CFO's actual quote: relayed through the account exec: was "I would like to see a simpler version." Deal stalled four months. Renewal of the existing on-prem support contract was 30 days away.
Move 1: Reset with the empty whiteboard
First meeting back: marker handed to the CTO, blank whiteboard, single question. "Show me how you currently think about where Riverbend's clinical data lives." The CTO drew six storage zones. Notable omissions: no encryption boundary, no DR replication line, no archive tier. Those three omissions became the architect's three discovery questions for the next session: and surfaced two unstated business constraints (a regulatory commitment to immutable audit trails, and a CMO concern about cross-facility data segregation).
Move 2: Build three variants, not one
Concept layer (5 elements) for the CFO: clinical data, audit, security boundary, regional failover, business outcome label. Logical layer (12 elements) for the CTO: same shape plus capability boundaries and integration surface. Deployment layer (38 elements) for the engineering review: full Azure landing zone reference. Each layer was designed to be handed across without translation.
Move 3: Apply Visual Hierarchy to the Concept layer
One element: the clinical data store with the regulatory audit boundary: rendered larger, in the brand accent color, centered. Everything else gray and smaller. The eye moves there first. The element label was business-language: "Patient Record: protected, audited, recoverable across facilities": not "ADLS Gen2 with Purview lineage."
Move 4: Test before the meeting
Architect handed the Concept-layer diagram to a Microsoft account colleague who knew nothing about the Riverbend engagement and asked: "In 60 seconds, what is this diagram trying to get me to approve?" The colleague answered correctly on the first attempt. The diagram passed.
Outcome
Re-do of the C-suite review took 22 minutes. The CFO opened the second meeting by pointing to the central element and saying "this is the one we have to get right, isn't it?": she had read the hierarchy correctly without narration. Deal advanced to commercial terms within 10 days. The architecture had not changed materially. The communication of the architecture had.
The mixed-audience steering committee
Situation
Quarterly steering committee for a $4.8M cloud transformation. Room contains the CFO, the VP of Manufacturing Operations, and the Head of Plant IT: three audiences, three different decision needs. The architect has 30 minutes total.
Move
Three slides built in advance. Slide 1 (Concept, for the CFO): risk reduction, capital posture, business outcome: 4 elements, no acronyms. Slide 2 (Logical, for the VP of Operations): plant connectivity, recovery objectives, dependency map: 9 elements. Slide 3 (Deployment, for Plant IT): full reference architecture: deferred to a follow-up technical session. Architect named the audience for each slide as it appeared.
Outcome
CFO approved the next phase in the meeting. Plant IT requested the deployment session for the following week. The previous quarter's review: a single deployment-layer slide for all three audiences: had ended with a request for "a status update next quarter."
The recovery deal that needed silence, not slides
Situation
Inherited account. Predecessor presented a fully designed solution at the first meeting, which the customer experienced as a sales pitch rather than a discovery. Customer disengaged for six weeks. The replacement architect was given one re-entry meeting.
Move
The architect brought no diagrams to the meeting. Opened with: "I want to spend the first 20 minutes understanding how you think about this problem, not telling you how I think about it." Marker handed over. Customer drew. Architect added two questions. The drawing surfaced an internal political constraint: a peer department's ERP migration: that nobody at Microsoft had named.
Outcome
Customer scheduled a follow-up of their own initiative. The Empty Whiteboard recovered the engagement that the pre-built diagram had broken.
The four-page wonder, undone by subtraction
Situation
Industrial customer reviewing a security architecture proposal. Four-page diagram set, 80+ components total, dozens of acronyms. The board asked for a "single-page summary" before the next review.
Move
Architect applied the 40% subtraction rule three times. First pass cut to 50 elements, second to 30, third to 12. The 12-element diagram named the four security outcomes the board cared about (data protection, identity, threat detection, regulatory posture) and showed which architecture components delivered each. The acronym count went from 26 to 3.
Outcome
The board approved on the single page. The 80-element original was used for the technical review with the security operations team the following week. Same architecture, two artifacts, two audiences, one approval.
Diagram Audit
Apply the Cognitive Load audit framework to a real architecture diagram. Use one of your own or the samples in the module folder.
- Count every distinct visual element: boxes, arrows, icons, text labels, color zones. Write the number down.
- Count every acronym and technology-native term. Write that number down.
- Ask yourself: what is the single most important decision this diagram is supposed to communicate? Write it in one sentence. Now look at the diagram and ask: does the eye go there first?
- Apply the 40% subtraction rule: redraw the diagram (or mark it up) removing 40% of its elements while preserving 100% of the decision-relevant information. Which elements were safe to remove?
- Show the original and your revised version to someone who did not draw it. Which one communicates the decision faster?
Filled-in audit: the Riverbend 47-component diagram
- Element count: 47 boxes/icons, 28 arrows, 11 color-coded zones: total 86 distinct visual elements.
- Acronym count: ADLS, RBAC, AKS, AAD, NSG, AFD, FW, KV, ASR, GRS, LRS, NSP: 12 unique, several undefined.
- Decision the diagram should drive: "Approve consolidation of clinical data on a regulated, audited Azure footprint." Eye does not go there first: it goes to the dense networking subgraph in the upper right.
- 40% subtraction: removed all networking detail (moved to a deployment-layer companion), collapsed six storage icons into one labeled "Patient Record: protected," removed every acronym, kept the audit boundary explicit.
- Result: 12 elements, 0 acronyms, decision element rendered larger and centered.
What was safe to remove: everything that supported "how" but not "what" or "why." The deployment audience sees those details on a different artifact.
Empty Whiteboard Simulation
Practice running a discovery session using the Empty Whiteboard Strategy. The constraint: you cannot show any pre-drawn diagram for the first 15 minutes.
- One person plays the customer (a CTO at a 500-person manufacturer considering a cloud migration). The other plays the architect.
- The architect’s only tool for the first 15 minutes: open-ended questions and a blank whiteboard or paper. Ask the customer to sketch their current state infrastructure.
- While the customer draws, take notes: What did they draw first? What did they leave out? What assumptions are baked into the sketch?
- After 15 minutes, the architect may introduce one prepared diagram. But it must be calibrated to what the customer just revealed:not a generic architecture slide.
- Debrief: what would the architect have assumed wrong if they had led with a pre-drawn diagram?
What the customer drew (Lakebourne Retail recovery)
- Four boxes: store systems, headquarters data center, e-commerce platform, "the cloud thing we're talking about."
- One arrow that did not exist in the architect's mental model: a direct line from store systems to e-commerce platform, bypassing headquarters.
- What was missing: any reference to the peer department's ERP migration, even though it was the binding constraint on timing.
Three architect notes from the session
- The customer treats the e-commerce platform as architecturally peer to the data center, not as a downstream consumer. The reference architecture I would have shown gets this hierarchy wrong.
- The "direct line" arrow is the place to ask the next question: what data flows there today, and who owns the contract for that integration?
- The ERP omission is the discovery surface. Question for follow-up: "How does this initiative relate to the ERP work I've heard mentioned?"
Counterfactual: if I had opened with my reference architecture, the customer would have nodded politely and never told me about the ERP dependency: and the proposal would have missed the actual binding constraint.
Three-Audience Diagram
Build three versions of the same architecture diagram, each calibrated to a different audience using the Level-Setting Visuals framework.
- Choose a cloud migration scenario (use the fictional scenario in the module folder or a real one you are working on).
- Create Version 1 for the development team: show data flows, APIs, and integration points. Maximum 10 elements.
- Create Version 2 for the CTO: show capability boundaries, platform dependencies, and migration sequence. Maximum 7 elements.
- Create Version 3 for the CFO: show risk zones, cost implications, and business outcome. Maximum 5 elements. No acronyms.
- Show each version to a different person without telling them which version they are seeing. Ask: “What decision does this diagram help you make?” Measure time to correct answer.
Three variants: same engagement, three audiences
V1: Developer (10 elements): Patient Record store, ingestion API, transform job, audit log, identity service, regional replica, observability, key vault, dev/prod boundary, deploy pipeline. Time to "what decision" answer: ~25 sec for an engineer ("am I approving the integration shape?").
V2: CTO (7 elements): Clinical data domain, audit boundary, regional recovery, identity perimeter, integration surface, governance plane, transition zone (current vs. target). Time to answer: ~45 sec for a CTO ("am I approving the capability sequence?").
V3: CFO (5 elements): Clinical data (centered, accent color), audit and recovery wrapper, business outcome label ("data protected, recoverable, audited"), one-line current cost vs. one-line target cost, one risk indicator. Zero acronyms. Time to answer: ~50 sec for the CFO equivalent ("am I approving the investment that protects patient data and reduces audit cost?").
Hardest version to make: V3. Compression and label discipline expose every place the architect was hiding behind technical vocabulary.
The Jargon-Free Test for this module is visual: your diagram passes when the CFO can identify the key decision without you narrating it. Rate yourself based on actual diagram reviews, not on what you intend to do differently.
The three errors below recur across cohorts and bias visual-communication ratings upward. Read these before scoring.
- Confusing technical depth with Ready performance. A CSA who answers every technical question correctly but fails to bring the non-technical audience along is not Ready on the Jargon-Free Test. Technical accuracy is necessary but not sufficient.
- Rewarding effort over outcome. A CSA who tries hard to simplify but does not actually land a CFO-level explanation is Developing, not Ready. The metric is observed audience comprehension, not visible CSA effort.
- Confusing "engaged customer" with "consensus." A customer leaning forward and asking questions is engaged, not necessarily aligned. Empty Whiteboard Ready performance requires that the customer's mental model is visibly in the diagram: not that they were a polite audience. Listen for "we" instead of "you" by the end of the session.