4 exercises — presenting diagrams to mixed audiences, justifying technical decisions, presenting trade-offs honestly, and using connector signposts between architecture layers.
0 / 4 completed
1 / 4
You're presenting an architecture diagram to a mixed audience: 3 engineers, 2 PMs, and 1 VP of Engineering. Which introduction works for all three groups?
Option B uses the user-first, then technical layering technique for mixed audiences:
Starts from the user's perspective: "A browser request hits our API gateway" — everyone understands "a user makes a request" Uses plain language first: "one responsibility", "message bus" — functional, not technical Promises depth for engineers: "for the engineers in the room I'll add the technical details" — acknowledges that two groups are present without splitting the audience
Why A fails: "gRPC", "east-west", "Istio" — the VP and PMs are lost after the first sentence. They smile and stop listening.
Why C fails: "Very complex" signals that you don't think your audience can follow. It's defensive framing.
Why D fails: Asking a VP of Engineering and two PMs if they know what a microservice is is condescending.
Mixed-audience architecture technique: 1. One sentence from the user's perspective 2. Navigate the diagram top-to-bottom (entry → services → storage) 3. Add technical depth at each node for engineers: "for the engineers: this is Kafka, because…" 4. Use the word "responsible for" instead of technical jargon where possible
2 / 4
You chose PostgreSQL over MongoDB for the new reporting service. A stakeholder asks why. Which explanation best justifies the technical decision to a mixed audience?
Option C uses the decision narrative format that technical decisions require:
States the specific technical constraint: "8–12 table joins" — not a generic "relational data" statement Explains the cost of the alternative: "denormalise upfront OR multiple round trips" — shows you actually evaluated MongoDB seriously Frames both technical and human costs: "complexity and maintenance cost" (technical) + "team SQL expertise, reduces onboarding time" (organisational)
Why A fails: "ACID-compliant RDBMS" loses non-engineers. Even correct technical answers must be translated for mixed audiences.
Why B fails: "We've done it before" is a tradition argument, not a decision. It invites someone to challenge you with "but why don't you try something new?"
Why D fails: "We evaluated both and Postgres won" — evaluated on what criteria? This is an empty answer.
Technical decision justification format: "We chose [X] because [specific constraint]. [Alternative] would have required [specific cost]. [X] solves that because [mechanism], and given [team/context factor], it was the better fit."
3 / 4
You need to present a trade-off between two architecture options. Which format communicates it most clearly to stakeholders?
Option C demonstrates the balanced trade-off presentation format that earns the trust of technical and non-technical stakeholders:
Names both options neutrally: No framing bias in the description section — both are described with genuine pros and cons Presents real trade-offs, not strawmen: Microservices weaknesses (operational overhead) are real; Monolith strengths (simpler operation, lower cost) are real Makes a concrete recommendation: "Option B for the first 12 months" — not "it depends"; stakeholders need a decision from you Grounds the recommendation in a measurable trigger: "20k DAU" — an objective metric, not a vague "when we need to scale"
Why A fails: "Microservices is technically better" is a platitude; it's not a decision, it's a preference Why B fails: "Old-fashioned" is not a trade-off analysis; it's a bias signal that undermines your credibility
Trade-off presentation structure: Option A: [What it does well] + [Honest cost/risk] Option B: [What it does well] + [Honest cost/risk] Recommendation: [Which and why] + [What would change your mind / trigger criteria]
4 / 4
You're presenting multiple sections of a technical architecture. Which signposting sentence best transitions between sections?
Option C is a connector signpost — the most valuable type for technical architecture presentations:
Three elements of an excellent signpost: 1. Summary of what you just covered: "That covers the ingestion layer — handles incoming events from all client types" 2. Introduction of what comes next: "Now let's look at the processing layer — transformation logic lives here" 3. The connection between them: "ingestion feeds processing, and the rate of buffering determines latency" — this is what the audience actually needs to know
Why connector signposts matter: Architecture diagrams are networks. Without connecting the concepts, each layer looks isolated. The most important thing your audience needs to understand is HOW the pieces interact, not just that they exist.
Why A and B fail: "Next part" and "moving on" are empty transitions — they just create a pause without building understanding
Why D fails: "Too technical" signals poor audience analysis; if a section is too technical for the room, simplify it — don't skip it and create a gap in their understanding
Signpost formula: "[Previous section] covers [function]. Moving on to [next section], which is responsible for [function]. The key connection is [relationship]."