Thuan: My CTO asked me to “give a quick update to the board.” I started with “We migrated from REST to GraphQL and reduced N+1 queries by 40%.” The room went silent. Someone asked, “Is that good?”
Alex: You were speaking engineer to business people. That’s like a doctor telling a patient “We performed laparoscopic cholecystectomy” instead of “We removed your gallbladder.”
Thuan: So how do I translate “we reduced N+1 queries by 40%” into something a CEO cares about?
Alex: “The app loads 40% faster.” Same information. Different language.
The Translation Framework
Alex: Every technical achievement maps to a business outcome. Here’s the framework:
Technical Fact → So What? → Business Impact
| Technical | So What? | Business Impact |
|---|---|---|
| ”Reduced N+1 queries by 40%" | "Pages load faster" | "Users see results in 1 second instead of 3" |
| "Migrated to microservices" | "Teams can deploy independently" | "We can ship features twice as fast" |
| "Added Redis caching" | "Reduced database load" | "We can handle 5x more users without new infrastructure" |
| "Implemented CI/CD pipeline" | "Automated testing and deployment" | "Fewer bugs reach production. Deployments take minutes, not days" |
| "Upgraded to PostgreSQL 16" | "Better performance and security" | "We’re compliant with security requirements and 20% faster” |
Template: “We [technical change]. This means [business impact].”
Thuan: So I never talk about the technology — I talk about the result?
Alex: Talk about the result first. Then offer technical depth if they ask. Most stakeholders won’t ask.
Phrases for Stakeholder Updates
Project Status
| Situation | Phrase |
|---|---|
| On track | ”We’re on track to deliver by [date]. No major risks.” |
| Slight delay | ”We’re 1 week behind schedule on [feature]. Root cause: [reason]. Recovery plan: [action]. New ETA: [date].” |
| Major delay | ”I want to flag a risk. [Feature] may slip by [time]. Here are our options: [A, B, C]. I recommend [B] because [reason].” |
| Ahead of schedule | ”We’re ahead of schedule on [X]. We’re using the extra time to improve [quality/performance].” |
Explaining Technical Decisions
| Technical Decision | Business Language |
|---|---|
| ”We chose PostgreSQL over MongoDB" | "We chose a database that’s proven, reliable, and fits our data structure perfectly." |
| "We’re using Kubernetes" | "We’re using a system that automatically scales our app up during peak hours and back down at night — saving infrastructure costs." |
| "We need to refactor the auth module" | "The login system needs modernizing. It’s currently a security risk and slows down feature development. Fixing it now prevents bigger problems later." |
| "We need to pay down tech debt" | "Some of our foundational code needs cleanup. It’s like maintaining a building — skip maintenance too long and renovations become 10x more expensive.” |
Handling Hard Questions
| Question | Response |
|---|---|
| ”Why is this taking so long?" | "Three factors: [X], [Y], [Z]. [X] was unexpected. We’ve adjusted the plan — here’s the new timeline." |
| "Can we just do it faster?" | "We can accelerate if we reduce scope. Which features are essential for launch?" |
| "Why do we need this technology change?" | "Our current system handles [X] users. We expect [3X] by next year. This change prepares us for that growth." |
| "What happens if we don’t do this?" | "Short-term: nothing changes. Long-term: [specific risk]. We’re recommending proactive investment now to avoid [consequence] later." |
| "Is our data safe?" | "Yes. We follow [standard] security practices. Our data is encrypted, access is controlled, and we do regular security audits.” |
The Executive Summary Format
Thuan: How do I structure a written update for executives?
Alex: The inverted pyramid — most important information first:
Executive Update Template
Subject: [Project Name] Status — [Month/Week]
**Bottom Line:** [One sentence: where we are and what
they need to know]
**Progress:**
- ✅ [Completed items]
- 🔄 [In progress items]
- ❌ [Blocked/at-risk items]
**Key Decision Needed:** [If any — specific question]
**Risks:**
- [Risk 1]: [Impact] → [Mitigation]
**Next Steps:**
- [What happens next]
**Timeline:** [On track / revised timeline]Example
Subject: Payment Module Status — Week of March 10
**Bottom Line:** Payment processing is on track for
March 20 launch. One risk: Stripe API integration
needs attention.
**Progress:**
- ✅ Credit card processing (complete, in QA)
- ✅ Invoice generation (complete, deployed)
- 🔄 Stripe integration (70% complete)
- ❌ PayPal support (deferred to Phase 2)
**Key Decision Needed:** Should we launch with Stripe
only, or wait 2 weeks for PayPal? 90% of users use
credit cards.
**Risks:**
- Stripe API rate limits may affect high-volume periods.
→ We've implemented request queuing as a safeguard.
**Next Steps:**
- Complete Stripe integration by March 15
- Full QA round March 16-18
- Production deployment March 20
**Timeline:** On track ✅Thuan: “Bottom Line” first. That’s the opposite of how I usually write — I build up to the conclusion.
Alex: Asian communication often follows an inductive pattern: background → analysis → conclusion. Western business communication is deductive: conclusion first, then supporting details. When writing to executives, always lead with the bottom line.
Demo Presentations for Non-Technical Audiences
Thuan: What about when I need to demo to stakeholders who aren’t technical?
Alex: The key: narrate the user experience, not the technology.
Technical Demo (for developers)
“This endpoint accepts a JSON payload with userId and preferences, validates against the schema, persists to PostgreSQL with an upsert operation, and returns a 200 with the updated entity.”
Business Demo (for stakeholders)
“Here’s what happens when a user updates their notification preferences. They toggle the switch, click save, and it’s instant — see, the confirmation appears in under a second. This works across all devices.”
Demo Narration Phrases
| Moment | Phrase |
|---|---|
| Setting the scene | ”Let me show you what the user experience looks like.” |
| Highlighting value | ”Notice how fast this loads — that’s the improvement we made this sprint.” |
| Simplifying tech | ”Under the hood, we’ve automated this process. Users don’t need to do anything.” |
| Showing before/after | ”Before this change, users had to [manual steps]. Now it’s one click.” |
| Ending | ”That’s the feature in action. Questions?“ |
10-Minute Self-Practice
The Translation Game (5 min)
- Write down 3 technical achievements from your current project
- For each, complete: “We [technical change]. This means [business impact].”
- Say each one aloud — aim for under 15 seconds per item
The Executive Summary (5 min)
- Write a 5-line status update for your current project using the template
- Start with “Bottom Line:”
- Time yourself — it should take under 5 minutes to write
What’s Next
You can now translate tech to business fluently. Next post: Client Meetings — Rehearsal to Delivery — the full lifecycle of client-facing communication.
This is Part 11 of the English Upgrade series. Pairs with English for Tech Leads Part 5: Presentations for broader speaking skills.
Related: Tech Coffee Break #3: System Design at Scale — the technical depth behind those simple stakeholder explanations.