Own the Problem
In the late 1990’s, I was on the routing protocols TAC team in Raleigh — which means I answered the phone, and said things like, “This is Russ from Cisco TAC, how can I help you?” Generally what followed was a crash, or, well, just about anything. The design on the left is what we had on the back of our shirts — including what we called ourselves, the Gateway of Last Resort.
Of course it’s a play on words, as you might imagine — where does a host send traffic it doesn’t know what to do with? The gateway of last resort. And what is the gateway of last resort? A router. And what the RP team worked on was, well, routers. But there’s another reason we adopted this slogan for ourselves — because it was, generally speaking, how the CRC (the folks who took the initial call and figured out which backline team to hand it off to) conceived of our little team. The PIX, the 7200, VIP cards, crashes, hangs, tracebacks, any sort of routing protocol problem, lots of hardware problems, anything to do with the forwarding path, memory fragmentation, and just about anything else. A classic example was the frequency of IPX cases tossed in our queue. When we asked why we, the IP team, were receiving so many IPX cases, the answer came back — “IPX is just IP Xtended, isn’t it??”
We could have, I suppose, whined about all of this — but, generally speaking, we didn’t. Instead, we stuck with the TAC credo: if you take the case, you own the case. Feel free to get other people involved, and feel free to say, “I’m out of my depth here,” but don’t ever, ever, leave tell the customer, “I don’t really know, let me hand you off to someone else.” All such hand-offs were to be positive, and you were to track the case until it was closed even if you did hand it off.
In those early days of widespread deployment of networks, a lot of people were pulled out of offices and teams and given the task of installing and running a small network. The entire process was a complete mystery to them, from unpacking the boxes (I actually had someone ask where the drive bay was to insert the disc that came with the router…) to getting the cables plugged in (“why doesn’t my cable match the plug on this thing?”), to configuring the device to work in the real world. Because we wanted networking to grow — and hence our business — we took care of the people we worked with over the phone.
In short, if you took the case, you owned the problem.
As I work through tech support and other channels, I find very few people in the networking industry who want to own the problem any longer. Their primary goal seems to be proving the problem isn’t in their “stuff,” and then getting you off the phone, or off their backs. This isn’t just “not helping the person,” this is also giving people a bad impression of network engineers, and networks in general.
It’s completely understandable if you don’t know how to solve something. It’s completely understandable if that once you’ve proven the problem isn’t yours, you want the person on the other end of the line to hang up and go away — so you can get back to “real work.” But it’s also completely understandable that once you’ve walked away, the person you’ve walked away from isn’t going to be any happier just because you’ve proven it’s not your problem.
Spend the moments it takes to guide the person with the problem to the right team, to make certain the transition happens smoothly — even if you can’t give that person the service they need, try and facilitate the service they do need.
It doesn’t matter if it’s your problem or not — own the problem, for in owning the problem, you’ll also be part of the solution.
Once upon a time, tech support had head count. It wasn’t a cost centre it was critical part of the product. With head count came time and resources to get things done.
In the last ten years, vendors have encouraged customers to reduce headcount and “buy the new shiny thing” instead. We live in a wasteland of resource poverty where owning the problem is simply impossible.
Yes and no… Note I didn’t say “solve the problem,” 🙂 as there’s simply no way to ever solve every problem, or even most of them. But that doesn’t mean engineers can’t go farther than just saying, “there, I’ve proven it’s not my problem, now go away” Rather, we should be able to say, “it’s not me, but you might want to try … — here, let me get them on the line and see if we can get this sorted.” From another perspective — when the business comes and says, “I want this done,” you can’t just say, “there, I did it.” You have to engage in the business process in order to deploy what makes sense — the business person simply doesn’t know the right questions to ask most of the time.