Here’s a scene from my life last week: a production outage was affecting the client’s checkout flow. The client VP called an emergency meeting. I knew exactly what happened — a race condition in the payment processing queue caused by a recent deployment that changed the message ordering. I could explain this perfectly in Vietnamese in 30 seconds.
In English? I said something like: “The system… there is a problem with… the things go in wrong order… when customer pay at same time… the deployment changed… the message… not come correctly.”
The VP looked more confused after my explanation than before. My junior colleague — who understood the problem less deeply than me — stepped in with a clear, structured explanation that the VP immediately understood.
This is the gap. Not knowledge. Not intelligence. Communication structure.
The PREP Framework
The single most useful communication framework for explaining anything in English:
- Point — state your conclusion first
- Reason — explain why
- Example — give a concrete example
- Point — restate with next steps
Example: Explaining the Outage
Without PREP (how I actually said it):
“So the deployment went out and then the messages, they are going in different order now, and when two customers buy at the same time, the payment processing is not… correctly… and then it causes the error we see.”
With PREP:
“Point: The checkout failures are caused by a deployment we made yesterday that changed how payment messages are processed.
Reason: Our payment system processes transactions in a specific order. The deployment accidentally changed that order, so when two customers check out at the same time, the system gets confused about which payment to process first.
Example: Think of it like a post office that normally sorts letters by arrival time. Our update accidentally switched the sorting to alphabetical. Now letters are being delivered to the wrong mailboxes.
Point: We’ve identified the fix. We’ll roll back the deployment within the hour, and all transactions will process normally.”
See the difference? The second version is clear even if your pronunciation isn’t perfect, because the structure carries the message.
The Power of Analogies
When you’re explaining technical concepts in your second language, analogies are your superpower. Here’s why: analogies let you use simple vocabulary to explain complex ideas.
The Kitchen Analogy Library
I use food and kitchen analogies constantly. Everyone understands cooking:
| Technical Concept | Kitchen Analogy |
|---|---|
| Load balancing | ”Like having 5 cash registers instead of 1 — customers are distributed so no single register is overwhelmed” |
| Caching | ”Like pre-cooking popular dishes before the restaurant opens — instead of making each one from scratch” |
| Microservices | ”Instead of one chef doing everything, we have specialized stations: one for salads, one for grills, one for desserts. They work independently” |
| Race condition | ”Two chefs grabbing the last egg at the same time — both think they have it, but only one actually does” |
| Technical debt | ”Like piling dishes in the sink — fine for a day, a disaster after a week” |
| CI/CD pipeline | ”Like a car assembly line — each station does one thing: welding, painting, testing, before the car reaches the customer” |
| Database index | ”Like the index at the back of a book — instead of reading every page to find a topic, you look it up in 2 seconds” |
| API | ”Like a waiter in a restaurant — you don’t go to the kitchen yourself, you tell the waiter what you want and they bring it back” |
The Highway Analogy Library
Traffic is another universally understood concept:
| Technical Concept | Highway Analogy |
|---|---|
| Bandwidth | ”The number of lanes on a highway — more lanes = more cars can travel at once” |
| Latency | ”The distance between two cities — even on an empty highway, it takes time to drive there” |
| Rate limiting | ”Like a traffic light at a highway on-ramp — it controls how many cars enter per minute” |
| DDoS attack | ”Like a million people all trying to enter a building through one door at the same time” |
| Message queue | ”Like a car wash line — cars wait their turn and are processed one at a time” |
| Scaling horizontally | ”Adding more lanes to the highway versus making cars drive faster” |
Creating Your Own Analogies
Formula: [Technical concept] is like [everyday thing] because [shared principle].
Rules:
- Use analogies your audience already understands (avoid tech-to-tech analogies for non-technical people)
- Acknowledge where the analogy breaks down: “Of course, unlike a real kitchen, our servers…”
- Keep it to one analogy per concept — don’t mix metaphors
- Practice your analogies in advance — don’t improvise them in meetings
Templates for Common Tech Lead Scenarios
Scenario 1: Explaining a Production Issue
Template:
“We’re seeing [symptom]. The root cause is [technical reason in simple terms]. This is affecting [business impact]. We’ve already [immediate action taken] and expect full resolution by [timeline].”
Example:
“We’re seeing slow page loads for about 15% of users. The root cause is that our database server is running low on memory because of an unexpected spike in traffic from the marketing campaign. This is affecting checkout conversion for users in the US East region. We’ve already added more capacity and expect performance to return to normal within 30 minutes.”
Scenario 2: Proposing an Architecture Change
Template:
“I’d like to propose [change] because [current problem]. The benefit is [outcome]. The tradeoff is [cost/risk]. I recommend we [specific action] with a timeline of [duration].”
Example:
“I’d like to propose moving our file storage from our own servers to AWS S3 because we’re spending 20 hours per month managing storage infrastructure. The benefit is we eliminate maintenance completely and get better reliability. The tradeoff is a slightly higher monthly cost — about $200 more per month — but we save 20 engineer hours, which is far more valuable. I recommend we start with a pilot migration of non-critical files over the next two weeks.”
Scenario 3: Saying “No” to a Feature Request
Template:
“I understand why [feature] is important for [business goal]. The challenge is [technical constraint]. If we do this now, [negative consequence]. Instead, I’d suggest [alternative] which achieves [same goal] with [less risk/cost].”
Example:
“I understand why real-time notifications are important for user engagement. The challenge is that our current architecture doesn’t support WebSockets, and adding it would require significant changes to our infrastructure. If we do this now, it could delay the product launch by three weeks. Instead, I’d suggest implementing push notifications as a first step — they provide 80% of the same benefit and we can build them on our existing infrastructure in about three days.”
Scenario 4: Giving a Status Update
Template:
“Here’s where we are on [project]: We’ve completed [done items]. We’re currently working on [in-progress]. The main risk is [risk]. Overall, we’re [on track / slightly behind / ahead of schedule].”
Example:
“Here’s where we are on the checkout redesign: We’ve completed the UI changes and payment integration, which is about 70% of the work. We’re currently working on the shipping calculator, which is the most complex remaining piece. The main risk is the third-party shipping API — their documentation is inconsistent and we may need extra time for testing. Overall, we’re slightly behind schedule — about 2 days — but I believe we can recover by parallelizing the testing work next week.”
Scenario 5: Estimating Timeline
Template:
“[Feature] will take approximately [time]. That breaks down into: [breakdown]. There’s a buffer of [X] for [reason]. The biggest uncertainty is [risk factor].”
Example:
“The user dashboard will take approximately three weeks. That breaks down into: one week for the backend API, one week for the frontend components, and one week for testing and polish. There’s a buffer of two days built in for integration issues. The biggest uncertainty is the analytics component — we need data from the data team and they haven’t confirmed their timeline yet.”
Writing Clear Slack Messages and Emails
Written communication is easier to prepare, but tech leads still struggle with clarity. Here’s a framework:
The 3-Line Rule for Slack
If your Slack message is more than 3 lines, restructure it:
Bad:
Hey, so I was looking at the deployment pipeline and I noticed that the test step is taking about 40 minutes which is way too long because the team has to wait and it blocks the whole workflow and I think we should split the tests into parallel runs but we need to discuss first because it might affect the infrastructure costs and I’m not sure if DevOps is okay with it, what do you think?
Good:
🔍 Issue: Test step in CI pipeline takes 40 min — blocks the team 💡 Proposal: Run tests in parallel (could cut to ~15 min) ⚠️ Consideration: May increase infra costs — need to discuss with DevOps
Worth a quick chat this week?
Email Template for Client Updates
Subject line: [Project Name] — Weekly Update [Date]
Hi [Name],
Quick update on [project]:
✅ Completed this week:
- [Item 1]
- [Item 2]
🔄 In progress:
- [Item 1] — expected by [date]
⚠️ Needs attention:
- [Item] — [brief explanation + what you need from them]
Next steps: [Action items]
Let me know if you have questions.
Best,
[Name]The Explain-It-Simply Test
Before any important communication, test yourself:
- Can you explain it to a 10-year-old? If not, you need a better analogy
- Can you explain it in 3 sentences? If not, your structure needs work
- Does your explanation start with the conclusion? If not, restructure with PREP
- Can someone act on your message? If not, add clear next steps
Practice This Week
- Pick one of the 5 templates and write out an explanation for a real situation at work
- Create 3 analogies for technologies you work with regularly
- Rewrite one Slack message using the 3-Line Rule
- Practice the PREP framework by explaining a technical concept out loud (record yourself)
- Ask ChatGPT: “I need to explain [concept] to a non-technical client. Help me create a good analogy.”
The goal isn’t to sound like a native speaker. The goal is to be understood on the first try. Structure does 80% of that work.
Next up: Part 5 — Presentation & Public Speaking — how to present new technology to a room full of people, even when your accent makes you nervous.