{"id":1685,"date":"2017-03-09T21:17:33","date_gmt":"2017-03-09T11:17:33","guid":{"rendered":"https:\/\/girl-germs.com\/?p=1685"},"modified":"2020-04-04T07:16:05","modified_gmt":"2020-04-03T21:16:05","slug":"explain-yourself-explaining-what-we-do-while-trying-to-keep-everyone-happy","status":"publish","type":"post","link":"https:\/\/girl-germs.com\/?p=1685","title":{"rendered":"“Explain Yourself!” – Explaining What We Do, While Trying to Keep Everyone Happy"},"content":{"rendered":"

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<\/a>!). 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<\/em> give me credit for it and let me know! I really love to know that my words are being used to help others!<\/p>\n

At this point I also need to give a huge shout out to Alan Burchill<\/a> & Lina Ryan<\/a> 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!<\/p>\n

\n

\u201cExplain yourself!\u201d<\/strong> – sounds almost like a manager getting cranky, doesn’t it?<\/p>\n

Well, that\u2019s kind of what this is about. How to avoid the awful \u201cExplain Yourself!\u201d situation because you\u2019ve already been able to explain yourself AND<\/strong> 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\u2019ll be happy.<\/p>\n

We\u2019re all guilty of saying the wrong thing, especially in the heat of the moment:
\n\u201cNo, I won\u2019t do that!\u201d
\n\u201cNo, you can\u2019t do that!\u201d
\n\u201cWhy am I doing it this way?\u201d
\n\u201cThis is stupid!\u201d<\/p>\n

Saying those things in your head? Totally fine. Out loud to people…perhaps not so much.<\/p>\n

I recently wrote a blog post about the things we, as IT pros, say to users and why they\u2019re important<\/a>. 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.<\/p>\n

With that in mind, I\u2019ve 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!<\/p>\n

No<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

We are so used to saying this, it just isn\u2019t funny. \u201cNo, you can\u2019t do that\u201d. \u201cNo, we can\u2019t buy that\u201d. \u201cNo, you can\u2019t access that\u201d. \u201cNo, you\u2019re doing it the wrong way\u201d.<\/p>\n

I\u2019m guessing we\u2019re 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.<\/p>\n

At the same time, we\u2019re in customer service \u2013 I preach about this a lot<\/strong>. We are here to serve the customer \u2013 our business, our organisation, our users. If they want something, we kind of have to give it to them…unless there\u2019s a really good reason. And when we say \u201cNo\u201d, there usually is<\/strong> a really good reason, but we\u2019re really *really* bad at explaining it.<\/p>\n

So, instead of saying \u201cNo\u201d…<\/p>\n

\"\"<\/a><\/p>\n

We should be saying \u201cNo, but I can see what you\u2019re wanting to do, and I think I know of a better way\u201d or \u201cPerhaps we could try doing it this way instead as it\u2019s more secure\/reliable\/cost-effective than the way you suggested.\u201d<\/p>\n

Rephrasing it in such a way that, while you\u2019re denying their original request, you\u2019re still trying to help is the most important part of this conversation. Saying \u201cNo\u201d pretty much says \u201cI don\u2019t want to help you\u201d. When you rephrase it offering a better solution, you\u2019re saying that you have an understanding of what they\u2019re asking and you do want to help.<\/p>\n

Have you done…<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

\u201cHave you done this?\u201d \u201cHave you done that?\u201d \u201cHave you done the magical incantation that gets your computer to work again?\u201d<\/p>\n

Question after question after question. And often times, especially if you\u2019re dealing with other IT professionals, this can come across as pretty condescending and patronising. Of *course* I\u2019ve 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\u2026 I know we\u2019ve all felt like this, especially if we\u2019ve all had to deal with some form of technical support on the phone. I\u2019m thinking of a few well-known ISP\u2019s who do this…<\/p>\n

\"\"<\/a><\/p>\n

Better way – ask them what they\u2019ve tried…and be prepared to sometimes be stunned by the lengths some users have gone to! You\u2019ll be surprised \u2013 I know sysadmins like to slag off about users, but honestly they\u2019re 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\u2019ll get the few who haven\u2019t tried anything, but I\u2019m 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 \u2013 you may not want a user to restart their machine because you might want to see it while it\u2019s in it\u2019s broken state. Often restarting masks what the actual problem is!<\/p>\n

Asking them this question makes them feel like a) they\u2019re involved b) you\u2019re not patronising them and c) you\u2019re not acting as if they\u2019re a technical idiot. It makes them feel that you\u2019re speaking to<\/strong> them rather than speaking down to them.<\/p>\n

Are you SURE…<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

We do this all the time. We call doubt on whether our users have done something that we\u2019ve asked them to do. We make users feel like recalcitrant children who didn\u2019t do their homework, even if they have gone through all the steps we\u2019ve 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\u2019ve rebooted your PC right?!) but even still, calling them on it just seems petty<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

Instead, we should be asking them to try again \u2013 because maybe the first time didn’t work. Sure, if they\u2019ve already done it, we\u2019re repeating steps. But sometimes they may not have done it right or worse – they may have said they\u2019d done it, because they were embarrassed to ask how<\/strong>. Show them. Walk them through it. Make them feel like they\u2019re 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\u2019t make them feel stupid, make them feel like they\u2019re learning something.<\/p>\n

I can’t do it if it’s not in a ticket<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

How many of you have a rule that if it\u2019s not in a ticket it doesn\u2019t get done? Well, if you don\u2019t, 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 \u2013 how often it comes in, how many requests that person puts in, whether it\u2019s 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 \u201cNo ticket, no help\u201d really isn\u2019t benefiting anyone.<\/p>\n

\"\"<\/a><\/p>\n

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\u2019re there, go through the steps of creating the ticket with them. If you\u2019re on the phone, log the ticket yourself, asking all the questions that are usually requested in the ticket. If you\u2019re with the user, get them to log in and walk them through the process. I guarantee, you\u2019ll only need to do this a few times before they realise that doing it themselves before<\/strong> contacting you is a much better use of both their time and your time! Also, if something is urgent, often you\u2019ll want that email as a reference – that way, when someone asks what you\u2019re 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.<\/p>\n

Don’t give your password to anyone<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

This is one I harp on a bit and I\u2019ve harped on it online and in talks and at work and to family and to friends and to strangers… We don\u2019t give out passwords. Ever. To anyone. You just don\u2019t. The problem is, we\u2019re not good at explaining the *why* behind this one, which means a lot of users think it\u2019s 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\u2019t about making our jobs easier – because if we\u2019re 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…<\/p>\n

\"\"<\/a><\/p>\n

In place of doing the blanket warning of \u201cDon\u2019t give you password out\u201d, explain why. Tell them that if they do, the person they\u2019re 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\u2019t. Or worse (and this one really seems to get people’s attention) \u2013 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\u2019t care about their online identities, I’m damn sure they\u2019ll care about their cash! And this goes for us to \u2013 don\u2019t ever EVER ask for a users password. I still remember this happening in my first job and it gives me shivers thinking about it.<\/p>\n

You don’t need admin rights…<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

I\u2019m a hard arse when it comes to this. If any of you have been to my \u201cRighting the Right Rights\u201d talk<\/a>, you\u2019ll know that I\u2019m big on preaching a separation of admin accounts (if you\u2019re a DA, you get FOUR accounts!) so I know I\u2019m even guilty of this one.
\n\u201cNo, you don\u2019t need admin rights\u201d *slap*
\nThis is a bit harsh…and I definitely should phrase this better.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

Instead of saying they don\u2019t need admin rights because chances are, if they\u2019re coming to you, they think they do need it \u2013 why else would they be braving your wrath? Find out what access they believe they need. They might surprise you \u2013 they might need some delegation on their account or they might actually need an admin account to do what they\u2019re needing to do! Remember, when I say that everyone gets admin rights (see the glorious Oprah picture above!), it doesn\u2019t necessarily mean top-level access.<\/p>\n

Remember, we can delegate access to what\u2019s required \u2013 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\u2019re responsible for. We can delegate access to OU\u2019s, to individual GPO\u2019s. We have LAPS and the ability to randomize passwords. We have the ability, via GPO\u2019s, 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\u2019t be admins on your workstations! If you\u2019re interested in any of this, hit me up on Twitter<\/a> \u2013 more than happy to go into further detail about this stuff!<\/p>\n

You can’t access the internet on that!<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

This one is usually aimed at developers. This is where they want to do something and sysadmins are like \u201cHELL NO!\u201d – 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\u2019s very rarely actually needed. It\u2019d be nice, sure \u2013 but it\u2019s not needed<\/strong>. The internet is a hive of scum and villainy, it\u2019s where dangers lurk and where the bad things come from.<\/p>\n

However, it\u2019s often not that clear-cut and we could be a little bit more lenient \u2013 after all, there\u2019s no point having security in place if it hinders the job the person is trying to do, so…<\/p>\n

\"\"<\/a><\/p>\n

Let\u2019s find out what it is they\u2019re actually trying to access. It might just be a single site. It could just be a handful of IP\u2019s. In those kind of scenarios, it\u2019s a very small risk profile that we\u2019d probably allow. So instead of jumping off the deep end, let\u2019s find out what they\u2019re actually trying to access. Remember, there is the hardline approach of no default internet access \u2013 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!<\/p>\n

It’s not broken for me!<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

There is nothing that frustrates a user more than being told that what they\u2019re 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\u2019s not working. Just because it\u2019s working for you doesn\u2019t necessarily mean it\u2019s 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\u2019s broken and they\u2019re relaying to you the wrong part.<\/p>\n

\"\"<\/a><\/p>\n

Show them that you understand that while it might be working for you, they\u2019re obviously seeing something different. Walk it through with them. Find out what it is they\u2019re doing. They might be doing things a slightly different way to the way you would, throwing a spanner in the works that\u2019s 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 \u2013 like that they\u2019re using wireless instead of wired. Be patient and really listen!<\/p>\n

For developers, this is a good reason to use either VM\u2019s, 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\u2019t expect us sysadmins to help clean it up!<\/p>\n

We can’t throw (insert hardware) at it!<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

Another one for developers and this seems to pop up quite often – \u201cJust throw more RAM at it, it\u2019ll work\u201d. \u201cJust give it more bandwidth, I\u2019m sure it\u2019ll go faster\u201d. That\u2019s often not how it works. And that won\u2019t fix the problem, just mask it. We know that throwing more hardware isn\u2019t going to fix the problem and will often end up costing the customer a ton of cash that they wouldn\u2019t need to…but we still have to understand that they\u2019re the customer and they\u2019re asking us to do something, so we have to come to some kind of understanding: a middle ground.<\/p>\n

\"\"<\/a><\/p>\n

There\u2019s obviously some kind of bottleneck that\u2019s 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 <\/strong> 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\u2019d 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<\/a> helped me out with this!), he calls this the \u201cscale up or scale out\u201d approach. If throwing more hardware at it works, then get beefier servers. If it won\u2019t? Then scale out and look at running on multiple. This is where the cloud can be useful!<\/p>\n

The internet isn’t down…<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

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\u2019s not the magical \u201cinternet\u201d – because for a large number of us, there\u2019s any number of firewalls, switches, servers and proxies between us and the outside world. If you\u2019re not in that bucket, lucky you!<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

Obviously they\u2019re seeing an issue. Something is broken and, for want of a better word, they\u2019ve decided the \u201cinternet\u201d is going to be their fall guy. Sure, the internet isn\u2019t the real cause, but you saying \u201cIt\u2019s not the internet\u201d isn\u2019t going to help you *or* them. Get them to try accessing both an internal and external site. Often \u201cthe internet\u201d is code for \u201csomething on the network\u201d. It could be they can\u2019t access their email… or one of the file servers isn\u2019t letting them access their files… or the intranet website is down. Explain calmly that they\u2019re having issues and you believe what they\u2019re having issues with is [insert thing here] and that you\u2019ll investigate. Don\u2019t be patronising, they\u2019ll definitely pick up on that!<\/p>\n

Did you have it backed up?<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

Ah the joy of 20-20 hindsight. Everyone says they\u2019d implement backups *after* they\u2019ve been through some of major disaster or outage…it\u2019s just a shame more don\u2019t think of it *before* disaster strikes. Chances are, the user *thought* they had it backed up when they really didn\u2019t. Shoveling on blame now isn\u2019t going to help anyone, so it\u2019s best to help as much as possible…<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

…and the best way to do that is to start by helping the user set the backups up so that it doesn\u2019t happen again. This also goes for us admins – because we often don\u2019t back up all the stuff *we* need to. If you\u2019re 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!<\/p>\n

We need to do…<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

Now, onto a few things we tend to tell our own managers and this one is probably the most common \u2013 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.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

My learnings, so far, is that managers tend to deal better if you give them the benefits up front. Doing means X we\u2019ll save $Y. Doing X means an increase of Y% productivity. Numbers are always good. Sometimes you can\u2019t give numbers, often it\u2019s a new feature which will help the business. Tie it back to any business strategies or goals and you\u2019re laughing.<\/p>\n

Key words here? \u201cBusiness Requirements\u201d. Remember, there\u2019s no point doing something if it doesn\u2019t serve the business in some way.<\/p>\n

I need training on…<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

Similar to the last one, saying \u201cI need…\u201d doesn\u2019t get you very far. They just hear \u201cI\u201d and tune out. Sure, it might be true that you do need training on a specific tool or technology, but again \u2013 there needs to be a benefit to the business. And selling yourself isn\u2019t always the best way.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

Note the skills gap. Allow them to delegate the best person for it. Sure, it could be you \u2013 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 \u2013 there\u2019s no point in you being the person trained up on everything, unless you\u2019re 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!<\/p>\n

What do you want me to DO?<\/strong><\/h3>\n

\"\"<\/a><\/p>\n

This is the big one \u2013 from users, to clients, to managers, to executives. As sysadmins we\u2019re pulled in multiple directions and it\u2019s easy to fling up your hands with a \u201cWell, what do you want me to do?!\u201d statement.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

The biggest issue with this is that it\u2019s often not helpful. Our managers may tell us to do one thing, or users might want us to do another. Because you\u2019re asking the wrong question<\/strong>. It\u2019s not what you should be doing. It\u2019s what *THEY\u2019RE* 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 \u2013 there\u2019s a reason we\u2019re SME\u2019s, people!<\/p>\n

Always be wary of people who come to you with solutions instead of problems. Make sure you know what problem they\u2019re 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 \u201cBusiness Requirements\u201d again. Everything – even the smallest thing you’re doing – needs to serve the business in some way!<\/p>\n

\n

Now some stats, courtesy of CBT Nuggets<\/a> \u2013 sorry, less amusing than memes, but a tad more useful! These are a few extra pieces of information, especially around dealing with end users:<\/p>\n