One of the key skills of a successful Sysadmin is the ability to communicate both ‘up’ (the management org chart) and “down” (to your end users).
It’s long been a dark joke in IT circles that: “When you do something right, it seems like you didn’t do anything at all.” It’s far too easy (and common) for the hard work and effort of a Sysadmin to be overlooked – better communications are the key to escaping this trap.
You’re likely reporting to someone who doesn’t know the difference between a MX and a CNAME record, doesn’t have an opinion on backup strategies, and only the most tenuous grasp of what the “cloud” means (hint: it means “other people’s computers”).
So, how do you best work with that person?
First: Broadcast how your efforts directly impact the company. It’s unlikely that the executives are aware of what it is exactly, that you do, why your work is important, what measures you’ve taken to counter security breaches, and how it benefits the company.
- Send weekly reports of actions taken
- Tie reports into revenue or productivity impacts.
– “Prevented PRODUCTION_SYSTEM downtime by apply updates X,Y and Z”
– Revenue example
- Forward industry articles along as an “FYI – this is something we’re monitoring for possible business impacts.”
Second: Emphasize requirements and needs as industry standard: there’s often a misconception that IT department merely wants more to play with – toys, not assets that are necessary to keep the company running.
Set up Google Alerts for competitors and keep an eye out for case studies from companies that your executives admire. Vendor case studies are a great thing to forward saying: “I’m not recommending we buy $SOLUTION today, but our competitors are preparing themselves for these problems using these tools.”
The number one reason you should focus on communicating structured information (System X will be unavailable at Y) to your end users is that if you do it well, it removes the need for them to contact you in an unstructured way (“AAH! Everything is broken!”)
Establish a pattern for how you write subject lines.
This can be as simple a using consistent prefixes: INFO, DOWNTIME, REQUEST, ALERT
Having a pattern lets you communicate quickly and effectively, with the bonus of earning trust by not wasting everybody’s time.
Set a firm policy for how much lead time is required (and include deadlines) for any given action or request.
Unless things have really gone off the rails at your place of employment, your users’ job performance isn’t based on whether or not they read and respond to your emails. It’s frustrating, but just not their top priority.
Give ample time to respond, ask questions and determine the impact of any changes you are making.
Be upfront in what needs done, and provide contextual information to back it up.
The very first line of every email is all that matters. Mostly. It should convey exactly what you need done, any vital information you need to communicate, and why it’s important. Be concise.
Don’t write 3 paragraphs of prose or copy and paste a bunch of release note bullet points into an email and accidently bury the phrase “…and if you don’t do this all your files will be lost forever.” It’s a headache you don’t need.
Look. At some point in your career, a user is going to go to your boss and say “I had no idea this was going to happen! Your Sysadmin is horrible!” Instead of arguing, you can just forward the email to them and go get a cup of coffee.
Make every email count.
Pretend you’re John McClane and you’re running out of bullets. You want every single one to count.
Be as targeted in your communications as possible: Establish granular lists of users based upon what devices, job role and application access that they have.
Stick to the “rule of two” as general policy – always email when:
- There will any downtime or disruption of somebody’s job.
- It impacts the direct revenue of the company – especially with Point of Sale, Ecommerce or anything financially related