Tag Archives: writing

How to Send an All Staff Technical Email

This post was originally published on the Idealware Blog in April of 2009.

I had big plans for another insightful, deep, break-down-the-walls-of-the-corporate-culture-that-diminishes-use-of-technology post today, but I think I’m gonna save it for a rainy day and write something a bit more useful, instead.  I have a big nonprofit technology conference coming up this weekend, as you might, as well, and I think we should all be resting up for it.

The most important skill for any IT staff person to have is the ability to communicate.  All of the technical expertise in the world has little value without it, because, if you can’t tell people what you’re doing, what you’re doing won’t be well-received.  And there is an art, particularly with tech, to telling people what you’re doing, whether it’s taking the system down for maintenance of upgrading staff from Notepad to Office 2007.

Here are my five rules for crafting an technical email that even my most computer-phobic constituents will read:

  • Let no acronym go unexplained

The simplest, worst mistake that techies regularly make is to tell people that

“The internet will be down while we reconfigure the DHCP server” or

“The database will be unavailable while we replace the SCSI backplane”.

Best practice is to avoid the technical details in the announcement, if possible.  But if it’s relevant, speak english: “In order to accommodate the growth of our staff, we need to reconfigure the server that assigns network resources to each system to allow for more connections.”

  • Be clear, concise and consistent in your subjects

Technical messages should have easily recognizable subjects, so that staff can quickly determine relevance.  If your message is titled “Technical Information”, it might as well be titled “You are getting sleepy…”  But, if it’s titled “Network Availability” or “Database Maintenance Scheduled”, your staff will quickly figure out that these are warnings that are relevant to them. Don’t worry about the Orwellian aspect of announcing system downtime with a message about availability.  The point here is that using the consistent phrasing will grab staff’s attention far more effectively than bolding, underlining and adding red exclamation points to the email (see rule 4).

  • Keep it short and simple

It’s about what the staff needs to know, not what you’d like to tell them.  So, the network maintenance email should not read:

“The systems will be down from 4:30 to 9:00 tonight while we replace drives in the domain controllers and run a full defrag on the main document server”

It should read:

“The network will be unavailable from 4:30 pm until 9:00 pm while we perform critical maintenance”.

If it’s only a portion of the network, but something useful will be up – as when the file servers are being repaired, but email is still available, make a note of that: “While the main servers will not be available, you will still be able to send and receive email”.

  • No ALL CAPS, no exclamation points!!! and go sparingly on the bold

System downtime might be urgent to you, but it’s never urgent to the staff.  It’s a fact of life.  A reply from the Director of Online Giving that the downtime will jettison a planned online campaign is urgent; not your routine announcement.

  • Tell the whole story

…even if this sounds like it conflicts with rule 3.  Because there are two types of people on your staff:

  1. The majority, who want simple, non-techie messages as described above
  2. The rest, who want the gory details, either so they can rest easy that you aren’t making anything up, or because they’re actually interested in what you’re up to.

My approach is to do the simple message and, below it type, “Technical Details (optional reading)”.  In this section I might explain that we’re replacing the server that processes their network logins (I won’t use “DHCP” or “Domain Controller” if I can help it) or that we’re upgrading to the new version of Outlook.

The key concepts here are consistency, simplicity, and a focus on what impacts them regarding what you’re doing.  Stick to it and, miraculously, people might start reading your all staff emails.