1 Communication Is an Operational Skill
IT professionals spend a surprising amount of time communicating — replying to support tickets, writing customer emails, joining troubleshooting calls, explaining an outage, requesting logs, speaking to developers, escalating incidents, updating managers, writing internal notes, documenting fixes, handing cases between global teams, presenting technical findings, explaining risk, and writing incident reports.
Poor communication can cause technical problems itself. Consider: "The server is broken. Please investigate." This gives the receiving engineer almost nothing useful. A better message would explain which server, which environment, what service is affected, when the issue started, what changed, what symptoms are observed, how many users are affected, what troubleshooting has already been completed, and what logs are available. Communication should reduce uncertainty.
2 The Core Rule: Clear, Accurate, Useful
Good technical communication should usually be clear, concise, accurate, structured, professional, factual, and actionable. Avoid making messages unnecessarily complicated.
Which version below is better technical writing?
A) "Following further comprehensive analysis undertaken in relation to the aforementioned authentication issue, it has been determined that there appears to potentially be a communication problem between the application server and identity provider."
B) "We identified a connectivity issue between the application server and the identity provider."
Reveal the answer
B. Both sentences describe the same finding, but A hides it behind padding — "following further comprehensive analysis undertaken in relation to," "it has been determined that," "there appears to potentially be." None of that adds information; it only adds reading time. B says exactly the same thing in twelve words. When you're editing your own messages, look for phrases you could delete without losing meaning — that's almost always where the padding is.
3 Know Your Audience
One of the most important communication skills is adjusting your explanation depending on who you are speaking to. The same incident may need to be explained differently to a developer, a network engineer, a customer, an IT manager, a CIO, or a security analyst.
Imagine users cannot log in because the identity provider's token endpoint is failing:
- To an IAM Engineer: "The client is receiving HTTP 503 responses from the OAuth token endpoint. DNS resolves correctly and TCP 443 connectivity succeeds. The issue appears to occur after TLS negotiation." Technical detail is appropriate here.
- To a Service Manager: "Users are currently unable to authenticate because the central identity service is unavailable. The infrastructure and identity teams are investigating." Protocol-level detail usually isn't needed.
- To an Executive: "Approximately 4,000 users are currently unable to access the customer portal. The incident began at 09:20 UTC. Engineering is investigating and the next update will be provided at 10:00 UTC." The executive needs impact, scale, status, ownership, and next update — not packet traces.
4 Separate Facts from Assumptions
Engineers often form hypotheses while troubleshooting — that's normal. But hypotheses must not be communicated as confirmed facts.
Which is the more professional way to report an unconfirmed suspicion?
A) "The firewall is blocking the connection."
B) "We suspect the firewall may be blocking the connection because the TCP handshake does not complete. The network team is validating the rule set."
Reveal the answer
B. Use language such as "evidence indicates," "initial findings suggest," "we suspect," "we are investigating," "not yet confirmed," or "currently under review." It is also acceptable — often better than guessing — to say you don't yet know: "We have confirmed that authentication requests reach the gateway. We have not yet determined why they fail before reaching the identity service." That demonstrates progress without pretending the investigation is complete.
The same discipline applies to timelines. Never invent an ETA you don't control. "This should be fixed within an hour" can create serious problems if you're wrong. Instead, distinguish a resolution ETA ("We will fix it by 15:00") from a communication ETA ("We will provide another update at 15:00") — the second is usually the safer one to commit to.
5 The Five Questions Every Technical Message Should Answer
Whenever possible, a technical message should answer:
If your message answers these five questions, it is usually useful — regardless of whether the audience is an engineer, a manager, or an executive. The rest of this module is really just this checklist applied to specific situations: customer emails, incident updates, escalations, handovers, and executive briefings.