Technical leadership is mostly a communication job. You spend maybe 20% of your time writing code, and 80% of your time in conversations that determine whether the right things get built by the right people in the right way.
This guide covers the conversations that decide careers: one-on-ones, performance feedback, the promotion conversation, scope negotiations, and the ones nobody prepares you for — when someone quits, when you need to fire someone, when you have to say no to your manager.
Part 1 — Running One-on-Ones That Build Trust
A one-on-one is not a status meeting. Used well, it’s the primary tool for retaining, developing, and understanding your team. Used poorly — or skipped — it’s the fastest way to lose people.
The Opening That Unlocks Real Conversations
Most engineers open one-on-ones with “So, how’s the project going?” That gets project updates, not actual information.
Try these openers instead:
| Goal | Opening |
|---|---|
| Understanding real blockers | ”What’s the most frustrating thing about work right now?” |
| Finding hidden problems | ”Is there anything that we’re doing as a team that doesn’t make sense to you?” |
| Checking wellbeing | ”How are you doing — genuinely? Work-life balance, energy levels, all of that?” |
| Career development | ”What do you want to be working on 6 months from now that you’re not doing today?” |
| Building psychological safety | ”Is there anything you wish you could say but feel like you can’t?” |
Don’t use all of these in one session. Rotate them. The goal is consistent signal over time, not an interrogation.
Listening Actively
When someone is sharing something important, resist the impulse to immediately problem-solve. First, make them feel heard:
“That sounds really frustrating. Tell me more about what happened.”
“I appreciate you sharing that — it takes trust to bring this up. Walk me through how you’ve been experiencing it.”
“I hear you. Before I respond, I want to make sure I understand the full picture.”
Phrases that show you’re actually listening:
- “So what I’m hearing is [restate]. Is that right?”
- “What’s the part of this that bothers you most?”
- “If this got resolved, what would that look like for you?”
Phrases for Common One-on-One Scenarios
When someone says they’re “fine” but clearly aren’t:
“You say it’s fine, but I’m sensing some frustration underneath that. I’m not going to push, but I want you to know this is a safe space to be direct with me.”
When someone brings a complaint about a teammate:
“I hear the frustration. Before we figure out next steps, can you help me understand your perspective on why they might be acting this way? I want to make sure I have the full picture.”
When someone is clearly burned out:
“I want to be direct with you: I’m concerned about your energy levels. What we’re asking of you right now — is it sustainable? Let’s talk about what needs to change.”
When someone says they’re thinking about leaving:
“I really appreciate you telling me that — it takes courage. Can you help me understand what’s driving it? I’m not going to try to talk you out of anything, but I want to understand if there’s something we should be addressing.”
Part 2 — Giving Feedback That Actually Changes Behavior
Most feedback fails because it’s too vague, too late, or delivered in a way that triggers defensiveness instead of reflection. Here’s a framework that works.
The SBI Model (Situation — Behavior — Impact)
Situation: The specific context when the behavior occurred Behavior: What you observed (not what you interpreted or assumed) Impact: The concrete effect it had — on the team, product, or business
Example — giving feedback about communication style:
❌ “You need to communicate better with the team.”
✅ “In yesterday’s design review [Situation], you interrupted three people while they were making their points, and after the second interruption, Sarah stopped speaking up for the rest of the meeting [Behavior]. The impact is that we may have missed her input on a critical decision, and it might make people hesitant to speak up in future sessions [Impact].”
Delivering Positive Feedback
Positive feedback is often undersold. Vague praise (“great job on the project”) has little impact. Specific praise builds the behavior you want to see more of.
Example:
“I want to call out specifically what you did in the client escalation on Tuesday. When the client was clearly frustrated and started blaming the team, you stayed completely calm, acknowledged their frustration directly, and redirected the conversation to what we could control. That de-escalated the situation and probably saved the relationship. That’s not easy to do under pressure — I noticed it, and I want you to know that’s exactly the kind of leadership we need on this account.”
Phrases for specific positive feedback:
- “What you did there was [specific behavior], and the effect was [specific outcome]. That’s worth recognizing.”
- “I want to highlight something you did that I don’t think you realize was exceptional…”
- “The reason this mattered is [business/team impact].”
Delivering Constructive Feedback
Phrase pattern: Direct observation → impact → exploration → path forward:
“I want to share some feedback — it’s direct, and I mean it constructively. [Specific observation of behavior]. The impact of that on [team/product/stakeholder] is [specific consequence]. I’m curious about your experience of that situation — what was happening from your side? [Listen.] Here’s what I’d like to see going forward: [specific change]. Does that feel clear? Is there anything on my side I can do to make that easier?”
Key principles:
- Never deliver critical feedback in a group setting
- Always check that the person understood what you’re asking them to change
- Ask what you can do to support the change — it signals this isn’t purely punitive
- Follow up in the next one-on-one: “Last time we talked about X — how has that been going?”
The Feedback That Nobody Gives: Timing
Feedback delayed is feedback lost. If something happened two months ago, bringing it up now will feel like an ambush, not a development conversation.
Rule of thumb: Deliver feedback within 48 hours of the behavior if possible. If you missed the window, acknowledge it:
“I should have brought this up sooner — I want to be transparent that this has been sitting with me for a few weeks. I want to raise it now because it’s affecting [X].”
Part 3 — The Promotion Conversation
Making a case for someone’s promotion — or your own — is one of the most important business English skills a tech lead needs. Promotion decisions are made by people who don’t always see the work directly. Your job is to create a compelling, evidence-based narrative.
Writing a Promotion Case
Structure: Role expectations → Evidence of exceeding them → Business impact → Readiness for next level
Example — making the case for a senior engineer to be promoted to tech lead:
“[Name] has consistently performed at the tech lead level for the past eight months, both technically and in terms of team influence. Here’s the specific evidence:
On technical scope: She independently led the design and delivery of the real-time notification system — a cross-team effort involving 4 engineering teams and 3 external dependencies. The system launched on time with zero production incidents in the first 30 days.
On team impact: She has become the de facto technical reviewer for the backend team’s architecture decisions. Three junior engineers have explicitly credited her with accelerating their development. She introduced the ADR process, which we now use team-wide.
On business impact: The notification system she designed directly contributed to a 12% improvement in user re-engagement, which the product team has attributed to a $200K increase in monthly retention revenue.
She’s ready for the formal tech lead title. The work, the influence, and the impact are already there. The title is recognition of what’s already happening.”
Phrases for Promotion Discussions with HR/Management
| Situation | Phrase |
|---|---|
| Stating the case clearly | ”I’m recommending [Name] for promotion to [Level]. Here’s the evidence that they’re already operating at that level.” |
| Connecting to business value | ”The business case for this promotion is [specific impact metric].” |
| Handling “not this cycle" | "I understand. Can you help me understand specifically what would need to be true for this to be approved in the next cycle? I want to give [Name] a clear, achievable target.” |
| Advocating when pushed back on | ”I want to understand the concern. From my perspective, [Name] has already demonstrated [specific behavior]. What am I missing?” |
Advocating for Your Own Promotion
Many engineers — especially from Vietnamese professional culture — find advocating for themselves uncomfortable. Here’s how to do it without feeling like you’re bragging.
Frame it as clarification, not a request:
“I want to check in with you about my career progression. I’ve been at [Level] for 18 months, and over the past year I’ve been taking on responsibilities that look more like [Next Level] — specifically [A], [B], and [C]. I want to understand where I stand and what the path forward looks like. Am I on track for promotion this cycle, and if not, what’s the specific gap?”
What this achieves: You’re not saying “give me a promotion.” You’re asking for clarity, which forces a concrete answer — either confirmation that you’re on track, or a specific list of what you need to do, which gives you something to work toward.
Part 4 — Hiring Interviews: Evaluating and Being Evaluated
Conducting a Technical Interview
Your questions reveal as much about your team’s culture as the candidate’s answers reveal about them. Strong interviewers are evaluators AND representatives.
Opening the interview:
“Thanks for coming in — I’m [Name], Tech Lead for the [team] team. Today I’ll spend about 20 minutes on your background and then we’ll work through a technical scenario together. This isn’t about whether you know the right answer — I’m more interested in how you think through problems. There’s no gotcha. Ready?”
Why this works: You immediately reduce anxiety by explaining the format and making clear you’re evaluating process, not trivia.
Probing for depth without being hostile:
- “Walk me through your reasoning there.”
- “What assumptions are you making?”
- “What would change your approach if [different constraint]?”
- “What are the failure modes of this design?”
- “If you’d done this before, what would you do differently?”
When a candidate struggles:
“Take your time — I’m interested in how you approach it, not just the answer.” “Let me give you a hint to keep things moving: [hint].”
Closing:
“Before we finish — do you have questions for me about the team, the work, or anything you’d want to know before making a decision?”
Giving Feedback on Candidates
In an internal debrief:
| Outcome | Phrase |
|---|---|
| Strong hire | ”I’m a strong yes. Specifically, [A] and [B] stood out. The thing that most convinced me was [specific observation].” |
| Weak hire | ”I’m a no. My concern is [specific gap] — [evidence from interview]. I want to be clear it’s [this specific thing], not a general feeling.” |
| Uncertain | ”I’m on the fence. I’d want to know [specific thing] before I could commit either way.” |
Vague debrief feedback (“seemed okay”, “not sure”) is unhelpful and leads to inconsistent hiring decisions.
Being Interviewed for a Leadership Role
When asked “Tell me about yourself”:
Don’t recite your CV. Tell a story about how you got to where you are and what you’re looking for next:
“I’ve spent the last 8 years building product engineering teams in the fintech space — first as a backend engineer, then as a tech lead once my team grew past 6 people. The work I’m most proud of is [specific project] — we took a system with a 40% error rate under peak load down to under 0.5% through a 6-month refactoring program while shipping product simultaneously. What I’m looking for now is [what you actually want — be specific]. When I read about [this company’s] approach to [specific thing], that resonated because [genuine reason].”
When asked “What’s your biggest weakness?”:
“I’ve historically tended toward being too hands-on technically when my team is struggling — stepping in to fix something myself instead of coaching them through it. I’ve gotten significantly better at this by setting an explicit rule for myself: I don’t touch the code until I’ve spent at least 20 minutes explaining the approach and letting the engineer try. It’s improved the team’s capability substantially, but it’s still something I consciously watch.”
Why this works: You name a real weakness (not a humble-brag like “I work too hard”), show self-awareness, and demonstrate what you’re actively doing about it.
Part 5 — Negotiating Scope and Timelines
This is where many tech leads lose ground — not because their technical judgment is wrong, but because they don’t know how to negotiate from a position of technical authority.
When a PM Asks You to Commit to an Unrealistic Timeline
“I want to make sure I give you a reliable answer rather than an optimistic one. Based on what I know today, this is a 6-week effort. If we need it sooner, I see two paths: we could scope it down to [core feature set] and ship in 3 weeks, then complete the rest in a follow-on sprint. Or we could add one engineer to the team for this sprint — that might get us to 5 weeks. What I can’t do without compromising quality is commit to 3 weeks with full scope. Which direction should we explore?”
Key principle: Never say “that’s impossible” — say “here’s what’s possible and here are the tradeoffs.” This keeps the conversation collaborative.
When You’re Asked to Cut Corners
“I understand the pressure, and I want to find a way to hit the deadline. I do need to flag one thing: if we skip the load testing, we’re accepting the risk of a production incident at launch. Based on past incidents, that could cost us [X hours of downtime / Y in SLA penalties / Z in eng time to fix]. My recommendation would be to do a lightweight smoke test at scale rather than the full load test — that gets us 80% of the protection in 20% of the time. Would that work?”
When the Business Wants Something Technically Risky
“I want to be transparent about the technical risk here so you can make an informed decision. This approach would work in the short term, but it creates a [specific type of technical debt] that will add roughly [X weeks] to any future feature work in this area. I can build it this way if that’s the decision, but I’d want to document it as a known risk and plan a refactor sprint within 6 months. Does that tradeoff make sense given the business timeline?”
Part 6 — The Difficult Conversations Nobody Prepares You For
When a Team Member Resigns
Your first response determines whether the relationship survives:
“I’m sad to hear this, but I appreciate you telling me directly. This door is always open — if you ever want to come back or need a reference, I’ll be here. Can you tell me what’s driving the decision? Not to change your mind, but genuinely so I can understand what we might improve for the rest of the team.”
Do not: Make them feel guilty, immediately try to counter-offer, or react emotionally.
Do: Thank them for telling you directly, ask for honest feedback, and ensure a clean handoff.
When You Have to Deliver Bad News to Your Team
(Layoffs, project cancellation, major reorg)
Principles:
- Be direct — ambiguity is worse than bad news
- Acknowledge how it feels — don’t skip this
- Tell them what you know and what you don’t
- Give them a path forward
“I want to bring you together because there’s something significant I need to share. [State the news directly in one sentence.] I know this is hard to hear, and I want to give you space to react to it. [Pause.] Here’s what I know: [facts]. Here’s what I don’t know yet: [open questions and when you’ll have answers]. Here’s what I’m committed to: [specific things you’ll do for them]. What questions do you have?”
When Someone Is Underperforming and You Need to Be Direct
After documented feedback and coaching, a direct performance conversation is sometimes necessary:
“I’ve thought carefully about how to have this conversation, and I want to be direct with you because I respect you. Over the past [period], we’ve talked about [specific issues] in [X] one-on-ones. The behaviors we discussed — [A, B, C] — haven’t changed in the way I was hoping. I’m concerned, and I want to be honest: if this continues, it will affect your standing on the team. I’m not saying this to scare you — I’m saying it because I’d rather have this conversation now and give you every chance to turn it around than have you be blindsided later. What I need to see change is [specific behaviors]. I’ll check in with you weekly for the next 6 weeks, and I’m committed to supporting you through this. But I also need your commitment that you’re taking this seriously. Do you understand what I’m asking?”
Part 7 — Communication Across Cultures
Many Vietnamese engineers work on international teams where communication norms differ significantly. Here are the most important adjustments to be aware of.
Directness Calibration
In Vietnamese professional culture, indirect communication is often more polite. In English-speaking tech environments — especially in the US, Australia, UK, and with international teams — directness is expected and interpreted as competence.
| Vietnamese-style (indirect) | English-style (direct) |
|---|---|
| “Maybe this approach could potentially have some issues…" | "This approach has a race condition that will cause data loss under concurrent writes." |
| "I’m not sure if this is the right place to say this, but…" | "I want to flag a concern.” |
| Staying silent in a meeting to avoid conflict | ”I have a different view on this — can I share it?” |
Important nuance: Direct doesn’t mean harsh. “That’s wrong” is harsh. “I see this differently — here’s why” is direct and respectful.
Hedging vs. Expressing Genuine Uncertainty
Hedging everything reduces your credibility. Reserve hedging for genuine uncertainty — and when you’re uncertain, be specific about what you’re uncertain about:
❌ “I think maybe this might possibly work but I’m not really sure…” ✅ “I’m confident the architecture is sound. My uncertainty is around the exact migration timeline — I’d want to do a spike before committing to a date.”
Following Up After a Meeting
In many cultures, the senior person speaks last and the meeting ends there. In international tech environments, decisions aren’t final until they’re written down. Always send a follow-up:
“Thanks for the productive discussion today. To summarize what we agreed on:
- [Decision 1] — Owner: [Name], by [Date]
- [Decision 2] — Owner: [Name], by [Date]
- Open question: [X] — we’ll revisit on [Date]
Let me know if I’ve missed anything or misrepresented anyone’s position.”
This follow-up habit alone will set you apart from 80% of your peers.
Reference: Leadership Vocabulary Quick Card
Giving Feedback
- “I want to share some specific feedback…”
- “What I observed was…”
- “The impact of that was…”
- “What I’d like to see instead is…”
- “How does that land with you?”
One-on-Ones
- “What’s the most important thing on your mind right now?”
- “Is there anything blocking you that I could remove?”
- “What would make your work more meaningful?”
- “What’s one thing I could do differently as your manager?”
Negotiations
- “I want to find a path that works for everyone.”
- “Here are the tradeoffs as I see them…”
- “I can commit to X, but I need Y to make that possible.”
- “Let’s make sure we’re aligned on what ‘done’ means before we start.”
Difficult Situations
- “I want to be transparent with you about something.”
- “This is hard to say, and I mean it constructively.”
- “I’m committed to supporting you through this.”
- “What do you need from me right now?”
Final Note: Language Is a Skill, Not a Gift
Every phrase in this guide was awkward the first time someone used it. Fluency in leadership communication comes from the same place as fluency in a programming language: deliberate practice, reflection, and iteration.
Start with one section. Pick two phrases that feel slightly uncomfortable. Use them this week — in a one-on-one, a Slack message, a review meeting. Notice what happens. Adjust.
The most respected tech leaders aren’t the ones who never have the wrong word — they’re the ones who keep showing up, communicating clearly, and building trust one conversation at a time.
This is Part 3 of the Business English for Tech series. Part 1 covers Technical Presentations & Demos. Part 2 covers Architecture & Design Discussions.