5 exercises — the same information can be correct or disastrously wrong depending on how formally you say it. Practise recognising the right level of formality for announcements, incidents, client email, and team communication.
Register levels in IT communication
Casual / team Slack — informal, fast, emoji OK, first names, contractions
Professional / formal Slack — clear, structured, minimal jargon, no filler
Incident communication — factual, templated, no emotion, precise
Client-facing email — formal, no internal jargon, confident, polite, proactive
0 / 5 completed
1 / 5
You need to announce a planned deployment to the entire engineering org. Which message is appropriate for a formal announcement Slack channel (#engineering-announcements)?
Formal announcement channels require precise, actionable information: what is being deployed, when (with timezone), the expected impact, and a contact point for questions. Option A ("thingy", "Should be fine 🤞") is too casual and shows low confidence. Options C and D are too vague — they omit the timezone and use casual language ("auth stuff", "Quick thing"). Option B hits the right register: concise, professional, gives all essential details. The structure of a good deployment announcement: [What] + [When with timezone] + [Impact] + [Contact]. Even in casual-culture organisations, announcements that affect other engineers deserve clarity — developers in different timezones rely on this information.
2 / 5
A SEV-1 production incident is happening: payments are failing for all users. Which message is correct for the incident Slack channel (#incidents)?
Incident communication has a specific format. In high-stress situations, emotions and vague language cause wasted time. The standard incident channel format includes: (1) Severity level (SEV-1), (2) What is broken (service name + symptom), (3) Impact (who is affected, to what extent), (4) Status (investigating / mitigating / resolved), and (5) Incident commander or owner. Option A is emotional and creates noise. Option B implies blame and offers speculation. Option D uses "I think" — dangerous when you should state facts and unknowns separately. Option C is factual, structured, and immediately useful. Many teams use an incident template: "SEV-[N] | [What is broken] | [Impact] | [IC: @person] | [Bridge: link]".
3 / 5
A non-technical client emails asking for a project status update. Which reply is the most professionally appropriate?
Client-facing communication requires confidence, precision, and professional language. "Hacking on it", "stuff", "TODOs", and "push to prod" are all internal jargon that a client might find confusing or concerning — "hacking" especially has a negative security connotation. Option D ("I think?", "if nothing breaks") signals low confidence and shifts the risk to the client. Option C uses clear structure: completed work → current status → estimated completion. Note it avoids internal jargon ("API" is acceptable with a technical client; for a non-technical client, say "the server-side logic"). Writing to clients: always translate tech language into business language. "The backend API is complete" → "The data layer is built and tested." "Deploying to production" → "Making the feature live."
4 / 5
You want to ask a colleague to review your pull request. Which message is most appropriate for a professional team chat?
The ideal review request gives the reviewer everything they need to prioritise and prepare: a link or ID, what the PR does, and why it matters. Option A is too casual ("Yo", "kinda urgent") and wastes the reader's time with informal padding. Option B lacks context — "urgent" without explanation creates friction. Option D ("immediately", "This is required") is too demanding and may come across as aggressive. Option C is the sweet spot: polite ("Could you"), contextual (what it does), and motivating (why it matters — sprint goal). A well-written PR request also reduces back-and-forth: the reviewer knows what to focus on before they open the code. Add a direct link when possible: "Could you review [PR #847](link)?"
5 / 5
You need to write an email to a client apologising for a delayed feature delivery. Which opening sentence strikes the right tone?
Apologising to a client professionally requires: (1) a clear, direct apology, (2) a brief, factual explanation — not excuses, and (3) a forward-looking statement. Option A ("stuff came up") is too vague and casual — it sounds like you didn't take the deadline seriously. Option C ("my bad") is too informal for a client email. Option D is over-apologising — it signals panic and damages confidence more than it helps. Option B is ideal: it acknowledges the delay directly, offers a factual (not emotional) explanation, and uses professional phrasing. The next sentence should give a new date and any mitigation steps: "We expect delivery by [date]. We have [specific action] to ensure this timeline is met." Avoid blaming tools, third parties, or the client's requirements in the explanation.