Support Management Magazine, July 1997
The Networks Down Now What?
A Network Survival Guide, Part I
George Spalding
Think about this for a minute could your company survive today without a network? When your network is down, (could happen!) doesnt everybodys head pop up out of their cubicle and start gabbing with their neighbor? Doesnt coffee consumption go way up? "Cube" friendships get renewed? Why? Simple. Cant do any work, the networks down. It is amazing how quickly the corporate landscape has changed. Its only been about ten years since Novell made local area networks viable for all but the largest companies. And only about 7 years since networks became what we could call robust and reliable. Yet every major corporation and mid-sized business and a staggering percentage of todays small businesses have rested the entire companys information workload and, by extension, the success or failure of their whole operation on the network. When the networks down, its a crisis.
Traditionally, the role of network support has fallen on the "network guys". A separate department which is usually guys (I would say at least 80-90% male in my Novell/Microsoft network classes, come on, girls, vast opportunity awaits Microsoft alone estimates a need for 150,000 more MS Systems Engineers by the year 2000 you go girl!) who have "substantial network experience" or have been recently trained and, often, certified in one of the major network operating systems (NOS). The network OS market is currently divided (roughly) as follows: Novell Netware - 60-65%; Microsoft NT - 15-20%; UNIX, Banyan, Sun - 15-20%. Novell is growing in total number of installations but ever so slowly losing market share (the total network market is growing faster than Novells sales), Microsoft Windows NT is growing in total number of installations and market share (the number of installations is growing faster than the total network market) which brings us to the current and future shortage of qualified Systems Engineers. Microsofts renowned marketing capabilities are beginning to outstrip its ability to support its products in the field. This is a serious problem for todays companies and a boom time for those qualified (and certified) to support MS products, bidding wars for these support capabilities already exist in a number of metropolitan areas where high-tech companies need to stay on the cutting edge. UNIX and, more specifically, Sun Microsystems are strong players with loyal customers that really cant find enterprise-wide, scaleable solutions in the Novell/Microsoft world (some people need the big, strong stuff). Regardless of Microsofts claims to the contrary, the UNIX/Sun share of the enterprise networking market should remain constant for the next five years (dont forget Sun created JAVA, the hottest thing to hit the Internet since modems). Banyan is another story. The industry pioneer in enterprise Directory Services (StreetTalk) for networks, Banyan watched its lead begin to erode with the introduction of Novells Netware Directory Services in the early 90s. In 2Q98, Microsoft will release NT 5.0 which includes Active Directory Services as well. The "killer app" that made Banyan unique is no longer unique, it has failed to keep pace with other current technologies and its future is cloudy at best. (BTW, if you are now asking yourself, "Hey, he didnt say anything about our company, we run stuff from the Ethernet corporation!" or "Well, thats nice, we dont have those guys, what about that TCP/IP company?" you have just flunked the network literacy test and need some network training now.)
So how does all this affect support? Most frontline support organizations refer their network-related problems to the "network guys" whose reputation for customer service rivals Genghis Khan. This is especially troubling to me. I spend most of my days teaching folks on both sides of this issue: Frontline support people who recount endless stories of technical arrogance and customer indifference about the network guys and their management and, on the other side, network support folks/administrators who are totally frustrated with the lack of basic knowledge and general comprehension of the problem of the frontline people. Both sides have valid points.
Frontline support people are exactly that on the frontlines. Ive even been to desks where the folks actually on the phones are referred to as being in the "hotseat". (Let those arrogant network "guys" try it for just one morning. How bout a Monday morning...after a weekend network "upgrade" which was supposed to be "transparent to the user" but wasnt.) Frontline reality is shaped by the day, by the hour, by the call. They (should) have specific goals and targets for time on hold, abandons, first call resolution, what to refer, what to keep, what to research, how long they can legitimately work a call before referring it to another resource, etc. The agenda of most frontline support in todays corporate world is, unfortunately, firefighting. It shouldnt be, but it is. I preach the need for training, I evangelize, I cajole, I demand I beg but to little or no avail. Not everyone and not everywhere, but at this years SSC East in Nashville, a help desk manager came up after one of my sessions and asked me where he could get training for his people that didnt take any time. "No time?" I asked, bewildered. "Yeah, I cant take any of them off the desk ever." "Not even for an hour or two?" "Nope, not even for half an hour." I tried to be polite, I dont think I was. I told him that I didnt know of any training that took no time. I wanted to injure him severely or at least ban him from the industry. I espouse the need for time off the phones: to recover, to rejuvenate, to learn, to train others. I know some of you are listening, but not enough. Corporate downsizing has taken its toll on frontline support organizations, there is no fat, no extra person, no backup, no net its full steam, all day, every day. No time for rest, training, improvement, investment just answer those phones, put out those fires. This "chew em up and spit em out" management style devalues the role of frontline support. It says to the workers "youre not worth investing in" AND it says to the customers, "wed like to help, but we dont know anything that isnt in our problem database and well quit before we ever have a chance to learn anything on our own." (And, of course, lets not forget "we havent been trained on how to enter stuff in the database.") The customers are frustrated by an endless parade of young, well-meaning but untrained "phone answerers" and an incredible lack of real "support". The workers (once they figure out how this all works) begin looking for a better place to work within a few months of hiring.
There are forward thinking support managers out there creating wonderful environments, encouraging their people to think of this not as just a job but as a real career, investing in them and giving them the time to learn and grow. I know what youre thinking they must all be altruistic bonzos with unlimited budgets with pansies for bosses, huh? No, they are hard-nosed, cost-conscious, bang-for-the-buck mangers who face all the same pressures from above that every support organization does. Theyve learned that if you want high first call resolution, train your people. If you want to shorten calls while maintaining a high first call resolution rate, train your people. If you want to reduce abandons while maintaining a high first call resolution rate, train your people. If you want to improve your customer satisfaction ratings, train your people.
So, the network guys are totally justified in their criticism of frontline support and get off scott-free in this whole discussion. No. Lets look at the agenda of the network department. They were created to "manage the network". This usually means maintaining the infrastructure. Which translates simply to performance (speed) and reliability (uptime). Thats the basic agenda of the network guys speed & uptime. Now we throw in all the new stuff: Internet/intranet, firewalls, switching to TCP/IP, routers/switches, new protocols, new cabling, etc. and we have a fairly high-level technical position with an enterprise-wide viewpoint. Thats the problem. The manager of the network department (never the same person as the manager of support) has the mission of keeping the network up and fast. He/she has delegated this mission to the network guys. This involves planning, designing, traffic analysis, upgrades, equipment maintenance, "network management", etc. and occasionally putting out fires in the form of server abends (abnormal ends) and crashes. Therefore, whenever a call is passed from the frontline support folks to the network guys its priority is immediately evaluated based on the criteria that Ive outlined. If the problem does not specifically impact the prime directives of speed & uptime, it is shelved to be dealt with "later" which often means never or, more likely, until the frontline analyst nags the living crap out of one specific network guy who finally caves and actually fixes it.
The "customers" for the network guys are not real people but more of a concept called "nodes" or workstations. They seldom, if ever, actually speak to or interact with a real user. They view of the world like road construction crews (I live in Minnesota where we only have two seasons: winter & road construction.). The road crews know that their work will impact traffic, but they believe that when theyre done well all like it better. There is no accommodation made for the individual who is now screwed because he/she missed an important appointment or an urgent plane flight. Repairs and changes are made for the "common good" of everyone. That is the way network guys think. "Dont call me because someone forgot their password or needs to be in the Laserjet group, I dont have time for this trivial stuff." The problem is that its not trivial for the user. They cant do their job their very important job their mission-critical job and their boss is yelling at them and next in line for yelling is lemme guess the network guy? Wrong! The frontline support folks take the brunt of the abuse because of lack of responsiveness by the network guys.
So both sides are right and both sides are wrong. The most important tool for providing responsive support for network-related customer problems is NOT an SNMP-based Management Console from Novell or HP but an SLA-based working relationship between the frontline support staff and the network guys. A Service Level Agreement between departments detailing how we will work together. I dont mean high-level conceptual, touchy-feely working together but detailed, nuts-and-bolts, procedural, I-do-this-and-you-do-that working together...with accountability if things dont happen.
If such an SLA is in place and supported by management, then a unique conversation can take place. "Im going to have to refer your problem to the network department. They will contact you directly." "How long will this take? When will they call me?" "Our agreement with them states that their response will never be longer than 2 hours for this type of problem." "Thanks."
Now that Ive gotten all that off my chest, next issue well discuss training options, certification programs and the role of outsourcing.