5 exercises — practise choosing the right level of formality: PR review requests, code review comments, external client introductions, responding to terse messages, and async Slack communication.
Tone & register quick reference
Urgency: use a deadline ("by EOD") not "ASAP" or "URGENT" — time-boxed is more actionable
Code review: questions beat statements — "Would it make sense to…?" instead of "This is wrong"
External emails: professional warmth — "Hi [Name]" + clear purpose + specific ask
Under pressure: action → finding → timeline → next update
Async (Slack): apply "No Hello" — greet and ask in the same message, include context
0 / 5 completed
1 / 5
You need to ask your team lead to review a large PR by end of day. It's already 3pm. Which subject line and opening are the most appropriate?
Tone analysis — why Option B works:
① Subject line is specific and low-pressure — "#412" is actionable (they can click straight to it), "if possible" signals respect for their workload. Contrast with "ASAP" or "URGENT!!!" which trigger resistance rather than urgency. ② Business reason is given — "it unblocks the QA team" transforms a personal request into a team priority. People are more likely to act when they understand the upstream impact. ③ "Would you be able to…" is the standard professional request form — it acknowledges their autonomy, which makes yes easier to say. ④ "Happy to walk you through it" — reduces the effort cost of saying yes.
Formal vs. informal tone guide for IT teams: Use more formal when: writing to someone senior, external contacts, cross-company communication, anything written down permanently (tickets, docs). Use more informal when: Slack DMs with close teammates, quick clarifying questions, celebrating wins.
Tone vocabulary: Informal → Formal: "ASAP" → "by EOD today / by [time]" "Need you to…" → "Would you be able to…" "Hey," → "Hi [Name]," → "Dear [Name]," "Thanks!" → "Thank you for your time."
2 / 5
A colleague sends you this message: "This code is wrong. You clearly don't understand how the event loop works." Which rewrite makes the same point professionally?
Tone transformation — blunt → professional:
The original message fails on three counts: it attacks person ("you clearly don't understand"), it states conclusion without explanation ("this code is wrong"), and it offers no path forward. In engineering teams, this kind of phrasing destroys trust and is the primary cause of toxic code review culture.
Why Option B works: ① "I think there may be an issue" — the hedge ("I think", "may be") is not weakness, it's professionalism. It leaves room for the possibility that you're wrong, which is always true in code review. ② Describes the specific technical problem — "blocking the thread in this callback could cause delays under load" replaces the vague "wrong" with a falsifiable claim. Now the author can actually check if you're right. ③ Offers concrete help — "Want me to share a link?" — this is the key move that differentiates a senior engineer mentality from a gatekeeper mentality.
The CODE REVIEW tone toolkit: Instead of: "This is wrong" → Use: "I think there may be an issue with [X] because [Y]" Instead of: "Why did you do it this way?" → Use: "What was the thinking behind [X]? I'm wondering if [alternative] might handle [edge case]" Instead of: "You need to fix this" → Use: "Would it make sense to [suggestion]? It would handle [scenario] more reliably." Instead of: "This will break" → Use: "This might have issues under [specific condition] — worth testing with [scenario]."
You're writing to a client's CTO (someone you've never met) to introduce yourself as their new technical account manager. Which tone is most appropriate?
Register analysis — finding the right formal-but-warm middle ground:
External business communication requires professional warmth — formal enough to communicate respect and expertise, but human enough to build a relationship. This is different from: • Internal team messages (more informal allowed) • Legal or compliance documents (fully formal) • C-suite board reports (neutral and formal)
Option A is too informal for a first external communication: "Hey!", "you guys", "quick chat" all signal junior/casual register that may undermine credibility with a CTO audience. "Super excited" is common in US startup culture but may read as hollow to many international business contacts.
Option B overcorrects into bureaucratic formality: "I am writing to formally introduce myself" is stilted, and "I look forward to supporting your technical goals" is generic. "At your convenience" is polite but leaves the scheduling open-ended, which delays a response.
Option C hits the sweet spot: ① "Hi [Name]" — professional but approachable first greeting ② Self-introduction with role and company ③ Brief forward-looking statement ④ Purpose: "learn more about your priorities" — signals service, not just admin ⑤ Specific, actionable ask: "Would any time next week work?" — reduces friction
Your manager sends a terse email: "The deployment failed again. What happened?" Which response manages the tone most effectively?
Responding to terse / pressure messages:
When a manager sends a terse "what happened?" message, they have two needs: ① information — what broke and why ② reassurance — is someone handling it. A good response addresses both.
Why Option C works: ① "I'm investigating now" — first word confirms you're already on it, removing the anxiety of "is anyone looking at this?" ② "Preliminary finding" — signals that you have useful information even if investigation isn't complete. This is professional incident communication: you don't wait for full certainty to share what you know. ③ "The same class of issue as last week" — gives context that connects to existing knowledge, making the problem more understandable and traceable. ④ "I expect to have… within 2 hours" — specific time estimate. Even if it changes, it sets expectations and shows planning. ⑤ "I'll keep you updated" — commits to proactive communication, which is what managers need most in incidents.
Terse email response framework: State what you're doing → What you know so far → Estimated timeline → Next update "[Action]: I'm [what you're doing]. [Finding]: [what you know / preliminary cause]. [Timeline]: I expect [resolution] in [time]. I'll update you at [time]."
Option A is honest but incomplete — "I'm looking into it" without any finding leaves the manager without useful information. Option B is passive-aggressive (blaming "the CI system"). Option D is defensive and damages the relationship regardless of whether you're right about the CI system.
5 / 5
Which of these Slack messages correctly applies the "no hello" principle of async professional communication?
The "No Hello" principle in async professional communication:
Sending "Hi", "Hey", "Are you available?" — and then waiting — is the single most common async communication anti-pattern in modern IT teams. It creates a two-step round-trip (greeting → response → actual question → actual answer) when a one-step message could have done the same work. In an async team, this interrupts people twice for one question.
Why Option C is correct: ① Greets and gets to the point in the same message ② States the question precisely: what behaviour, in what condition ③ Provides context immediately: "Asking because I'm implementing X" — Sarah can give a better, more targeted answer ④ Is completely async-safe: Sarah can read this at 4pm, answer asynchronously, and no synchronous availability is wasted
The "what, why, context" async message formula: Who/What: name the thing you're asking about → Question: ask it → Why: explain the context (what you're building or deciding)
Async communication anti-patterns to eliminate: ❌ "Hello" / "Hey" / "Hi [Name]" with nothing else — forces a reply before any information exchange ❌ "Are you free?" — implies synchronous time is required when async might work ❌ "I have a question" — promises information but does not deliver it ❌ "Can I ask you something?" — meta-communication overhead; just ask the thing
Additional resource: nohello.net explains this principle with examples. Reference in your team's async communication guide.