{"id":27346,"date":"2020-03-30T01:05:03","date_gmt":"2020-03-30T08:05:03","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=27346"},"modified":"2020-03-30T01:05:03","modified_gmt":"2020-03-30T08:05:03","slug":"helping-customers-effectively","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/helping-customers-effectively\/","title":{"rendered":"Helping Customers Effectively"},"content":{"rendered":"

I have to put a disclaimer here since this is not the usual type of blog posts I write. I\u2019m by no means a master at communication. This is just what I thought that seemed to work well. YMMV of course. But I\u2019d be very happy if they help you in some way \u2018cause many of us work with customers. And I welcome your thoughts and suggestions. <\/span><\/p>\n

I have talked to customers a lot since I started working on the GC. This is in the context of helping customers to handle and resolve issues they are seeing. <\/span><\/p>\n

1. The intention of helping should be genuine<\/span><\/strong><\/p>\n

I am naturally the kind of person who wants to help with coming up with a solution when I see a problematic situation. But an equally important reason in the professional context is that I think that it\u2019s actually a bit misleading to say \u201chelp customers\u201d \u2018cause it makes it sound like \u201cI\u2019m the giver and the customer is the receiver\u201d. In reality the end result of helping customers is largely to help ourselves \u2018cause we wouldn\u2019t be here if we didn\u2019t have customers \ud83d\ude00. If you think about this, the empathy for customers will come naturally and you will genuinely want to help.<\/span><\/p>\n

I\u2019m sure we all have had this experience \u2013 when you sense someone doesn\u2019t actually want to help you, it\u2019s never a pleasant experience.<\/span><\/p>\n

2. Respect others and assume the best intentions<\/span><\/strong><\/p>\n

Respect is a 2-way street so this is really a suggestion for all parties involved.<\/span><\/p>\n

I have definitely come across my share of customers who simply didn\u2019t make it easy for themselves to be helped. I\u2019ve worked with people who were hostile and\/or demeaning and\/or didn\u2019t care to make any effort to try any solutions and only continued to complain. But most folks I\u2019ve worked with were very reasonable. Some were so accommodating and that I\u2019m really grateful that I have customers like them. By default I always treat someone new I talk to with respect. And I never felt the need to change this default. I always assume that there\u2019s a good reason why they have or have not done something. <\/span><\/p>\n

When I ask someone for help, I\u2019m always appreciative \u2013 this doesn\u2019t just mean to say \u201cI appreciate your help\u201d, much more importantly, having a clear description of the issue and showing them what you have already tried shows that you have respect for their time. It makes people much less interested to help you when they need to pull the info out of you. We\u2019ve probably all seen the cases where someone is like \u201cIt\u2019s broken. Can you look at it?\u201d with no description of what they are doing, what version of the product they are using, whether they have collected dumps\/traces and whether they have done any analysis at all and when you ask them they give minimal answers. <\/span><\/p>\n

I\u2019m actually totally fine with it when people come to me but haven\u2019t done much investigation on their own, <\/span>as long as they are willing to do it if it helps to resolve the issue<\/span><\/em>. I understand that people have different experiences \u2013 there are hardcore perf folks who do memory analysis on a daily basis – honestly I\u2019m impressed with the level of investigation and understanding from some customers I\u2019ve worked with and deeply appreciative of them. And there are folks who just haven\u2019t had the need to learn about memory and that\u2019s fine (in a way this is a good sign \u2013 it means GC and our libraries work well enough that they don\u2019t need to care). Sometimes this actually shows a problem on our side – it may mean our doc is too hard to discover or our explanation is simply insufficient. Over the years I\u2019ve put in a lot of effort in improving the tooling and the documentation so it\u2019s easier for the customers to discover and diagnose problems on their own.<\/span><\/p>\n

If I have any doubts about the feasibility of my suggestions I would end the conversation with \u201cDoes this sound reasonable to you?\u201d which provides a clear opportunity for them to voice their concerns. I myself find that very helpful when other people say it to me so I\u2019d like to believe it\u2019s helpful when I say it to my customers.<\/span><\/p>\n

3. Understand the problem before suggesting solutions<\/span><\/strong><\/p>\n

This sounds obvious but you\u2019d be surprised how often people would jump ahead of themselves and talk about solutions without much understanding of the problem they are trying to solve. It\u2019s interesting \u2018cause I\u2019ve seen this on both sides. Some of us would start spelling out various solutions that <\/span>may<\/span><\/em> be useful or just enumerate solutions they\u2019ve tried and worked before; and some customers would want suggestions before they explain what the issues they are facing actually are.<\/span><\/p>\n

Understanding the problem often means getting data or sometimes even trying out a prototype in order to get data. And I completely understand that may not be feasible so there\u2019s definitely a time and place that calls for \u201chey, I\u2019ve worked on this for a while and have seen many cases, and here are the possible causes\/solutions you should try\u201d. But I\u2019ve definitely seen this happen way before it\u2019s concluded that\u2019s not feasible or without even thinking about the feasibility at all. <\/span><\/p>\n

When I request info from folks, I explain why I\u2019m requesting it, ie, what kind of things it would help me figure out so we can make forward progress. This helps with justifying the time they\u2019ll need to spend to get the info.<\/span><\/p>\n

4. Convey applicable information<\/span><\/strong> <\/span><\/p>\n

When I describe the solution\/workaround, I include 2 pieces of info – the diagnostics I did, in a way that’s relevant to the issue and the action items for the customer and\/or for us.<\/span> <\/span><\/p>\n

I\u2019ve seen devs write long emails that mentioned a lot of info when responding to an issue, yet it\u2019s not obvious how each piece of info is related to the issue at hand and more importantly, not obvious what the action items are. Most of the info may not be important for the customer to understand at all to resolve the issue and especially when folks are under time pressure (which means they are busier than usual), this doesn\u2019t exactly help with the situation.<\/span><\/p>\n

I have a coworker who does this exceptionally well \u2013 he would describe the root cause and the fix\/workaround at the beginning of his email in a concise yet informative way, and specifically say \u201cthe rest of the email is the details that you only need to go read if you are curious\u201d. And the rest of his email describes things in very much detail.<\/span><\/p>\n

–<\/span>—–<\/span><\/p>\n

Of course, as mentioned in the beginning, this is all in the context of helping to resolve issues. If you are helping customers in a different context, eg. \u201cI\u2019m writing a blog post to tell my customers some info about my product that they may not need in their daily work but just \u2018cause they are a curious bunch\u201d then of course some of this does not apply.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

I have to put a disclaimer here since this is not the usual type of blog posts I write. I\u2019m by no means a master at communication. This is just what I thought that seemed to work well. YMMV of course. But I\u2019d be very happy if they help you in some way \u2018cause many […]<\/p>\n","protected":false},"author":3542,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[],"class_list":["post-27346","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet"],"acf":[],"blog_post_summary":"

I have to put a disclaimer here since this is not the usual type of blog posts I write. I\u2019m by no means a master at communication. This is just what I thought that seemed to work well. YMMV of course. But I\u2019d be very happy if they help you in some way \u2018cause many […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/27346","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/3542"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=27346"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/27346\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=27346"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=27346"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=27346"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}