Working on an issue tracker for the past four years has taught me more than just how to build and maintain a piece of software. It’s taught me how to be diligent with my response to people’s problems.
Here’s what I mean. We get feedback – lots of it – from our customers. The feedback ranges from high praise to a rant about how we’ve done a great disservice to someone’s life. We get a lot of feedback from our internal team as well. Again, it can vary from “Great work on the new feature!” to “This reminds me of a sh*ttier version of ______.”
Credit for a job well done feels amazing. Detest for something you’ve labored over for years is demoralizing – even if someone just nitpicking a small part of your work. You take it personally because you’ve invested more than just your business-self in what you do.
A few years back, on a day where work wasn’t going so well, my good friend Ian once said to me that he “just wanted to be of use.” I could tell his words came from a very raw and genuinely vulnerable place. It opened my eyes to the fact that all people, at their core, want to feel of use. A simple reassurance that you are, indeed, serving a useful purpose for someone else’s life is sometimes all the fuel you need to keep going.
Fortunately, we get plenty of positive feedback from others. We respond to that person with equally kind words, and we go off our merry way. There’s actually not that much to think about when responding to good feedback.
Now, here’s someone that I’d categorize in the latter bucket. We received this email last week from a customer:
“I received 50+ emails from DoneDone. Needless to say UNSUBSCRIBE ME from your ‘service’. Go away and leave me alone.”
This email sucks. And, to be honest, it’s not even all that bad. Personally, I’ve had way worse feedback on work I was truly proud of, from people I actually knew.
So now what? Why was this person – we’ll call him Doug because I don’t know a real-life Doug personally, and it keeps the pain a little less real that way – so angry? Some people might initially hide away in fear, while others might initially write back in anger.
The key is, to do nothing with your initial feeling. Instead, I try to think through the problem from three different angles. After doing so, I can respond with the personal assurance that I’ve done my due diligence in thinking through the problem.
Angle 1: How do I perceive this problem?
The first question I’ll ask is “what is the actual problem?” In this case, I didn’t perceive any problem – the software was working as is. DoneDone sends you notification emails when things happen to issues you’re working on. If 50 things happen then 50 emails shall be sent. I queried the database and dug through email logs to make sure there wasn’t any actual technical problem. Nope. The emails went out properly, the data was right, everything was cool.
In fact, last summer we added a feature to disable all notifications on a project in DoneDone because some customers didn’t want the email bombardment when projects were “running hot.” And, Doug apparently hadn’t found that option yet. So, from my vantage point, there was no problem. DoneDone was working as it should.
Angle 2: How could Doug be perceiving this problem?
If I don’t think there was a problem, why did Doug think there was (and a big one at that)? Why was he yelling at DoneDone for doing exactly what it’s supposed to do?
I spent some more time querying timestamps in Doug’s account. The records showed that he was assigned to a bunch of issues in late March, and since then, nothing happened…until last week. Ah, now it’s making sense.
From Doug’s point of view, DoneDone was a service that briefly entered his life late last Spring, drifted off into the ether, and then came roaring back with a vengeance last week. When 50+ emails came in, DoneDone felt no different than a Viagra Ad. Forget that these emails were real people updating real things that should concern Doug. That’s clearly not how he perceived the situation.
Angle 3: Would Doug understand the problem from my vantage point?
The first question to answer is the most direct. The second requires a little deduction. The final one requires a little imagination. Knowing how I perceive the problem, and deducing how Doug perceives the problem, can I conjure up an educated guess as to whether Doug could see things from my viewpoint?
When several people complained about email overload a year ago, before we built the “unsubscribe from notifications” option, I had enough evidence to see that other people wouldn’t buy the response that this was not the original design of the system. So, ultimately, we realized this was a feature worth building in. In Doug’s case, would a little nudge to have him go into the application he clearly hates and find this option we built be something he’d be willing to accept?
Given what little I know about Doug other than he was very angry, and that the remedy is a rather simple one, I concluded my best approach was to offer the option and be apologetic. Doug had a bad experience with us, regardless of whether it was “technically correct” or not.
I’ve found the three angle approach to a problem works well in any situation where someone else is telling you why your actions have created a problem, be it through an anonymous email, a co-worker, or friend.
What exactly is a problem?
The first two questions help me define the problem. But, what exactly is a problem? If you think about it, there is no such thing as a problem in and of itself. A problem is the combined discrepancy between what is occurring compared to what each party thinks should be occurring. For instance, you could also think of a software bug as not a bug in and of itself. Instead, it’s the combined discrepancy between what the application does with what you – the programmer or the user – thinks it ought to do.
If the first two questions help me decide on the remediation (e.g. Is this something I should fix? Is this something they can help fix with me?), the third question informs me on how to frame my response. Do I need to be more explicit or more sympathetic? What do I need to say for them to see how I perceive the problem?
Realize that no matter how well you think you might have answered these questions, you still might not get the response you want back. The important thing is that you’ve done your due diligence and thought through the full problem as best you can.
As it turns out, Doug never read this email, because he replied back the next day chastising DoneDone again. Following the same three steps, I had to get more stern the next time around. I cut through the niceties and bold-texted exactly what he had to do. I even suggested he email his account owner to remove him from the account. Problem solved.
Or, at least he stopped yelling.
Sign up for a DoneDone account in 30 seconds. Want to read more by Ka Wai Cheung? Ka Wai’s new book on the modern-day programmer, The Developer’s Code, is available in eBook and print. You can follow him on Twitter @developerscode.