JakeScaltreto.com

April 7th, 2007 by Jake Scaltreto

Well, I'm about a week in at Red Hat, so I figured I might as well check in. After the orientation was over on Tuesday, I spent the rest of my week hanging out with the Helpdesk (or, Help Desk, rather. long story) here in Raleigh. My first impressions of the Red Hat way of life (that weren't part of an expectedly sugar-coated orientation class) remain positive. I haven't met anyone who doesn't like their job and who isn't enthusiastic about working for Red Hat. I am especially impressed with the way the Help Desk operates compared to the helpdesk at my last place (with due respect, the helpdesk there started out good, but management chose to change it for the worse). The typical helpdesk is designed to operate much like a sweatshop, only instead of substandard goods, helpdesk's are expected to produce copious amounts of tickets as efficiently as possible. This means that in a typical helpdesk setting, customer service takes a back seat to producing numbers.

The reson for this is quite simple: managers (who generally aren't technical - at least not the ones who make decisions) love things that they can look at to justify where the company money is going. And, in the end, it all comes down to cost. The more tickets a helpdesk analyst can churn out in an hour, the lower that analyst's cost per ticket. And cost per ticket (we'll call it CPT) is one way managers have come up with to determine how much value they're getting off of their helpdesk. CPT can easily be charted - and you walk into your average classic helpdesk and you're likely to see a CPT graph hanging on the wall somewhere - hung there, no doubt, as the proverbial "big brother" poster reminding lowly analysts that they're always only a few cents per ticket away from the chopping block. Arguably, in some cases, more money is wasted tracking numbers than stands to be gained by doing so.

CPT is only one of a hundred ways that managers have come up with to quantify something that by its very nature can't be quantified: service. And this is where all the fancy bar charts and Visio diagrams really miss the mark. While everyone's busy trying to raise the numbers, one essential element of a helpdesk is lost: the help. Take, for example, two fictitious individuals, we'll call them Steve and Greg. Steve consistently has the highest operating numbers on the desk; lowest CPT, highest call answer performance, etc. All day, Steve takes call after call with the sole intention of hanging up the phone and getting to the next call. He doesn't take any time to troubleshoot issues, only writing a ticket to send off to someone else to solve. Greg on the other hand listens to the problem and takes time to troubleshoot it. Only once he has exhausted his arsenal of IT magic will he resort to escalating the ticket up to the next level. Because of the way Greg handles calls, his way is inherently slower than Steve's.

At the end of the day, Steve has taken, say, 50 calls, escalated 30 tickets and solved 20. Greg has taken only 30 calls, escalated 10 and solved 20. Based on these fictitious numbers, Steve is answering a lot more calls than Greg, thus his relative cost is going to be lower. They're both solving the same number of tickets - so on paper Steve is looking pretty good. But consider this, of the calls he took, Greg solved two thirds of them right at the desk, while Steve is only pulling 40%. Right away Greg is looking pretty good from a customer service standpoint; most of the people he talked to had their problems solved before they even got off the phone, and presumably, Greg was able to do enough investigation and troubleshooting on the phone to make for a very short desk side visit. Now Steve has far fewer smiling customers (percentage wise), but what's worse, all those people who didn't get their problems solved will now have to wait for a desk side visit to get their problems addressed. Plus, because Steve was so concerned with getting to the next call in the queue, and didn't do a lot of troubleshooting over the phone, the desk side technician will have to spend additional time trying steps which probably could (and should) have been done at the helpdesk. Already, it's getting pretty clear who's really of more value to the company.

Now, consider the fact that the typical helpdesk analyst (Tier I) makes significantly less than a typical desk side tech (I don't make the rules). The company now has to staff additional desk side techs to cover all the tickets coming from the helpdesk. Clearly, if the helpdesk was more focused on quality than on quantity, then fewer tickets would end up in the desk side team's lap and suddenly you start to see savings on staffing right there.

Alas, it will be some time before this thinking will have its chance in the greater world of IT management. Until then, most helpdesks will continue to be call routing centers, and chart wielding managers will continue their method of thinking. Things are also complicated by the myriad of companies out there that support this line of thinking. Namely efficiency gurus and those in the IT outsourcing world. One of the ways that outsourcing companies charge is by staff headcount, so the more bloated you make the staff, the more money the outsourcing firm stands to rake in.

When companies take the "classic" approach to helpdesks, customer service is reduced - and isn't customer service the end goal of any IT organization?

Sorry for going off on such a tangent there. Back to Red Hat. You see, Red Hat's helpdesk isn't based on the classic paradigm. At least from my initial impression, the helpdesk is deliberately staffed with knowledgeble individuals who's goal isn't to get to the next ticket, but rather to stick with the current ticket until it's done right. This, I feel, is a positive approach to customer service. With benefits which can be noticed not only from a service perspective, but may also be seen from a cost perspective when held up against the paradigm helpdesk.

Well it looks like I've gone and used up all of my blogging mana for one night, but I'll be back with more to keep you posted on my continuing adventures.

April 3rd, 2007 by Jake Scaltreto

Today was my second official day at Red Hat. I flew down to Raleigh on Sunday and will be down here for the next three weeks or so. Today and yesterday I spent in the new hire orientation class. I know NHOs aren't known for their flair and ability to keep one's interest, but I have to say it wasn't that bad. Meeting people from all different departments at the company has really given me a good taste of what Red Hat is all about. In short, it's a company with a focus and a goal. And everyone that works there is really passionate about the company. Furthermore, Red Hat seems to realize that it is nothing without it's employees and the open source community and does its best to stay in the good graces of both. It's a refreshing alternative to the typical corporate atmosphere which tends approach the company as an all-powerful supreme being and employees as tiny peons ripe for the crushing.

Tomorrow will commence my first day of actual "work" work. Even though I'll be a sys admin, initially all the admins have to spend a couple of weeks working on the Help Desk to learn the ropes. I think this is really brilliant - and is a concept worthy of adoption at other places. So, that's what I'll be doing until next Friday. After that, I'll spend an additional week down here during which there will be a departmental kickoff meeting with people from all over coming in, and I'll also start to learn my duties as a sysadmin.

After that I'll be flying back home where I'll begin my actual duties at the Westford office.

So, the next month looks like it's going to be both challenging and rewarding as I adjust to my new job.

On a non-work related note, last week I pulled and disassembled the engine in my '77 MGB. Right now it's off at the machine shop getting bored and cleaned up so hopefully by the time I'm back I'll be able to put it all back together to have it ready for the warm weather. I'm damn siked and can't wait to get back to working on it.