Support is not Manufacturing: Part 2

Ok, my arm is warm now.  Time to start tossing some theory bombs out there, and hope none get picked off.  They said Italians couldn’t quarterback, but look at Vinny Testaverde!  (Err…no, don’t.)

The reason treating support processes like a manufacturing endeavor fails is because it doesn’t take into account the sheer mass of uncontrolled variables that go into fixing software, IMO.  In an ideal world, you could have an unlimited number of truly gifted people performing every job function.  In the real world, you have to balance the needs for customer service with technical savvy, troubleshooting with good communication, prompt response with cost, etc.  People aren’t machines.

Taking a deterministic approach to creating your workflows means “sticking your head in the sand” to the variables out of your control, and overloading the system should a bottleneck occur.  Example:  If you require all cases go to your next tier of support at N days, but you neglect to factor that all of Europe takes August off, your small, specialized upper tier will be overloaded with issues from people who aren’t answering phones, (and when they do it will all be on the same day.)

Going in the opposite direction is fraught with peril as well.  As anyone who has worked in a helpdesk or support environment knows (at least from the armchair quarterback standpoint), the only consistently effective way to improve the quality of support is to have more people available to handle your volume, many of whom are aces at what they do.  As anyone who has been involved in managing a project like that knows, doing so is so expensive that you’d trash any profit your product might make.  So the question is how to strike the right balance.

The problem is, I don’t think there’s a good answer, at least not in terms of traditional support.  The real answer lies with software.  I’ll go into that next.

Comments (4)

  1. TristanK says:

    I’m enjoying this series.

    We’ve had frequent discussions about "Checkout-style" management of resources locally (here in Australia): you can pretty much guarantee that any given person on a checkout can process X items in Y time, with little variance from person to person.

    I’m wondering if it’s simply a matter of perspective…

    I bet if you asked someone working checkouts, they’d explain why they are more effective than Barry, or why Sean is a much faster worker than they are, but mysterious checkout factor X is applied to their work, so they think they’re doing a good/better/equivalent job anyway.

    VPs tend to get the 10,000 foot view of their organization, so perhaps to them at that level, Support engineering really does become like checkout management, despite the massive variances in day-to-day operations. They can make certain generalizations because historically, X support engineers of varying capabilities can perform Y operations with Z customer satisfaction figures at cost (bugger, I’ve run out of letters) A.

    At the "taking the calls" level, it’s really obvious how different our styles and techniques are, but viewed from a sufficient height, we all just look like ants, doing ant things that don’t really need to be understood, other than statistically.

  2. TristanK says:

    (should add, checkout in the grocery/supermarket store sense)

Skip to main content