The meaning of your communication is the response you get.

Those familiar with NLP- Neurolingistic programming - may recognise the phrase. It certainly seems a bit odd, but in an important sense it’s true: whatever you say or ask will be interpreted, ignored, misunderstood, and just occasionally, you get back what you really hoped for.

Here’s an example email: “Dieter, please send me the relevant information about incident HA365532” 10 minutes later, Dieter replies:

“Server XD345532 experienced periodic displays of slow response between 07:14:56 CET and 11:19:52 CET. The response times should normally be a maximum of 200ms. During this period there were periods of up to 10 minutes where this increased to 10,000ms. The full trace is attached.

We hit the server with various additional loads of test traffic. This seemed to make no difference, either in the normal times, nor in the slow response periods.

Other servers in the same rack: XD 345531, XD345530, 345533, 345534 were not affected. We have found no recorded differences in the CMDB, so we are starting a forensic examination for differences, which we expect to complete in the next hour”

Now for a different example: “Hello, JNET. We’d like you to look at the 25 minute outage on our network, and let us know what you can tell us about the cause.”

The reply comes promptly (in this case): “We have checked our systems, and everything is normal”

What just happened? Is it our network vendor’s mission to be unhelpful?

The truth is that all of our behaviour is driven by stimuli of different sorts; if the person we seek help from has the time, has the tools, has a supportive environment, and crucially- understands exactly what we want, they are likely to help.

You may not be able to do very much about the working environment of external support staff, but you can influence their understanding of what is needed with the quality of your communication.

Dieter didn’t need it spelled out; he knows what’s required in cases like this. And he has the time and inclination to help.

With others it may not be the same:

·      They’re under pressure to move tickets on or close them

·      They lack information about the systems they support. The CMDB is a distant dream

·      They are constantly being moved around to support different customers, so they rarely get to learn your environment

So?

So the only hope you have to become much more explicit in your expectations. Make clear what you need, AND what you want it for. If you don’t have a Dieter at the other end, your message will need to be something like.

“Hi Jim

With ticket HA365532 we saw an unexplained level of poor response for just over four hours, and we need to establish cause quickly to avoid any chance this occurs across the whole DC.

With that in mind, please send me:

.log files for Server XD345532 in the period 06:00 to 11:20 CET today, and the same for servers XD 345531, XD345530, 345533, 345534.

Once you’ve done that, please ask your on site team to do a forensic examination of these 5, looking for any small differences between XD345532, and the other 4 which were working normally. This includes BIOS, Firmware, Middleware and anything else you think may influence performance.”

With this example, we see two important facets of communication: the requests are very specific AND the intention is made clear.

 It would be nice if we were always surrounded by people to whom we could just say, “please do the needful”, but we’re not. A few moments extra crafting your message will save you hours later, and possibly prevent the next major outage..