A Little Empathy

  • Comments posted to this topic are about the item A Little Empathy

  • Indeed, I have also learned that "just asking a business person to tell me what to do often results in neither of us being successful."

    Just had a situation where they have two reports: one that can filter by branch, but does not show the balance on each result; and another that only shows results with balances, but cannot filter by branch.

    An accounting person emailed me to add the balance column to the first report, so she could eyeball the branch results to see which needed followup because they had balances. "Unless…you have a better way?"

    I replied that it "would probably be more effective to" add the branch filter to the second report, because she would then get just the records that needed followup at the desired branch.

    (I also estimated fewer hours to program it that way, but made it clear that I was still willing to do it as requested.)

    She said "That would be awesome!" Win-win:)

  • Hi Steve,

    Yes you are right - technology does not exist in a vacuum.

    I think that people in general would rather not ask for help - so actually sometimes ask too late maybe with a hint of desperation. So if you are solving a problem that you think they could have done alone, it's well worth investing the extra time and effort in helping the person understand. So they can sort themselves out next time.

    Most people like to feel more in control - with a side benefit that they thought they had received good service.

  • Boy, this article is dead on. I too reacted poorly to things early in my career. I sometimes receive requests where the only reason for it appears to be for the requester to make the request. There's no clarity as to what they actually want and the only purpose for it is to consume my time. I've learned over time to react better and to ask "What is it that you're trying to accomplish here?" This gets them to really think about what they're after and usually results in a request that's completely different than the original and actually does make sense. In fact, getting people to think about what they want to accomplish has become a regular part of my job. Through this, I've actually been able to get to the point where I've completely automated a process that the original request was designed to only make a manual process easier.

    I've also learned to temper my responses and not react to this type of request so poorly. Maybe that comes as a result of experience, age or both. Either way, it does reduce stress.

  • Best IT advice I ever got from my boss in my first IT position. He said something to the effect of: "When someone asks for help, most of the time they're frustrated and upset because they can't get their job done. You MUST remain polite and professional and have a can-do attitude."

    It's served me well. I always joke around with people that IT can never win. Users come to us saying "I can't get my work done!! Fix it!!" When we fix it, they say "Aww, man, I have to go back to work now?"

    Hardware is *always* fixable - if worse comes to worst you just replace the hardware. Data is a different question entirely. Retrieving lost data is a question of the quality of your backups and/or recovery hardware/software. Microsoft Office and most other software is mostly a combination of Google, "fiddle 'til it works" and where-did-they-hide-that-stupid-menu-item?

    Good tech professionals - particularly those who have come from a support background - are very good at process. You have to listen to the user, ask good questions to really understand the issue, then methodically work the problem until solved. There's really not much difference whether the issue is a busted hard drive or addressing a business need. Addressing business needs typically involves more people and many additional factors, but overall the means of resolving it is the same.

    When it comes to business needs, most users tend to have a semi-solution already in mind: "Can we build a database to do X?" or "How can we get Y software to do Z?". Those are the times I like to back people up and ask, "Setting technology aside for a moment, what exactly are you trying to accomplish?" We had a situation this past year where management was all fired up and ready to make a huge change and asked my opinion about it. I looked at them and said, "The current paper-based system is far more efficient" and then spelled out why. I did mention we could tweak the current process to make it a bit simpler and achieve basically the same end far cheaper than what they had in mind.

    This is the kind of thing you CANNOT learn in a classroom. Very rarely someone comes along who understands it instinctively. Most of the time either you have a mentor teach it/model it for you or you learn it the hard way as you go.

    (Plus what Ed said).

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

  • Steve - I don't think I get the last sentence "just asking a business person to tell me what to do often results in neither of us being successful." Could you elaborate more?

  • Very interesting editorial and responses.

    One thing I've learned to do over the years it to adjust a user's perception about what they can ask for. Often I run into people saying "Well, I wasn't sure what was possible so I asked for X..." where X is usually some basic solution that is much less than what could be implemented for them.

    I like to say to people that it's not their job to think about what is and isn't possible, that's my job. Their job is to come up to me and say "I need to fly to the moon!" and then I figure out whether it can be done, how it can be done, what could be done instead etc.

    If people limit themselves with what they ask based on their own fears and lack of knowledge then it can lead to sub-par solutions.

    Of course, the techy hardware guys hate it when I tell them I need to fly to the moon, but whatever 🙂

  • In my experience people voice problems when they are frustrated about them. It doesn't matter that they may not understand or be off in their evaluation or interpretation of a problem, it is still frustrating. Even if I can prove them wrong, I try to see things through their eyes and see if I can eliminate the frustration. Sometimes it is just an explanation that helps, sometimes offering possible solutions, sometimes just fixing the software to work better or more intuitively.

  • Remember that when you talk to someone you will get a whole lot more communication then the initial ticket.

  • Michael Lysons (1/15/2015)


    I like to say to people that it's not their job to think about what is and isn't possible, that's my job. Their job is to come up to me and say "I need to fly to the moon!" and then I figure out whether it can be done, how it can be done, what could be done instead etc.

    If people limit themselves with what they ask based on their own fears and lack of knowledge then it can lead to sub-par solutions.

    Of course, the techy hardware guys hate it when I tell them I need to fly to the moon, but whatever 🙂

    You're completely right.

    So often, instead of being asked "I need to fly to the moon!", I get told "I need a catapult that will land me on the top of Mt Everest, and then I need a giant trampoline on the mountain that will bounce me towards the moon, and then I need a giant net on the moon to land in."

    Though of course the initial ask is "I need a catapult".

    Leonard
    Madison, WI

  • Wait... So it's not us against the end users? I'm going to need some time to mull that over... 😀

  • I got cans of empathy, bushels of empathy, warehouses of empathy.

    However, I'm not your doormat, you still need to learn how to use Excel on your own...

    :crazy:

  • isaacchk (1/15/2015)


    Steve - I don't think I get the last sentence "just asking a business person to tell me what to do often results in neither of us being successful." Could you elaborate more?

    I've had people say things like "I need you to add a widget for choosing xx" to a form/page. Say, let's add a checkbox to the form that lets me choose if I want to show inactive orders. However that's not the problem, and once I add the checkbox, they come back to say that the form doesn't give them the info, or they were really looking for a way to find old orders for a customer. That might be a new form, or a change to a process.

    What I've found is that users don't often view an application as I do, and when they ask for a specific item, it's because they have a task they need. They think the specific item meets it, but because they don't understand the application, it doesn't work.

    It's the same for me as a developer. I think that I'm managing process x, so I build an application. However the user really needs to do x+y, and so my app falls short. Poor requirements? Maybe. Poor communication? Certainly. However I think it's more that we too often don't speak the same language, or have the same frame of reference. If I embed myself in the business a bit more and learn what they need, I usually build something better.

  • I'm finding that business people don't have all the answers to ITs questions. "What are your requirements?" elicited an unusually frank conversation from an extremely successful career woman.

    "I can't tell you exactly but what I do want is an environment where I can do small and rapid experiments. We have ideas that might be good, they might be bad, we can't tell which is which so we need to try them. We accept that we can learn a lot from failure and we accept that what can be delivered at speed won't be bullet proof. For rapid experimentation I am prepared to accept all that. Is what I want feasible and how can I help you to achieve it.

    If you ever meet a business stakeholder like this look after them. Help them realise their dreams. If you come up with a good idea of your own then they will quickly see how it helps both the business and them and they will support you. I thought such people were "rainbow unicorns" but I've come across 2 or 3.

    For those of you who get annoyed when asked for help then think when you last called some sort of help line or customer service rep. Chances are your blood was boiling long before you picked up the phone and that was none of their fault. They probably work for a call centre subcontracted out by the company you are trying to call. I cringe with embarrassment knowing that I have picked up the phone and been a belligerent git either making a phone call or taking a phone call.

    On occasion I have had unusually courteous and/or competent treatment. My place of work has a mechanism for recognising such behaviour. Outside of work for some service I go to the extreme of putting pen to paper. I have seen what happens when an employee gets a letter that says "Thank you, you really helped me out". I think we should say thank you a lot more. I also think we should "walk a mile in another man's shoes".

  • What I've found is that users don't often view an application as I do, and when they ask for a specific item, it's because they have a task they need. They think the specific item meets it, but because they don't understand the application, it doesn't work.

    Early in my career, I had a customer who needed a database to do budget-tracking but insisted that he wanted an Excel workbook. In particular, he wanted a "master list" in Excel (Really, he wanted a SINGLE table). I could not convince him that the correct solution was a relational database. I would describe everything the database and its front-end would do (the whole thing was in MS Access), and he agreed on the features. When I told him it was a database, though, he didn't want that--it HAD to have a "master list." Eventually, I assured him that it did have a "master list" in Excel even though it was all MS Access. He was very happy with the final product and never understood what it really was, and, in truth, he didn't need to understand it.

Viewing 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic. Login to reply