Engineering Support Beyond Do, Doc, Done

Posted On April 30, 2019

DoDocDone captures a way of working that is popular among support engineers and which often works well. For example : a case comes my way in the issue tracking system. I fix it (Do), send an email or write a comment when I close the case (Doc) and move on to something else (Done).

There’s nothing wrong with this reactive process, but it can be even more powerful when a touch of proactivity is added, in the form of a Double-check.

A recent conversation with Alex Growcoot crystalized my thoughts on this. Alex, for his sins, runs customer-focus workshops for ARM support. He’s done a lot of work to understand how customer support could be improved, mainly using feedback from ARM’s issue tracking system. In spite of the considerable data available from the system, it’s been surprisingly difficult to work out what could (systematically) be done better.

Engineers analysed dozens of cases where customers had said they were ‘extremely satisfied’. They found a number of common themes and, unsurprisingly, quality and speed of response were the most common contributors to satisfaction.

It seems that many customers are easily satisfied (bless their souls :-). If an ARM engineer makes their pain  go away, then they’re happy. Even if that engineer breaks multiple support guidelines – fails to ask basic questions, writes undecipherable emails, makes it hard to upload their testcase, etc. – then an easy-going customer may not care too much, provided the fix works.

However, we learnt more from the #2 satisfaction factor, which was that the support engineer had followed up to confirm that an issue was completely resolved. Hence, as shown by factor #1, DoDocDone (D3) generally works, but DoDocDouble-checkDone(D4) would be even better.

This is good news, since it’s challenging to systematically improve the quality or speed of support responses. On the other hand, it’s relatively easy to have support cases systematically closed with a Double-check that, for the customer, the issue is fully resolved.

Notice that this work did not take the obvious approach of looking at negative feedback in order to understand and correct the support process. This had been tried in the past, but it was found that lessons on how to improve processes are hard to spot in most « angry customer» cases. Many are caused by events beyond the support engineer’s control – earthquakes and email inadvertently going to into the Junk folder, for example. Most others are related to fiendishly difficult technical issues and a few are caused by, let’s say, psychological glitches on the part of one of the parties. Either way, it’s hard to imagine any process that could completely eliminate such problems.

So, Alex’s data clearly shows that going a little beyond D3 makes an important difference. An email or call to check that information and data has been received and understood is greatly appreciated. What’s more, there are other advantages for the support organisation, since the exchanges which result from this type of follow up may unearth information on customer preferences, projects and future needs.

Of course, implementing a D4 process has to take account of certain obstacles:

  • Time pressure: If support engineers feel that they are being measured only on the number of cases that they close each week, then D3 is the most logical way for them to go. Team leaders must therefore avoid such simplistic performance metrics.
  • Perfectionism linked to blame avoidance: Even if team leaders fully support Double-checking, many engineers have in-built ‘be perfect’ and ‘hurry-up’ drivers. This may be compounded, in some cases, by the wish to avoid blame – i.e. negative feedback from the issue tracking system. These factors may cause engineers to keep their heads down and execute the D3 process as quickly and perfectly as possible, even if they are encouraged to do otherwise!
  • A preference for solving clean, isolated problems: As explained in a previous article, the natural inclinations of most engineers, reinforced by their scientific training, is for solving isolated problems using analytical methods. This is easier to achieve with a D3 approach, since things often get more complex once extra customer feedback is obtained.

Once these obstacles are overcome, Alex and I believe that D4 takes significantly more time than D3 only in cases where there is a good reason for investing the extra time. And if there isn’t, then the most likely customer response is, “yes, it’s working great – thanks” … which is well worth the extra few seconds it took to make the Double-check!

Written by Andrew Betts

Consultant, trainer and coach specialising in client communication practices (inter- and intra-company). As a facilitator, I use training, coaching and mentoring in due measure. I enjoy developing original programs and creating new tools, and begin with the assumption that the people I meet are doing their best in complex circumstances. The rest depends on where they’re starting from and where they want to go. As a sales consultant, I strive to walk the talk, applying the values and beliefs that underpin my facilitation work to the techno-commercial domain. I agree with Frankl about the importance of meaning, and believe that this generally comes from work with and/or for others – human animals are wired that way! For myself, I’ve noticed that when I’m working towards the transmission of knowledge and skills, then I feel the greatest sense of fulfilment/flow. I am also rather attached to the Schutzian notion of truth as a fundamental enabler, and to Isaiah Berlin’s idea of plurality – the complex and unfortunately rather dull opposite of extremism – as a sensible approach to the problems of the world.

Related Posts

Adjusting Intentions when Leading a Difficult Conversation

My customer brings up supply chain issues again, just as they did last meeting and the one before, and for as long as I can remember now. As usual, this is done just when I’m getting to topics that are important to me and the question is accompanied by an agonized,...

read more

A Troll-Taming Loop for Reconciling a Difficult Exchange

"Happy families are all alike; every unhappy family is unhappy in its own way" (Leo Tolstoy, Anna Karenina, 1878). We posit that a key attribute of happy families, and effective people in general, is that they can bring Difficult Conversations to a satisfactory...

read more

Difficult Conversations, Bridges and Trolls

Trolls are trouble when you want to cross a bridge. Especially when the bridge in question is slippery and swaying.  They can takes ages to deal with and, of course, trolls present a health and safety hazard. A Difficult Conversation is like crossing a troll bridge. ...

read more