This post contains all the material that I used in my Ignite Australia 2017 Hack@Ignite talk (and I did an interview about it as well!). I received a few requests to either post this online or for myself to give this talk to helpdesks/service desks. If you want to use this yourself, I have absolutely no issues with that – just pretty please give me credit for it and let me know! I really love to know that my words are being used to help others!
At this point I also need to give a huge shout out to Alan Burchill & Lina Ryan for their assistance in helping me put this topic together before I originally gave this talk. Their advice was invaluable in making sure I included all the right information (Alan went above and beyond here!)…and by giving me the assurance that this talk was something I should do!
“Explain yourself!” – sounds almost like a manager getting cranky, doesn’t it?
Well, that’s kind of what this is about. How to avoid the awful “Explain Yourself!” situation because you’ve already been able to explain yourself AND keep people happy at the same time. After reading this, I want you to be thinking about how you phrase your requests, your answers, and especially your refusals into something that non-IT folk can understand and accept. Even if you can just rephrase *one* thing you usually say, I’ll be happy.
We’re all guilty of saying the wrong thing, especially in the heat of the moment:
“No, I won’t do that!”
“No, you can’t do that!”
“Why am I doing it this way?”
“This is stupid!”
Saying those things in your head? Totally fine. Out loud to people…perhaps not so much.
I recently wrote a blog post about the things we, as IT pros, say to users and why they’re important. Problem is, the way we say them is just as important because we tend to come across as confrontational, aggressive and sometimes just plain rude.
With that in mind, I’ve put together a few of the most common things we (as sysadmins) say that really *REALLY* seem to get under the skin of our users and our management. And from there, rework them into something that says what we mean…while not pissing off the person on the other side of the conversation. Be warned, many memes incoming!
We are so used to saying this, it just isn’t funny. “No, you can’t do that”. “No, we can’t buy that”. “No, you can’t access that”. “No, you’re doing it the wrong way”.
I’m guessing we’re like this because a lot of the time, we are the gate keepers to our systems. Things have to flow through us before getting on to the system, going live, becoming production.
At the same time, we’re in customer service – I preach about this a lot. We are here to serve the customer – our business, our organisation, our users. If they want something, we kind of have to give it to them…unless there’s a really good reason. And when we say “No”, there usually is a really good reason, but we’re really *really* bad at explaining it.
So, instead of saying “No”…
We should be saying “No, but I can see what you’re wanting to do, and I think I know of a better way” or “Perhaps we could try doing it this way instead as it’s more secure/reliable/cost-effective than the way you suggested.”
Rephrasing it in such a way that, while you’re denying their original request, you’re still trying to help is the most important part of this conversation. Saying “No” pretty much says “I don’t want to help you”. When you rephrase it offering a better solution, you’re saying that you have an understanding of what they’re asking and you do want to help.
Have you done…
“Have you done this?” “Have you done that?” “Have you done the magical incantation that gets your computer to work again?”
Question after question after question. And often times, especially if you’re dealing with other IT professionals, this can come across as pretty condescending and patronising. Of *course* I’ve tried turning it off and on again. I work with computers, I know how this works! Yes, I totally checked the logs and they meant nothing to me. Go on, ask me another question so I can feel stupid… I know we’ve all felt like this, especially if we’ve all had to deal with some form of technical support on the phone, although I prefer to use the phone for meeting people since they’re some great free chat line numbers services online. I’m thinking of a few well-known ISP’s who do this…
Better way – ask them what they’ve tried…and be prepared to sometimes be stunned by the lengths some users have gone to! You’ll be surprised – I know sysadmins like to slag off about users, but honestly they’re not all as technophobic as we make them out to be. Some are actually quite smart and savvy when it comes to what their computer is doing and are more than willing to pass on information. Many have tried some of the more obvious things, like restarting or trying to access it a different way. Sure, you’ll get the few who haven’t tried anything, but I’m finding those type of users are more in the minority than the majority. Also try to remember that (quite often) restarting *hides* the issue you’re looking into – you may not want a user to restart their machine because you might want to see it while it’s in it’s broken state. Often restarting masks what the actual problem is!
Asking them this question makes them feel like a) they’re involved b) you’re not patronising them and c) you’re not acting as if they’re a technical idiot. It makes them feel that you’re speaking to them rather than speaking down to them.
Are you SURE…
We do this all the time. We call doubt on whether our users have done something that we’ve asked them to do. We make users feel like recalcitrant children who didn’t do their homework, even if they have gone through all the steps we’ve asked. Now, I know a few users who do push the envelope a bit with this one (you do know we can see if you’ve rebooted your PC right?!) but even still, calling them on it just seems petty
Instead, we should be asking them to try again – because maybe the first time didn’t work. Sure, if they’ve already done it, we’re repeating steps. But sometimes they may not have done it right or worse – they may have said they’d done it, because they were embarrassed to ask how. Show them. Walk them through it. Make them feel like they’re part of the solution, not part of the problem. Sometimes they may be interpreting your instructions in an entirely different way, especially when it comes to typing in commands. Don’t make them feel stupid, make them feel like they’re learning something.
I can’t do it if it’s not in a ticket
How many of you have a rule that if it’s not in a ticket it doesn’t get done? Well, if you don’t, you should have. A ticket in a job system is a great way to keep a written record of what went wrong, what was attempted, what was done to fix it and can be used for further documentation. Doing jobs on the fly gives you no basis for measuring that job – how often it comes in, how many requests that person puts in, whether it’s a job that can be easily answered by sending a knowledge base or wiki article to the user… A ticket system is a must for anyone dealing with end-user IT issues, but there are ways to go about letting users know that. Saying “No ticket, no help” really isn’t benefiting anyone.
So instead – if someone calls you and needs something done without a ticket, or stops you in the hallway to take you to their machine, while you’re there, go through the steps of creating the ticket with them. If you’re on the phone, log the ticket yourself, asking all the questions that are usually requested in the ticket. If you’re with the user, get them to log in and walk them through the process. I guarantee, you’ll only need to do this a few times before they realise that doing it themselves before contacting you is a much better use of both their time and your time! Also, if something is urgent, often you’ll want that email as a reference – that way, when someone asks what you’re working on, you can say that you were sent a ticket *AND* an email and it was urgent. But remember, this is only for honest-to-goodness urgent issues. I rate these as things that are affecting more than a certain number of users at once or affecting a business critical process or system.
Don’t give your password to anyone
This is one I harp on a bit and I’ve harped on it online and in talks and at work and to family and to friends and to strangers… We don’t give out passwords. Ever. To anyone. You just don’t. The problem is, we’re not good at explaining the *why* behind this one, which means a lot of users think it’s exactly the same as a whole bunch of other things that we tell them not to do: because it makes our jobs easier. This one isn’t about making our jobs easier – because if we’re to be honest, some thing would be much easier if a user could give us their password! This is about privacy and about security and keeping protected information safe. So…
In place of doing the blanket warning of “Don’t give you password out”, explain why. Tell them that if they do, the person they’re giving it to has access to all the information they do. Can impersonate them in emails and instant messenger. Can modify private files. Can access websites they shouldn’t. Or worse (and this one really seems to get people’s attention) – when it comes to work passwords, if you give that out to someone else, that gives them the ability to modify where your pay check goes to. If people don’t care about their online identities, I’m damn sure they’ll care about their cash! And this goes for us to – don’t ever EVER ask for a users password. I still remember this happening in my first job and it gives me shivers thinking about it.
You don’t need admin rights…
I’m a hard arse when it comes to this. If any of you have been to my “Righting the Right Rights” talk, you’ll know that I’m big on preaching a separation of admin accounts (if you’re a DA, you get FOUR accounts!) so I know I’m even guilty of this one.
“No, you don’t need admin rights” *slap*
This is a bit harsh…and I definitely should phrase this better.
Instead of saying they don’t need admin rights because chances are, if they’re coming to you, they think they do need it – why else would they be braving your wrath? Find out what access they believe they need. They might surprise you – they might need some delegation on their account or they might actually need an admin account to do what they’re needing to do! Remember, when I say that everyone gets admin rights (see the glorious Oprah picture above!), it doesn’t necessarily mean top-level access.
Remember, we can delegate access to what’s required – getting a bit technical here, but bear with me! It could be they need a desktop admin account, so they can install some software. It could be a server admin account, so they can remotely access a specific server they’re responsible for. We can delegate access to OU’s, to individual GPO’s. We have LAPS and the ability to randomize passwords. We have the ability, via GPO’s, to push out local admins if required. Very few people need the keys to the castle! I can only think of a handful of reasons why someone would ever need to be elevated to Domain Admin or Enterprise Admin and even then, your Domain Admins shouldn’t be admins on your workstations! If you’re interested in any of this, hit me up on Twitter – more than happy to go into further detail about this stuff!
You can’t access the internet on that!
This one is usually aimed at developers. This is where they want to do something and sysadmins are like “HELL NO!” – usually because they want open slather internet access. Allowing open-slather internet access on a server is just asking for trouble. Similar to admin rights, it’s very rarely actually needed. It’d be nice, sure – but it’s not needed. The internet is a hive of scum and villainy, it’s where dangers lurk and where the bad things come from.
However, it’s often not that clear-cut and we could be a little bit more lenient – after all, there’s no point having security in place if it hinders the job the person is trying to do, so…
Let’s find out what it is they’re actually trying to access. It might just be a single site. It could just be a handful of IP’s. In those kind of scenarios, it’s a very small risk profile that we’d probably allow. So instead of jumping off the deep end, let’s find out what they’re actually trying to access. Remember, there is the hardline approach of no default internet access – which is fine. But there can be exceptions to the rule. They just have to be clear and concise and there has to be a genuine business need for them. Balancing security with usability is a big part of what we do! However, internet browser on servers…baaaaaaaad juju!
It’s not broken for me!
There is nothing that frustrates a user more than being told that what they’re trying to do is working fine for you. I mean it. I know how annoying it is, having been on the end of those phone calls with certain ISP helpdesks being told that everything is fine. Everything is NOT fine. Something is DEFINITELY broken because it’s not working. Just because it’s working for you doesn’t necessarily mean it’s going to be working for me – else why the hell would I be calling?! So have a little empathy when dealing with users. Remember that they may not use the right terminology, they may not know exactly what’s broken and they’re relaying to you the wrong part.
Show them that you understand that while it might be working for you, they’re obviously seeing something different. Walk it through with them. Find out what it is they’re doing. They might be doing things a slightly different way to the way you would, throwing a spanner in the works that’s causing the issue. They might be using an entirely different program to the one you thought they were. They might have forgotten to mention a crucial piece of information – like that they’re using wireless instead of wired. Be patient and really listen!
For developers, this is a good reason to use either VM’s, that can be blown away and rebuilt – or even containers. The SOE is standardized and remains the same, they can do whatever they want to do in their sandpit and destroy it…provided they don’t expect us sysadmins to help clean it up!
We can’t throw (insert hardware) at it!
Another one for developers and this seems to pop up quite often – “Just throw more RAM at it, it’ll work”. “Just give it more bandwidth, I’m sure it’ll go faster”. That’s often not how it works. And that won’t fix the problem, just mask it. We know that throwing more hardware isn’t going to fix the problem and will often end up costing the customer a ton of cash that they wouldn’t need to…but we still have to understand that they’re the customer and they’re asking us to do something, so we have to come to some kind of understanding: a middle ground.
There’s obviously some kind of bottleneck that’s causing the issue. Either things aren’t fast enough, or something is actually causing problems, so hardware is what was first thought of as being the cause of it all. However it can sometimes come down to working out what that bottleneck truly is. It might be fixed by a tweak of a setting or a change in the software. Or it might be that the configuration for the application has been so underspec’d that it would *never* work. See things through the users eyes and then you understand where the problems lie. Speaking with a fellow IT Pro (told you Alan Burchill helped me out with this!), he calls this the “scale up or scale out” approach. If throwing more hardware at it works, then get beefier servers. If it won’t? Then scale out and look at running on multiple. This is where the cloud can be useful!
The internet isn’t down…
The number of users who seem to think that the internet is the centre of the universe and that when something breaks, the whole world is broken. We, as sysadmins, know that’s just not the case. We know it’s not the magical “internet” – because for a large number of us, there’s any number of firewalls, switches, servers and proxies between us and the outside world. If you’re not in that bucket, lucky you!
Obviously they’re seeing an issue. Something is broken and, for want of a better word, they’ve decided the “internet” is going to be their fall guy. Sure, the internet isn’t the real cause, but you saying “It’s not the internet” isn’t going to help you *or* them. Get them to try accessing both an internal and external site. Often “the internet” is code for “something on the network”. It could be they can’t access their email… or one of the file servers isn’t letting them access their files… or the intranet website is down. Explain calmly that they’re having issues and you believe what they’re having issues with is [insert thing here] and that you’ll investigate. Don’t be patronising, they’ll definitely pick up on that!
Did you have it backed up?
Ah the joy of 20-20 hindsight. Everyone says they’d implement backups *after* they’ve been through some of major disaster or outage…it’s just a shame more don’t think of it *before* disaster strikes. Chances are, the user *thought* they had it backed up when they really didn’t. Shoveling on blame now isn’t going to help anyone, so it’s best to help as much as possible…
…and the best way to do that is to start by helping the user set the backups up so that it doesn’t happen again. This also goes for us admins – because we often don’t back up all the stuff *we* need to. If you’re an AD or GPO admin, BACK THAT STUFF UP! Trust me, you want to be able to pull some of that stuff back at a moments notice!
We need to do…
Now, onto a few things we tend to tell our own managers and this one is probably the most common – we need to do this. We need to implement that. We need to put this in place. We need, we need, we need…without the why.
My learnings, so far, is that managers tend to deal better if you give them the benefits up front. Doing means X we’ll save $Y. Doing X means an increase of Y% productivity. Numbers are always good. Sometimes you can’t give numbers, often it’s a new feature which will help the business. Tie it back to any business strategies or goals and you’re laughing.
Key words here? “Business Requirements”. Remember, there’s no point doing something if it doesn’t serve the business in some way.
I need training on…
Similar to the last one, saying “I need…” doesn’t get you very far. They just hear “I” and tune out. Sure, it might be true that you do need training on a specific tool or technology, but again – there needs to be a benefit to the business. And selling yourself isn’t always the best way.
Note the skills gap. Allow them to delegate the best person for it. Sure, it could be you – but it might not. There might be someone else better suited to that training. Allow the rest of your team to get some of it – there’s no point in you being the person trained up on everything, unless you’re an AMAZING trainer and can come back and train the entire team. You want to share the knowledge, and you want to be able to take leave without leaving a giant gaping hole in your team…or receiving phone calls when you’re on leave and just trying to relax!
What do you want me to DO?
This is the big one – from users, to clients, to managers, to executives. As sysadmins we’re pulled in multiple directions and it’s easy to fling up your hands with a “Well, what do you want me to do?!” statement.
The biggest issue with this is that it’s often not helpful. Our managers may tell us to do one thing, or users might want us to do another. Because you’re asking the wrong question. It’s not what you should be doing. It’s what *THEY’RE* trying to achieve. Finding that out is crucial, as it allows your time to be better suited to following that, rather than what someone thinks you should be doing in pursuit of that – there’s a reason we’re SME’s, people!
Always be wary of people who come to you with solutions instead of problems. Make sure you know what problem they’re trying to solve so you can help tailor a solution. Sure, they might already have the best solution, but they might not. It comes back to the magic “Business Requirements” again. Everything – even the smallest thing you’re doing – needs to serve the business in some way!
Now some stats, courtesy of CBT Nuggets – sorry, less amusing than memes, but a tad more useful! These are a few extra pieces of information, especially around dealing with end users:
- It takes 12 positive experiences to make up for a bad one
- Using positive language is the most important thing – phrase things in a positive light and people will take them positively
- Don’t apologise if it’s not your fault – users understand that technology does weird stuff, it isn’t a persons fault, just try to be empathetic!
- Let users tell you their side of the story – don’t assume you know everything…you never know, you might learn something!
- Provide answers to your customers that they’ll understand – not everyone knows everything about computers, if you have to use simpler language and terminology to help, do it – just be sure not to patronise!
- Remember – this is the first time they may have had to deal with this particular issue. While you may have plenty of experience fixing this one thing, they may never have come across it!
Finally, some links that I included in my talk that people have been asking for:
- CBT Nuggets link for the information in the previous section (with a GREAT infographic that should be printed and put in every helpdesk/service desk) – https://www.cbtnuggets.com/resources/infographic/people-skills
- 10 highly valued soft skills (though they’re just SKILLS) for IT Pros – http://www.techrepublic.com/blog/10-things/10-highly-valued-soft-skills-for-it-pros/
- 15 customer service skills that every employee needs – including and especially IT folks! – https://www.helpscout.net/blog/customer-service-skills/
So that’s it – a few things we can do and some information to keep in mind when we’re dealing with our users, our management, our business – remember, we are in customer service. We’re here to help the people in our businesses and organisations do their job to the best of their ability – and we mustn’t forget that. It’s the reason we have our jobs!