Category Archives: Pals

How to not fail at support

Support is a really neglected part of a lot of development jobs. You want to just keep writing code and making releases. It’s easy to get into the code and forget that the users are the reason you get paid to write it! If you find you’re doing your best and solving problems, but don’t seem to get the credit or positive results to show it, this might help you. Also, the title is “How to not fail at support” – because this is not about solving the problem or techniques for doing the fix – this is about how to not lose the encounter even when you solve the problem.

All Code has Bugs

You’re going to have them. Nothing is perfect. Your plan for any software has to include support or you’re gonna have a bad day.

Why people get angry at you when you are trying to help them

People need help and when people need help they are vulnerable. They are trying to do something and it is important to their ability to succeed at their job. If they don’t need it to succeed at their job, they won’t bother you about it. If they do need help, they want it as soon as possible and they want to get back to doing their work.

H.A.R.E.M solves the problem

The best way method I’ve found to keep sane and make sure every user is happy with support is to follow the H.A.R.E.M method. There is no silver bullet for software development, but there is definitely a silver bullet for handling human beings who need support without them getting angry about it.

It sounds stupid simple, because it is. Doing it is harder than understanding it.

  • Hear the request
  • Acknowledge the request
  • Restate the request
  • Estimate how long until you will get back to them.
  • Meet or beat your estimate.

That’s it! It handles the customer service part perfectly. Do this and all you have to do is go find that race condition that disappears when a debugger is running!

Hear the Request

You need to have someone actually monitoring incoming support requests. This is harder than it sounds. Not hearing the request is a terrible problem – because they’ve reported an issue and no one is actually working on it.

If you don’t have a clear, easy dedicated, and monitored pipe for users to tell you about their problems, you need to fix that immediately. When someone doesn’t know where to go for help or when they go for support and no one looks at the queue, you have a big problem. Your users will hate you, and you’ll deserve it. If you’ve ever called for help and it hasn’t arrived, you understand the feeling of betrayal and hopelessness that you are associating with your labor.

Poor software with excellent support is a better deal for users than good software with no support. We know, because they actually use poor software with excellent support more.

Think through the experience of asking for help. You are trying to get help. It’s bad enough so that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. If you don’t know where to go to reliably get help, you will feel despair and anger.

Acknowledge the request

If someone tries to get support but they feel like they are shouting into the darkness, that’s the same as if they aren’t getting support. One of the big reasons people call instead of entering a ticket is that people don’t know if the ticket is getting looked at. If someone is calling, they know that a person has heard them.

Think yourself through the experience of asking for help. You are trying to get help. It’s bad enough that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. You ask for the support and hear nothing. You will feel anxiety until you know that someone has heard you. You’ll “check in on them.” You’ll call to follow-up. You’ll do anything to make sure that someone is actually going to work on your problem.

When you acknowledge the request – you just say “I heard you and I’m working on the problem.” That is such a soothing thing to hear. Someone knows the house is on fire and help is coming!

This is super important!

  1. Users can chill out and go work on other things until you solve the problem
  2. If people know that submitting an email or ticket online gets acknowledged, then they can do that without tying up someone on the phone.

A script

“Hi Allie, I saw your ticket and we’re re-imprinting Asimov’s three rules on the floor robot’s positronic brain.”

“Hi Bob, I saw your message. I’ve unlocked your account for you and you can reset your password at the help portal. Happy to help, let me know if you’ve got any more issues with it.”

“Hi Carla, I saw your request. You’ve hit the hard drive limits under our policy.  I’m attaching a quick guide to how to slim your hard drive footprint that other folks have found helpful. If that doesn’t work we can send a note to your manager and the CTO to see if they will approve an exception.”

Restate the request

Support requests are difficult. Don’t work on the wrong one. I’ve spent hours troubleshooting the wrong problem because I didn’t understand what they were trying to tell me. This waste is a waste of your time and the poor person who is waiting for you to fix their problem. They don’t care about the time you just spent and how hard you worked. No one benefits.

Always. Restate. The. Requests.

It sounds stupid. It sounds awkward. Do it anyway. It’s a “check for understanding“. In conversation you can just say “I want to make sure I’ve got this right, so let me restate what you’ve told me.” That language usually helps them understand why you insist on saying back to them what they said to you.

Think yourself through the experience of asking for help. You are trying to get help. It’s bad enough that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. You ask for the support and hear that someone will help. Relief.. Then they tell you the house isn’t on fire – but you are seeing the flames! Or they say they’ve fixed the water leak, but you are seeing a waterfall in your bedroom. Are they insane or incompetent or lazy or lying? You will feel angry, frustrated or betrayed.

A script

“Hi Allie, I saw your request – I just to make sure I understand. You’re saying the floor robots are ignoring Asimov’s 3rd Law – that they are killing themselves out of boredom?”

“OH MY. Sorry, you’re saying that they are ignoring Asimov’s 1st Law and killing everyone on the floor out of boredom! I’ll send Will Smith over immediately. Please shelter somewhere safe.”

“Hi Carla, I saw your request to increase your hard drive size – you’re telling me that you have to use a program that only works with large files on your primary drive. You’ve hit the hard drive limits under our policy.  I’m attaching a quick guide to how to slim your hard drive footprint that other folks have found helpful. If that doesn’t work we can send a note to your manager and the CTO to see if they will approve an exception.”

Estimate how long until you will get back to them.

A key metric for user satisfaction is “First Call Resolution”. FCR makes people happy. For phone calls that means getting solved during a conversation. For emails and tickets, that means someone resolves the issue within 1 hour of the request coming in and while in the first response to the request. Yay – those are automatic wins!

But there are plenty of issues that are bigger than a single call or take more time. This is where real rancor and unhappiness can develop even if you are solving problems and doing everything else right.

Tell people how long until you will get back to them. This isn’t a guarantee that you’ll have the problem fixed – just a message of how long they should expect until you can update them. This is very important because it gives them a chance to make decisions and be empowered. Just telling them this lets them be less helpless.

If you think this reporting issue will take 1 hour, and someone has to be on the phone with a client in the next 20 minutes, they can decide to calculate the numbers themselves or to postpone the call. Letting someone know enough to seek other solutions is good for them.

An estimate is basically a promise to the user: You can bug me if I don’t come back to you before this time. If that isn’t soon enough you can seek other solutions. If it is ok, just relax and work on something else until I call you – I’ve got this.

A script

“Hi Zelda, I’m not sure why the delivery drones are returning to the warehouse without releasing the payload. Just to be clear – the address is correct, the payment is fulfilled and they order hasn’t been cancelled, but the drone just goes to the address, circles, and comes back with the package? This is tricky. I know you are under a time crunch. I’ll start looking at this and I’ll get back to you by 2pm with either a solution or I’ll let you know how much longer it will take me.”

Meet or beat your estimate.

When you make an estimate, you’ve made a promise. Keep your promises.

Don’t break your promises. Do what you say. Be clear. Meet or beat your estimate. That’s why your estimate includes a statement saying you might come back with another estimate. Do that if you think it might take longer than your original estimate. Better to keep the user in the loop and up to date than to have them know that they can’t trust you.

A script

“Hi Zelda – Just calling to check in with you. This is trickier than we thought. The GPS system connected to the drones doesn’t show the address! That’s something we are working with a vendor to correct, but it won’t be fixed by 2pm. I’ve asked them to keep us up to date and I’ll chase them. I’ll get back to you by 4pm with either good news or I’ll get you a better estimate.”


The reason this works is simple: it’s humane, it respects the needs of the person asking for help and it treats them with good manners. It won’t solve problems for you – you’ve still got to do that, but it will get rid of feedback that your people feel abandoned by your support team or that they don’t want to bother reporting issues.

Magical Clouds of Central Park

It’s a beautiful misty spring morning and I climb the stairs out of the Q train. I look up and see one of those magical New York sights. The clouds are hanging so low that I can see them actually flow through the trees of Central Park.

Beautiful low clouds flowing through Central Park
I’m struck still. This is so rare and beautiful.  I’ve got to share a picture of it with you. You need to see these low clouds hanging out in the park, slowly ambling by.

Of course, then I turn around and look behind me, because who can trust beauty to just be simple and perfect.
Clouds clearly coming out of a steam pipe in the road

It turns out what we do matters

Just a few things to note.

Across the street from me, the Macy’s is being renovated. The pace of change in the whole neighborhood is crazy, but the interior of the Macy’s is getting changed, they are tearing out and rebuilding the floors above the store, the parking garage catty-corner is getting torn down- it’s a lot.

And it’s loud. SO LOUD. The folks running the projects were doing demolition all through the night.

I’m on the board of our building so people asked me how to get this to stop. I had no clue. I just told them to call 311, report the noise repeatedly and lets see if our combined hectoring led to anything. Eventually, we posted a sample of text for folks to make it easier – they didn’t have to figure out what’s important to say, just read what we posted. Of course, I didn’t have much hope because who’s going to listen to some folks like us when there’s a big developer behind the renovation?

I was wrong. We got their night permit suspended. One of the reasons cited was the volume of calls from our building.

Our voices mattered.

Just like they did when we rejected the initial proposal for Ryan/TrumpCare. And they will keep mattering.  This is good, but it is also a responsibility. I grew up with a lot of cynicism about participation in the political system – lots of folks in my generation figured the game is rigged. So why play?

The game might be rigged, but you’re definitely fucked if you don’t play. If you fight you get some wins. That matters.

So now I’m more committed to doing my bit. I can’t do it all, but I can make some calls each day at lunch with I can join in and support groups like Tech Solidarity. I can donate cash to campaigns that need it. I can phone bank. I can text Resist Bot and send short messages to my government representatives. It’s NEVER been easier to have some effect.

And your voice and actions matter too, friend. It’s time to make yourself a schedule or an appointment of small sustainable things you can do every day. Please take 10 minutes today to think about what matters to you and come up with a small, easy to keep up with plan. Call me if you need any support. Please tell me about what you decided! Sharing your experience helps keep you energized! I will talk through it with you!