Thuan: I like retros in theory. In practice, it’s either: everyone says “everything was fine” and we leave in 10 minutes, or someone drops a bomb and it turns into a blame session.
Alex: Both extremes come from the same problem — people don’t have the language for constructive feedback. In English, there’s an art to saying “this didn’t work” without it sounding like “this is your fault.” Let’s learn that art.
The Retro Structure
Alex: Most retros follow one of these formats:
| Format | Columns | Best for |
|---|---|---|
| Start-Stop-Continue | Start doing / Stop doing / Continue doing | Action-oriented teams |
| What Went Well / What Didn’t / Action Items | Positives / Issues / Fixes | General purpose |
| 4Ls | Liked / Learned / Lacked / Longed for | Newer teams |
| Sailboat | Wind (helps) / Anchor (hinders) / Rocks (risks) | Visual thinkers |
Running the Retro as Tech Lead
| Phase | Phrases |
|---|---|
| Opening | ”Alright, let’s start our retro. Reminder: this is a safe space. We focus on processes, not people.” |
| Setting the timer | ”Let’s take 5 minutes to write your items silently. Don’t overthink it. One sticky note per idea.” |
| Grouping | ”I see a few themes here. Let’s group them: deployment, communication, and testing.” |
| Time check | ”We have 15 minutes left. Let’s focus on the top two items.” |
| Closing | ”Okay, we have three action items. [Name] owns [X], [Name] owns [Y]. I’ll follow up next retro.” |
Giving Feedback Without Blame
Thuan: This is where I struggle. How do I say “the deployment was a mess” without pointing fingers?
Alex: The secret is blameless language. Focus on the process, not the person.
Blameless Phrasing
| Blaming (Don’t) | Blameless (Do) |
|---|---|
| “The deployment failed because QA didn’t test it" | "The deployment had issues. Our testing process didn’t catch the regression." |
| "You broke the build" | "The build broke after the merge. How can we prevent that?" |
| "Nobody reviewed my PR" | "PR reviews took 3 days this sprint. Can we set a 24-hour target?" |
| "The PM keeps changing requirements" | "We had scope changes mid-sprint. How can we handle that better?" |
| "You didn’t finish your stories" | "We had carryover this sprint. What blocked completion?” |
Template: Replace “you” with “we” or “the process”:
❌ “You missed the deadline.” ✅ “We missed the deadline. What can we improve?”
Thuan: So it’s about using “we” and talking about processes?
Alex: Exactly. And asking “how can we improve?” turns a complaint into a collaboration.
Phrases for Common Retro Scenarios
Positive Feedback
| Situation | Phrase |
|---|---|
| Good teamwork | ”The collaboration between frontend and backend was great this sprint.” |
| Quick resolution | ”We resolved the production issue in 30 minutes. That’s a great response time.” |
| Process improvement | ”The new code review checklist really helped — we caught two bugs before staging.” |
| Individual shoutout | ”I want to call out [Name] — the migration script they wrote saved us a lot of time.” |
Raising Issues
| Situation | Phrase |
|---|---|
| Communication gap | ”I think we could improve communication between dev and QA. Some bugs were found late.” |
| Process problem | ”Our deployment process has become a bottleneck. Each deploy takes 2 hours.” |
| Workload | ”The team felt stretched this sprint. We took on more than our velocity suggested.” |
| Knowledge silos | ”Only one person knows the payment module. That’s a risk — can we cross-train?” |
| Tool issue | ”Our staging environment was down for 2 days. That cost us time.” |
Suggesting Improvements
| Suggestion | Phrase |
|---|---|
| New process | ”What if we added a 10-minute handoff meeting between dev and QA?” |
| Automation | ”Can we automate the deployment? Manual steps are error-prone.” |
| Better estimates | ”I’d suggest we break stories smaller. Our 8-pointers always carry over.” |
| Knowledge sharing | ”Can we do a 30-minute knowledge-sharing session every two weeks?” |
| Reducing meetings | ”We spend 6 hours a week in meetings. Can we cut the status meeting since we have standups?” |
Talking About Team Productivity
Thuan: My manager asks me to “improve team productivity.” How do I discuss that in English?
Alex: Productivity discussions need data. Here’s how to frame them:
Presenting Metrics
- “Our velocity this sprint was 26 points — down from 30 last sprint. The main factor was context-switching.”
- “We spent 30% of the sprint on unplanned work. That’s too high — ideally it should be under 15%.”
- “Bug fix ratio went from 20% to 35%. We’re spending more time fixing than building.”
- “Lead time for a feature — from story to production — is averaging 12 days. Our target is 7.”
Proposing Solutions
| Problem | Proposed Improvement |
|---|---|
| Too many meetings | ”Let’s try ‘no-meeting Wednesdays’ for heads-down work.” |
| Context switching | ”Can we batch interrupts? One person on support rotation per sprint.” |
| Slow reviews | ”Let’s set a 24-hour SLA for PR reviews.” |
| Knowledge silos | ”Pair programming on critical modules — one hour per week.” |
| Low morale | ”The team needs a win. Let’s scope the next sprint for 90% confidence.” |
| Technical debt | ”We should allocate 20% of each sprint to tech debt. It’s slowing us down.” |
Thuan: “The team needs a win” — that’s a powerful phrase.
Alex: It is. It shows leadership awareness. You’re not just tracking points — you’re tracking morale.
Handling Difficult Retro Moments
When Someone Gets Defensive
Dev: “That’s not fair — I finished my stories on time!”
You: “I hear you. We’re not assigning blame here. Let’s focus on what the team can do differently next time.”
When Nobody Speaks
You: “I see a lot of empty columns. Let me start — one thing I think we could improve is [X]. What do you all think?”
When It Turns Into a Complaint Session
You: “We’ve identified the issues — lots of good points. Now let’s switch to solutions. For each issue, what’s one thing we can try next sprint?”
When Someone Blames Another Person
You: “Let’s keep it process-focused. Instead of who, let’s ask: what in our process allowed this to happen?”
Action Items That Actually Happen
Thuan: Our retro action items always die by the next sprint.
Alex: Because they’re too vague. Fix that with the SMART action item format:
| Vague Action Item | SMART Version |
|---|---|
| ”Improve communication" | "[Name] will add a 10-min handoff slot to the QA calendar by Monday" |
| "Better testing" | "[Name] will create a regression test for the checkout flow — due next Thursday" |
| "Reduce tech debt" | "We’ll allocate 5 points per sprint to tech debt, starting next sprint" |
| "More documentation" | "[Name] will document the deployment process on Confluence by EOW” |
Rule: Every action item needs an owner and a deadline.
10-Minute Self-Practice
The Feedback Rewrite (5 min)
- Think of something that bothered you last sprint
- Write it as a blame statement: “X didn’t do Y”
- Rewrite it as a blameless observation: “Our process for Y could be improved”
- Write a suggestion: “What if we tried Z?”
- Say all three versions aloud — feel the difference
The Retro Prep (5 min before each retro)
- Write one positive thing from the sprint
- Write one improvement suggestion
- For the suggestion, prepare a SMART action item
- Practice saying all three in under 60 seconds
Thuan: I like that the practice is always tied to real work.
Alex: That’s the whole point. You’re not studying English — you’re becoming a better tech lead. The English is the vehicle, not the destination.
What’s Next
Retros mastered. Next post: Dev vs BA — Requirement Debates — the real-world conversations where your English directly impacts what your team builds.
This is Part 6 of the English Upgrade series — practical Business English for busy tech leads. Related: Tech Coffee Break #12: Career Growth — why communication is the biggest lever in the senior-to-lead transition.