Happy New Year to all the regular readers!
Recently, I had a very interesting chat with a fellow IT leader; we discussed the efficiency of tier 1 technical support and how we usually try to achieve the optimal 80% efficiency mark (80% of the cases to be solved within self-service or the first help desk line). While common techniques are indeed… common (by seeking common denominators in root causes), when it comes to tier 2 and above, there were fewer obvious solutions. And that’s natural, given that complexity becomes a major factor and is implied by the higher tier. So what can leaders do to gain improvement in this area?
I did share one recommendation which works for well for me. It caught some attention therefore I’ll cover it briefly here. The method is called obtaining a minimal working example. It is mostly popular among software developers who are more likely to stumble across a block while working on a complex software project. What do? Involve more brains then, right? Well, of course, but who has the time to go through a litany of complex lines of code, while everyone has their own work to do? Especially if you consider sharing the problem with an open source community, you will need to come prepared. You’ll get no input if the question is presented in a way which might resemble “hey, do my work for me, would you”.
A minimal working example is a complete (ergo: working) piece of code which has to be well crafted before can be presented via collaboration tools to narrow down the scope and yet be able to present the issue. That is required to allow a group to investigate quickly and efficiently. Building an MWE is a method, but even more, it is an exercise for the author. The developer has to be able to collect only the required code, leaving the remainder out to avoid obscuring the root cause of the issue and slowing down the investigation. During the process of building the sample, this method requires considerable effort to be put into evaluation of every step and… yes, about 80% of these get resolved during the preparation of the MWE!
While it is certainly a trick software developers and their managers should consider, it is not limited to programming. System administrators can also benefit from this approach, especially when working on complex configuration files, sometimes including vast and compelx scripting. As tier 2 or 3 support teams gain the ability to build a minimalistic setup with the problem bit captured in it, they surely will also be much more competent and empowered to solve and prevent other technical issues. Naturally, they will also be very efficient when working with the vendor (if eventually required). Building an MWE is also encouraging team work through empathy – after all, the MWE is prepared for someone else to understand and gain insight.
So, that’s one method; please share what works best for you!