Speaking Practice: Presenting Technical Decisions Out Loud
Session type: Shadowing + pronunciation drills Focus: Explaining technical decisions clearly and confidently in English Time needed: 12–15 minutes
🎯 Why This Session
You make technical decisions constantly — which library, which architecture, which trade-off. But when you have to explain them in English (in a meeting, a code review, or a design doc review), there’s often a gap between the decision you made and how clearly you can communicate it.
This session trains the words and patterns you need to explain decisions out loud.
🗣️ Key Phrases — Say Each 3 Times
These are the phrases engineers use when explaining technical decisions. Read each one aloud. Then say it again without reading.
| Phrase | IPA | Use case |
|---|---|---|
| ”We went with X because…” | /wiː went wɪð ˈbiːkɒz/ | Core decision statement |
| ”The trade-off we made was…” | /ðə ˈtreɪdɒf wiː meɪd wɒz/ | Acknowledging a compromise |
| ”We considered Y but rejected it because…” | /wiː kənˈsɪdəd… bʌt rɪˈdʒektɪd/ | Showing your decision process |
| ”In the short term this costs us X, but long term it saves us Y.” | — | Temporal trade-off framing |
| ”This is reversible / This is a one-way door.” | /ˈrɪvɜːsɪbl/ | Framing decision risk |
| ”I’d like to hear any concerns before we commit to this.” | — | Opening for pushback |
| ”The main risk here is X — and our mitigation is Y.” | — | Risk framing |
📋 Shadowing Scripts — Read Aloud
Shadowing means: read the script out loud at natural pace, trying to match the rhythm and intonation of a native English speaker.
Script 1: Choosing a Database
“So we evaluated three options: PostgreSQL, DynamoDB, and PlanetScale. We went with PostgreSQL because our query patterns are relational — we have complex joins across five tables, and a document store would have made that significantly harder to maintain.
The trade-off we made is that PostgreSQL needs more ops work to scale horizontally. But given our current traffic, that’s not a concern for the next 12 months. And when it becomes a concern, we’ll have a much clearer picture of our actual usage patterns.”
Read this twice. Second time: no pauses, normal pace. Focus on the rhythm of “we went with X because… the trade-off we made is…”
Script 2: Proposing a Refactor
“I want to walk through why I think we should split the monolith here — specifically the auth and billing modules.
Right now, these two modules are tightly coupled: a change to billing validation triggers a full auth re-deploy. That’s added 2–3 hours to every billing release cycle this quarter.
We considered just cleaning up the internal interfaces, but the coupling runs deep. The cleaner fix is a proper service boundary.
The main risk is the migration period — about 3 weeks where we run both versions in parallel. We have a mitigation plan for that. I’d like to hear any concerns before we commit.”
Read once normally. Then read it again, pausing 1 second after each period. Silence after a statement = confidence.
Script 3: Declining a Tool Choice
“I want to be transparent about why I’m pushing back on GraphQL here.
We considered it — it’s a great fit for teams with multiple frontend consumers. But right now we have one mobile client and one web client, and our API surface is stable.
GraphQL would add significant schema management overhead for a problem we don’t currently have. My recommendation is to stick with REST and revisit in 12 months when we have a clearer picture of our client diversity.”
This one is harder — it’s pushback. Read it three times. Notice the softening language: “I want to be transparent about why I’m pushing back” (not: “GraphQL is wrong”). “My recommendation is…” (not: “We should”). This language shows confidence without aggression.
🔤 Pronunciation Focus: Decision Vocabulary
Practice these words carefully:
| Word | Common mistake | Correct IPA | Drill |
|---|---|---|---|
| architecture | ar-chi-TEK-cher (4 syl, wrong stress) | /ˈɑːkɪtektʃər/ (AR-ki-tek-chuh) | “the architecture decision” × 3 |
| reversible | re-VER-si-ble | /rɪˈvɜːsɪbl/ (ri-VUR-si-bl) | “this is reversible” × 3 |
| trade-off | tray-DOF | /ˈtreɪdɒf/ (TRAYD-off) | “the trade-off is” × 3 |
| mitigation | miti-GAY-shun | /ˌmɪtɪˈɡeɪʃən/ (mi-ti-GAY-shun) | “our mitigation plan” × 3 |
| constraint | CON-straint | /kənˈstreɪnt/ (kun-STRAINT) | “given the constraint” × 3 |
⏱️ 5-Minute Decision Drill
Timer: 5 minutes. Speak the entire time.
Minute 1: Say all 7 Key Phrases twice each. Speak as if to someone on a Zoom call — project.
Minute 2: Read Shadowing Script 1 (database choice) twice. Second read: no pausing, natural pace.
Minute 3: Say this out loud without reading — improvise around YOUR last real technical decision:
“We went with [X] because [reason]. The trade-off we made was [Y]. The main risk is [Z] and our mitigation is [A].”
Minute 4: Read Shadowing Script 3 (pushback). Read it once normally. Then read it again with 1-second pauses after each period.
Minute 5: Pronunciation drill — say each of the 5 words from the table above 3 times. Slow is fine; accuracy matters more than speed.
🧠 Handling “Why didn’t you do X instead?”
This is the hardest question after a technical decision. Here’s the structure:
- Acknowledge the alternative: “That’s a valid option — we considered it.”
- Name the constraint that ruled it out: “Given [constraint], it wouldn’t have solved [problem].”
- Confirm your choice: “That’s why we went with [Y].”
Practice out loud:
“That’s a valid option — we considered Kafka. Given our team’s ops capacity, running a Kafka cluster would have introduced more operational risk than it solved. We have one SRE. That’s why we went with a simpler queue. If we scale to the point where Kafka makes sense, we can revisit.”
🎯 The Reversible/Irreversible Frame
One phrase that instantly makes your decision-making sound senior:
“This is a reversible decision — we can change it in 3 months with a 1-week effort.”
vs.
“This is a one-way door — once we migrate, rolling back would take 6 weeks. So I want to make sure we’re confident before we commit.”
Practice both sentences. “One-way door” is an Amazon-originated phrase that has spread widely in tech. Using it signals you think about decision reversibility — a senior engineer trait.
🌟 This Weekend’s Challenge
Find one technical decision you made this week (or are about to make). Write it as a 4-sentence spoken explanation:
- “We went with [X] because…”
- “The trade-off we made was…”
- “We considered [Y] but rejected it because…”
- “The main risk is [Z] — and our mitigation is…”
Say it out loud 3 times. Then record it. Listen back — did you sound like you owned the decision?
The engineers who get promoted aren’t always the best coders. They’re the ones who can explain their decisions clearly, acknowledge trade-offs confidently, and invite challenge without getting defensive.