Download / Stream ‘Love Death Immortality’: https://smarturl.it/TGM_LDI
Shop Limited Edition Merch & Vinyl: http://shop.theglitchmob.com

FOLLOW THE GLITCH MOB
——————————————
Text Us: +1 (323) 210-3654
http://instagram.com/theglitchmob
http://spoti.fi/1rkv39e
http://youtube.com/glitchmob
http://twitter.com/theglitchmob
http://facebook.com/theglitchmobmusic
http://soundcloud.com/theglitchmob
http://theglitchmob.com

The Glitch Mob - Can't Kill Us

Cycles

If you are really going to master DevOps you need to master communications.  At least the ability to clearly motivate and pull people into the discussion and the goal you are trying to achieve.  Spending an extra fifteen or twenty minutes writing an E-Mail can save you days and sometimes weeks of discussions, arguments and apologies.  I have a lot of tips about how to be more effective in communicating ideas but today I am going to give you my top six.

What is the goal of your communications?
A goal is essential to forming any effective communications.  If you don't really know what you want to achieve with the message how will anyone else.  Some common goals for me when I was an operations lead were getting help with a Memory Leak, let everyone know about upcoming patches to the middle ware, or getting someone to help figure out why a build or deploy is failing.  Once you know what the goal is you can easily expand on it and form a complete thought and translate it into a communications.

What is your motivation for writing the communications?
Sounds weird I know.  Communicating why you are trying to solve the problem often goes a long way towards getting people's sympathy or at least an understanding about why you care about the problem.  If you try to hide this or omit it you run the risk of pushing people away.  That will also draw people in.  In those cases where you are trying to help someone else it will also draw them into the communications and compel them to read on.  So state it clearly but don't go and on about it.  I normally try to keep my motivations locked up in one sentence.  To much discussion can come off as bragging, whining, or self-righteousness depending on what is being said.

What are you trying to motivate others to do?
This one sounds super obvious but it is really more about how you say it then what is being asked or said.  This is really the sales pitch part of any communications.  I know that for a lot of people this is the most difficult part.  We all normally hate being sold things so the idea of selling things to others can be difficult. The thing that really good sales people know is that the best way to sell is not to be a pushy sales person.  Instead focus on the benefits of the person you are -selling to- asking for help from.  Everyone wants to look good doing what they do best.  Making people feel important by asking them for help in areas you aren't the best in is also helpful.  A little humility will go a long way towards winning people over to your way of working and thinking.

Stay away from certain exclusive words and use more inclusive words.
I only speak English so I am not sure if this part holds true in all languages.  In English though words like I, me, my, us, Department/Group Names, them and you tend to imply an exclusion of the reader or you as the writer.  This exclusion while a minor thing really can put people off and make them restive to your ideas for various reasons.  Some people will think you are blaming them, others may think you are dumping work on them, and still others just may not know you so they will use these words as an excuse to ignore you.  Instead focus on using words or phrases that imply inclusion like we, our, as a team, etc.  Depending on the context these words will have different levels of affect.  They will always be positive it's just that some situations are just naturally inclusive so the effect of this is just less visible.

Leave the door open to Dialog.
Often times the communications I receive are worded as statements of fact and not statements open for discussion.  They seem to be written by people who have already decided what the best approach is and they want me to rubber stamp it.  It's my job as a Solutions Architect and previously as a Team Lead to resist this.  If you are talking about my area of expertise and haven't asked me for input you might even piss me off.  So while stating your plan may be acceptable make sure you are always asking for feedback in the communications.  This could be a requested meeting, a response to the message, or flat out asking what issues the readers see in what you are presenting or proposing.  

Like a good beer let it ferment.
That's right the best thing to do in most cases is just to let the communications sit for a few hours, overnight, or longer if possible.  This is especially good for those times when you are really upset by the actions or lack of actions around a problem.  If the communication is an E-Mail save it and go take a walk.  I will often write an E-mail, save it as a draft, and then go to lunch.  Then when I get back open it up read it I will be fresher and calm.  Normally I re-write about half of it to incorporate the other items on this list.  Even if I wasn't upset when I wrote it I will normally find places where I can make it better.  

Let's look at an example.
As an example here is a less than optimal communication:

"Hey Guys,
I really need you guys to look at this memory leak.  It's effecting the sites performance and the up time stats. When can your team fix it?
Thanks,
DevOps Master"

Something like this would probably work better:
"Hey Guys,
We are all really starting to see the effects the slow performance and a growing number of outages that appears to be caused by a memory leak from the look of the stats.  Let me know when we can get together today to discuss a strategy to identify the real problem and fix it.
Thanks,
DevOps Master"

The second one pulls the reader in, states the problem I need help with, and asks for a meeting to plan the approach.  Remember to always ask for what you want like a meeting today.  Expect that your requests are not always realistic and be accepting of those responses offering a different solution or meeting time.

Never forget that everyone is busy.  The less time everyone spends being irritated with how things are written the more time we all have to fix problems.  So make a effort today to write something better.  Ask others to proof what you write looking for the things in this article.  Look for me to post more tips for improving your communications in future articles.

Episode 19 - Devopsmastery.com -  Six tips for more effectively DevOps communications

This podcast is all about doing the DevOps thing.  We are here to help you get from a DevOps newbie to being a DevOps Master.

Episode 19 - Devopsmastery.com - Six tips for more effectively DevOps communications

Devops Mastery

Related tracks