Architecture discussions are where technical decisions become organizational decisions. How you communicate your proposal — the words you choose, the order you present trade-offs, how you respond when someone challenges your design — determines whether a good idea gets adopted or buried.
This guide covers the full lifecycle of architectural communication: proposing a solution, running a design review, navigating disagreements, and writing documentation that influences decisions long after the meeting ends.
Part 1 — Proposing a Technical Solution
Whether you’re proposing this in a Slack message, a design doc, or a live architecture review, the structure that works is:
Problem → Options → Recommendation → Evidence → Ask
The 90-Second Verbal Proposal
When you need to pitch an architectural idea quickly — in a standup, a Slack thread, or when someone drops by — use this compact structure:
“Right now we have [specific problem]. I’ve looked at a few approaches: [Option A] would [outcome but tradeoff], [Option B] would [outcome but tradeoff]. My recommendation is [Option B] because [core reason tied to business or technical priority]. I’ve already [spike/prototype/benchmark], and the early results show [evidence]. I’d like 30 minutes on Thursday to walk through it properly — does that work?”
Example — proposing event-driven architecture for a slow reporting pipeline:
“Our reporting pipeline currently runs synchronously on every user action, which is hammering the database at peak load — we saw 4x slowdown during last Friday’s campaign launch. I’ve looked at two approaches: polling with a dedicated reporting DB would isolate the load, but we’d still have data lag of 5-10 minutes. Moving to an event-driven model with Kafka would give us real-time reporting and completely decouple the write path from the read path. I’d recommend the event-driven approach. I spent two days prototyping it, and the throughput numbers look strong. I’d like to do a formal architecture review on Thursday — can we get 45 minutes on the calendar?”
Proposing Without Sounding Prescriptive
One mistake tech leads make: presenting a recommendation as the only option. This invites defensiveness. Instead, use framing that shows you’ve thought about alternatives but have a view.
| Too prescriptive | Better |
|---|---|
| ”We need to use Kafka." | "My recommendation is Kafka — here’s my reasoning, and I’m open to other approaches if there are constraints I’m not seeing." |
| "This design won’t work." | "I see a potential issue with this approach under high load — let me walk through my concern." |
| "We should have done this from the start." | "Going forward, here’s how I’d approach this type of problem.” |
Part 2 — Running an Architecture Review Meeting
A well-run design review produces a decision, not just a discussion. Here’s how to facilitate one.
Opening the Review
“Thanks everyone for joining. Today we’re reviewing [the proposed design for X]. The goal is to leave this meeting with either a green light to proceed, a clear list of concerns to address before we proceed, or a decision to explore an alternative. I’ll walk through the proposal for 15 minutes, then I want to open it up for challenge. Lena, I know you had some concerns about the data model — I’ll make sure we address that specifically. Let’s start.”
What this accomplishes:
- Sets a clear decision goal (not just discussion)
- Signals the presenter is open to challenge
- Acknowledges pre-existing concerns so they don’t fester
Phrases for Facilitating Discussion
| Situation | Phrase |
|---|---|
| Drawing out quiet participants | ”David, you’ve worked closest with the legacy system — what’s your read on the migration risk?” |
| Managing someone dominating | ”That’s an important point — let’s park it and come back to it. I want to make sure we hear from the whole group first.” |
| Forcing a decision | ”We’ve surfaced a few concerns. Are these blockers, or are they things we can address in the implementation phase? Can we get a show of hands?” |
| Handling circular debate | ”We’ve been on this point for a while. Let me try to frame the core tradeoff clearly: [restate it]. Can we agree on that framing and then decide?” |
| Wrapping up | ”Let me read back what I think we’ve agreed on: [summary]. Does that reflect where we landed?” |
The Parking Lot Technique
When a discussion goes off-track into implementation details during an architecture review, use the Parking Lot:
“This is a great point, but it’s getting into implementation specifics. Let me add it to the parking lot — we’ll address it in the detailed design phase. For now, I want to stay at the architecture level.”
Have a visible space (whiteboard, shared doc, Miro) where you write these items. Always review the parking lot before closing the meeting.
Part 3 — Disagreeing Without Damaging Relationships
Technical disagreements are healthy — but the way they’re handled determines whether teams stay cohesive. Here are the patterns that work.
The Acknowledge-Probe-Reframe Pattern
When you disagree with a proposed approach, resist the impulse to state your counter-position first. Instead:
- Acknowledge — show you understand what’s being proposed
- Probe — ask a question that surfaces the assumption you’re challenging
- Reframe — offer an alternative framing, not necessarily an alternative solution
Example — someone proposes rebuilding a system from scratch:
❌ “That’ll take 9 months and we don’t have time.”
✅
“I understand the appeal — a greenfield build gives us the architectural freedom we’ve been missing. Before we commit to that direction, I want to understand what’s driving the ‘rebuild vs. refactor’ decision. What’s the core problem we’d be solving that incremental refactoring couldn’t address? I’m asking because a full rebuild comes with migration risk and a delivery gap, and I want to make sure we’re solving the right problem.”
This invites the other person to either defend their reasoning (which might reveal flaws) or update their position, without them feeling attacked.
Pushing Back on a Senior Leader’s Bad Idea
This is the hardest scenario. You need to protect the team and the codebase without making your manager lose face.
Framework: Agree on the goal → Surface the risk → Offer a path:
“I’m fully aligned on the goal here — getting this feature to market by Q2 is critical, and I want to find a way to make that work. I do want to flag one risk so we can plan around it: [specific technical concern]. If we proceed without addressing it, we’re likely to see [specific consequence] around [timeline]. I’ve thought about a few ways we could manage this. One option is [approach A], which gets us 80% of the feature by the Q2 deadline. Another is [approach B], which takes two more weeks but avoids the technical debt. I’d recommend [option], but I wanted to surface this before we lock in the plan so you have the full picture.”
Key moves:
- Start with alignment on the business goal
- Present the risk with consequences, not just technical concerns
- Always come with options, not just problems
- Use “I wanted to make sure you have the full picture” — it positions you as a helpful advisor, not a blocker
When You’re Overruled
Sometimes you make your case clearly and the decision still goes the other way. How you respond matters.
❌ Staying silent but visibly disengaged. ❌ Saying “OK, but don’t say I didn’t warn you.”
✅
“Understood — I’ll make sure we execute this as well as possible. I’d like to log this in our ADR as a known risk so we have a reference point for the retrospective, and set up a checkpoint in 6 weeks to review how it’s tracking. Does that work?”
This is professional, non-passive-aggressive, and ensures there’s accountability for the outcome.
Part 4 — Challenging Someone Else’s Proposal
When you’re reviewing someone else’s architecture and see a problem, how you frame your concern changes how it’s received.
Question vs. Statement
Framing a concern as a question is almost always more effective than stating it as a fact:
| As a statement (confrontational) | As a question (collaborative) |
|---|---|
| “This won’t handle traffic spikes." | "How does this design handle a 10x traffic spike? I’d like to understand the scaling approach." |
| "You haven’t considered the data migration." | "What’s the plan for migrating existing data? I don’t see it in the proposal." |
| "This is too complex." | "Walk me through how a new engineer would debug an issue in this system at 2am.” |
The question form invites the presenter to fill in details, rather than forcing them to defend themselves.
Separating Concerns from Blockers
In a review, be explicit about the severity of your concern:
- Blocker: “I don’t think we should proceed until we address X. Here’s why…”
- Risk to flag: “I want to note a risk here — it’s not a blocker for the current phase, but we should have a mitigation plan by Q2.”
- Preference: “My instinct would be to approach this differently, but I’m not blocking on it — happy to discuss if you want a second opinion.”
- Question: “I want to understand this decision better — can you walk me through your reasoning on [specific choice]?”
Being explicit about severity prevents reviewers from treating every comment as equal weight.
Part 5 — Writing Architecture Decision Records (ADRs)
An ADR is a short document that records a significant architectural decision: what was decided, why, and what alternatives were considered.
The best ADRs are written in plain, direct English — not jargon-heavy prose. Here’s the structure and language that works.
ADR Template with Real Language
# ADR-042: Use PostgreSQL + pgvector for Vector Storage Instead of Pinecone
**Date:** 2026-03-15
**Status:** Accepted
**Deciders:** [Tech Lead], [Backend Lead], [Platform Architect]
## Context
We need a vector database to support the semantic search feature
for our knowledge base. The original plan assumed Pinecone, which
was evaluated in Q4 2025.
Since then, pgvector has reached production maturity, and we already
run PostgreSQL. Introducing Pinecone would add a new infrastructure
dependency with associated cost (~$700/month at expected scale)
and operational overhead.
## Decision
We will use PostgreSQL with the pgvector extension for vector
storage and similarity search.
## Rationale
- **Lower operational complexity:** No new system to manage, monitor,
or be paged for. Our team already has deep PostgreSQL expertise.
- **Cost:** $0 additional infrastructure cost vs. ~$700/month for
Pinecone at projected scale.
- **ACID guarantees:** Vectors stay transactionally consistent with
our relational data — no sync issues between two systems.
- **Performance:** At our projected scale (< 10M vectors initially),
benchmarks show pgvector within 15% of Pinecone on recall@10.
This gap narrows further with IVFFlat tuning.
## Alternatives Considered
**Pinecone:** Best-in-class ANN performance and managed scaling.
Rejected due to cost, new operational surface area, and lack of
team expertise. Would revisit if we scale beyond 50M vectors.
**Weaviate:** Open-source, strong feature set. Rejected because
it requires a dedicated service with its own operational burden,
without meaningful performance advantage at our current scale.
## Consequences
- We accept slightly lower ANN performance vs. Pinecone at scale.
Mitigation: IVFFlat index tuning, revisit at 50M vectors.
- We need to enable the pgvector extension in production.
Owner: @platform-team, by 2026-03-28.
- Indexing strategy needs documentation before go-live.
Owner: @backend-lead.Language Patterns for ADRs
Describing context (not history):
- “The system currently handles X in way Y. This creates a problem when Z…”
- “We need to decide how to approach X. Two constraints shape this decision: [A] and [B].”
Stating the decision:
- “We will [specific decision].” — always present tense, always specific
- Not: “We have decided to potentially explore using…”
Explaining rationale:
- “The core reason is [single most important factor].”
- “Secondary benefits include [B] and [C].”
- “We accept [known downside] because [mitigation/tradeoff].”
Describing alternatives:
- “[Option A] offers [advantage]. We rejected it because [specific reason].”
- Not: “Option A was also considered but was not chosen.”
Part 6 — Real Phrases for Technical Discussions
During a Design Review
| Goal | Phrase |
|---|---|
| Challenging an assumption | ”That approach assumes [X] — is that a safe assumption given [Y]?” |
| Asking for evidence | ”Do we have data to support that? I want to make sure the decision is grounded in something measurable.” |
| Proposing an alternative | ”Another way to approach this would be [X]. The tradeoff is [Y vs. Z].” |
| Reaching for consensus | ”It sounds like we agree on [X] but are still debating [Y]. Can we lock in [X] and timebox the [Y] discussion?” |
| Summarizing a decision | ”Let me reflect back what I think we decided: [restate]. Does that match everyone’s understanding?” |
In Slack / Async Written Discussion
| Goal | Phrase |
|---|---|
| Raising a concern without blocking | ”One thing worth discussing before we merge: [concern]. Not a hard block — want to make sure we’ve thought through [implication].” |
| Approving with conditions | ”LGTM overall. Two things I’d flag for follow-up: [1], [2]. Happy to proceed if we can track those.” |
| Requesting a design change | ”I’d push back slightly on [decision] — my concern is [specific issue]. Worth discussing before we go further.” |
| Acknowledging you’re wrong | ”Good catch — I was wrong about [X]. Updating my comment above. The correct behavior is [Y].” |
| Escalating a stalled decision | ”We’ve been going back and forth on this for 3 days. I’d like to propose we time-box a 30-minute call to make a decision and move on. Can we find a slot this week?” |
Part 7 — Common Mistakes by Vietnamese Engineers in Design Discussions
Mistake 1: Being Too Indirect When Flagging Problems
What often happens: Softening concerns so much that they don’t register as concerns.
❌ “Maybe there might be a small issue with performance possibly?”
✅ “I’m concerned about performance under load. Based on our benchmarks, this approach will likely degrade at 5,000 concurrent users — which we’ll hit in about 3 months. I’d like to address this before we proceed.”
Being direct about a technical concern is professional, not rude. Stakeholders and peers need to hear the concern clearly to act on it.
Mistake 2: Not Speaking Up Until a Decision Is Already Made
Design reviews are for input, not ratification. If you have a concern, raise it during the review — not in a private message afterwards.
✅ In the meeting: “Before we finalize this — I have a concern I’d like to raise. Is this a good moment?”
Mistake 3: Over-Hedging in Written Proposals
❌ “We could potentially consider possibly implementing a solution that might involve using event sourcing if that seems appropriate.”
✅ “I recommend implementing event sourcing for the order processing pipeline. Here’s my reasoning.”
Confident writing signals confident thinking. You can acknowledge uncertainty specifically (“I’m less certain about the migration timeline — I’d like a spike before committing”) without hedging everything.
Mistake 4: Treating English Precision as Rudeness
Vietnamese technical culture often softens direct statements. In English-language tech environments — especially with international teams — directness is expected and respected.
“This design has a race condition” is not rude. It’s helpful. “I think maybe there could potentially be a slight concern about possibly a concurrency issue” — this buries the problem and signals uncertainty.
Practice Scenarios
Scenario 1: Your team proposes using MongoDB for a new feature. You know the feature requires complex relational queries. How do you raise your concern in the design review without shutting down the engineer who proposed it?
Scenario 2: Your tech lead wants to skip writing ADRs because “we’re moving fast.” How do you make the business case for documentation in a way that resonates with a speed-focused leader?
Scenario 3: An architect from another team reviewed your proposal and left 15 comments, several of which you disagree with. How do you respond in writing — professionally, clearly, and without being dismissive?
Scenario 4: You’re in an architecture review and you realize mid-presentation that your proposed design has a flaw you hadn’t considered. How do you handle it?
The engineers who advance into technical leadership aren’t always the ones with the most technical knowledge — they’re the ones who can communicate that knowledge in a way that moves decisions forward. This guide gives you the language. The practice is yours to do.
Next in this series: Engineering Leadership Communication — how to run one-on-ones that build trust, give feedback that changes behavior, and navigate the conversations nobody teaches you about in a tech career.