Something broke today at work. Again. Our content management system is a black box, one that has created a lot of buyer’s remorse for me. One of my Web developers fixed the problem but it was not clear how or why. He’s going to bird dog the issue for awhile but, at the end of the day, there is a limit to how much time to put into it. We had a solution, which meant we – and our customers – could move forward with our work. Since so many of the defects with this system are one-offs, it doesn’t make a lot of sense to understand the problems each one raises.
This reminded me of someone I once knew who was very much focused on the process. We were both doing front line tech support, fixing computers and helping staff when they had software or hardware questions. “Sparky” spent hours trying to diagnose the problem, sometimes with a successful end result but just as often without. Even when the information was something that was replicable, and that we could add to our knowledge store, it was often at the expense of significant downtime for a customer. It was during this time that we shifted from fixing hard drives to just quickly reimaging them and getting the customer back up and running as fast as possible. The myriad defects in the operating system and the hardware meant that, as each of our tech team got bogged down in a project, we would quickly eliminate all available resources.
It is a challenging balance to create. When faced with a problem, it is often valuable to understand the underlying causes. If a process has failed, it can be important for operational and accountability reasons to identify why and see if they can be remedied. In libraries and in many technology service environments, the understanding part is something of a luxury. The customer tends not to care about the why – they want something, whether research or their system, and the sooner the better. Understanding the broken process may mean gaining knowledge at the cost of customer service. One way to improve the likelihood of getting both an understanding and a happy customer is to make sure the team is sharing information. That way, whether by someone solving the problem or by the accretion of facts and scenarios, it becomes clearer what is going on.
I tend to be more focused on the solution than the process. This can be a drawback but, as with many things, being mindful can help you to keep the proper perspective, because it is not all one or the other. Many technology-related issues are hard to diagnose and, in the end, possibly not worth diagnosing. One upside is that blame for me isn’t a big issue. Accountability for the problem is one thing, but it also demands identifying ways forward. Blame is part of diagnosing the process and it can be an important part of what management needs to communicate to stakeholders. But it doesn’t necessarily contribute to a solution. It’s like the so-called perfect storm. It’s rarely one thing, or even one thing that’s likely to recur, that gets you bogged down. Use your debrief or post mortem to understand how to improve, but get the customer what they need in the meantime and keep that as the primary focus.