Years ago, a friend's parents told me a story of when they decided that he could and should start taking responsibility for his own decisions. At the end of winter break, they decided to let him make the call of when to leave for the airport for the plane back to Boston. They asked him what time to leave, and, when he named a time, they knew it was too late. However, they didn't say anything. He missed his plane, of course, and had to work with the airline to get back to Boston.
I mentioned this to him later (they told me the story in his absence), and his response was, "You're kidding! I honestly thought the plane was an hour later! I wish they'd at least said something about the time so that I could have known. That really pisses me off."
To a large extent, I know how he feels. Somehow, geeks often expect their leaders to know about things and act upon them, but they haven't told us the time of departure. Likewise, users will sit on a problem for a long time and expect geeks to fix it. Their (usually irate) conversation goes something like this:
User: As you know, this has been a problem for a while.
Geek: Uh... I'm sorry; I didn't know. For how long has it been a problem?
User: Since I called you six months ago and told you about it.
Geek: I'm sorry; I thought we resolved it at the time.
User: Well, you fixed it for me that once, but it keeps happening, and I'm just at the end of my rope!! Why are you so incompetent!?!?
At this point, the geek gets off the phone and drinks heavil--er, fixes or escalates the problem appropriately.
Geeks and leaders of geeks aren't mind readers, and we're not perfect. Sometimes, especially if things have been stressful, we completely forget to follow up on a problem or assume it's fixed. That problem was one of 40 or so that the geek heard or found and fixed that day. (That's not an excuse, but it is an explanation.)
Leaders are often treated similarly to the geek above. Maybe I forgot to return your phone call when the systems crashed. Maybe I didn't get back to you about that great project idea you had. Please tell me. Please remind me. I'm sorry if I dropped the ball, but I can't fix something if I don't know it's broken.
By giving me information, you help me to know the following:
- The problem still exists.
- The problem is important to you.
- I need to either take or facilitate action to resolve the problem.
Posts
13 comments:
Jenn -
Is this an information problem or a communications problems. (or am I drawing a false distinction.)
I think most organizations do not focus enough on how complaints are handled, where the information is kept and how the other side can find out if the problem is fixed.
Since I was often the caller on the other end of the hotline. I understand the frustration with things not getting done and lingering problems.
How about going helpline 2.0? Open up the call logging information to a larger audience. Let everyone see the current status of the open issues and the list of continuing problems. Let the users help manage the process.
Too often people think their complaints go into a black hole. How can I check on the status of my reported problem? Often I cannot. I know I logged the problem, but I don't know what happens after that.
I think there is more to this than just the help line example. The classic is the "information" that fills the void when management doesn't say something -- such as during a "quiet period" or during heavy negotiations around a merger. Management may be in the thick of things and think they have communicated properly, but the people on the edges don't know what is happening. They are either blissfully unaware (Merck is buying S-P, announced today!) or they are nervous and grasp at every rumor and story.
Why wouldn't the "geek" follow up with the user at some point after the fix to make certain everything is running smoothly and hasn't repeated?
Currently, on Boston radio there's an ad for a painting contractor that makes a great point about the contractor calling the customer after the job is complete to be certain everything met with the customer's expectation and satisfaction. It's a great way to avert dissatisfaction and bad word-of-mouth. Even if the issue isn't fixed correctly the 1st time, the pro-active follow-up more than makes up for the issue being unresolved (or, being re-introduced). Much better than the contractor "blaming" the customer for not calling when a problem arises.
My comment is more directed to Joe. The amount of houses that the painter paints is fairly small (and generally logged).
The amount of help requests (big and small) that the average geek deals with is a LOT larger (and not always logged).
Phone calls and "hey, I've been meaning to tell you" don't always come at times when you can pay strict attention to the person/problem.
It's not just the geek that is failing to communicate, it's the none-geek as well. Of course the non-geek blames the geek since "all" the geek has to do is make sure that everything runs correctly.
Kathy - It's true that the painter has fewer jobs than the "geek," but using the excuse that the computer issues aren't logged is a poor excuse for not following up. Not logging the issue is a problem in and of itself.
I worked at a company where the best IT Manager I've ever worked with made sure that every time one of his people resolved an issue for someone, they followed up to be sure that the user was satisfied. That's the difference between doing a great job and doing a competent job.
Of course, it's also the user that's not communicating to the geek, but who's being measured on whether the user's tech needs are being met?
I definitely appreciate the discussion about the geek and follow-up.
However, it's actually immaterial for the example (which is why, because I try to keep my posts shorter, I didn't say anything about it). Let's say the geek did follow up later that day or the next day. The user hadn't had the problem again, so the ticket was completely closed, and the issue assumed resolved.
I find that, even with follow-up, users somehow still expect IT to know about a problem magically. How the issue is communicated is immaterial; it's that the information must be shared in order for everyone to operate effectively.
Jenn - That does make a difference. And not to quibble, but something in your comment jumped out at me. You said, "Let's say the geek did follow up ... and the issue assumed resolved." Perhaps you didn't intend to say "assumed," but in my experience, often that's the crux of the problem. Sometimes if the user doesn't report the problem as having re-occurred, the tech "assumes" that the issue is resolved.
Joe,
I understand your quibble with the word "assumed," but the use was appropriate. The geek assumed the issue was resolved BECAUSE the follow-up confirmed that the user was no longer having the problem. However, that was clearly not the case, but the information that the problem recurred was never conveyed to the geek.
If the user doesn't report the problem as recurring, OF COURSE we assume it's gone. I'm completely unclear as to how we would know otherwise...
Jenn - First, I want to be clear that it is the user's responsibility to report a newly arisen, or recurring problem that had been previously resolved. But, in the interest of this discussion, let me go back to my painting contractor analogy.
If the contractor did their follow up before the paint dried, and received good feedback from the customer, the contractor may "assume" that everything is OK, and "close the ticket." I'd argue that the follow up was too soon, as imperfections may nor reveal themselves until the paint dries. The same can be true if the follow up process in an IT situation isn't timed correctly, for instance. The process around the follow up isn't necessarily as simple as saying, "is that problem resolved," as the user may not be sufficiently knowledgeable to answer properly. Much like when a client asks a lawyer to perform a service for him/her. It's not the lawyer's job to simply perform the service, but be knowledgeable enough to ask the right questions to be certain that what the client is asking for is what he/she needs.
Joe and Jenn -
I think you are both identifying (and exemplifying) the same problem: the failure to communicate.
And I don't think the painting analogy works. That is a long term project with lots of interaction and money. Help desk projects are usually very short.
As I tried to point out earlier, it is not just following up with a phone call. There is just not enough time in the day.
You need to log the calls and open the log to the user community. Let them see what problems they have reported and what the status is on resolving those problems.
I am less likely to report a problem if I think the message ends up in a black hole. I do not remember who I complained to about my problem (more than likely, I was just yelling at myself.)
I am not going to bother calling about the email if there are already 10+ (100+) logs about email being down.
I prefer to look at online merchants to see what they are doing. I love that I can track my package through FedEx and see its journey, having some idea when it gets delivered. Why not do the same for it.
Open the Kimono!!
I'm with Doug on the "opening the Kimono" (in the way of transparency -- not in trying to be flashed by the geeks!)
We've been asked to streamline the technology processes over the past 10+ years by centralizing help desks, tracking calls, and creating knowledge bases within the geek departments. But, the streamlining takes away what used to be a face-to-face communication between the user and the geek. So, 10 years ago, I knew that a problem was resolved because the geek told me to my face it was resolve. If it broke later, I called that particular geek and said "Get Back Here and Fix it!"
Now, we get a form email letter that says "the problem has been resolved." And, in a way the user is told that if something breaks later, then they have to start the process all over again by calling the central help desk, and submitting a new ticket for the problem... blah, blah, blah.
This has a chilling effect on people, and they tend to find work arounds until they have to contact the central help desk again.
I think Doug's point of being able to really track what's going on would help the end user better understand the centralization process without feeling that the request is going into some black hole somewhere.
We'll never get back to the personal friendship we once had with our geeks, so now is the time to create a transparent, easy to follow system that creates some type of virtual friendship between the user and the geek.
I agree that the painting analogy is faulty, I only used it because it's what reminded me of the importance of follow-up. If that follow-up is online and is open to the user, as Doug suggests, that's great.
I am with Greg.
Its about creating connections. I never knew who I was talking to when I called the help desk. I never remembered who helped me or who to contact for the same problem.
Transparency is good. (In the open communications way, not in the naked geek way).
Post a Comment