Pat Vickers, Expert in Help Desk Management

Start a Team Mentoring Program

Most support teams are pretty diverse when it comes to skill sets. Some techs excel at customer interaction while others are experts at telephony and others are the hardware specialists. It’s good to have a specialty.  We can be good at many things but generally, to be great we must concentrate on one area.

A lot of Good can be better than Great

In managing teams I found it’s better to have a lot of employees who are good at many things than a few employees who are great at one thing each. Vacations and sick days alone really kill you. That’s why I like to have a mentoring program within my team. A lot of organizations refer to this as skill sharing but I’ve had more success calling it mentoring.

Make everyone a Trainer

There are few ways to do it. One is to schedule two hours a month, or even a week devoted to training. Ask each team member to prepare a course to give the rest of the team in those hours. Some members will be too shy to present. While it is great to encourage people to face their fears, never force it. If an employee just does not want to present ask a less shy employee to work with him or her or ask that they write up something.

Don’t stop the program when everyone has had their 2 hours. Start over again. Each area of expertise has should have a lot to offer. Encourage your employees to create training around incidents where they learned something new about their area.

Another mentoring method is just that, mentoring. Team up people with different strengths for a few months at a time. Be clear about why you team them. Ask each tech to mentor the other one on their specific strength. Spell it out. Make sure the techs know you mean their ability to analyze network issues, not their wicked Xbox skills.

Everyone Wins

Mentoring others helps the team become more diverse in their skill sets and, therefore, stronger. It also develops leadership skills in people who likely want to eventually move into management roles. It’s a good trade off for everyone involved.

Do you have a mentoring program within your team? Tell us how it works for you. What problems, if any have you run into?

For more ideas on how to get the most from your team check out our Practical IT Manager Gold series.

Pat Vickers, Expert in Help Desk Management

Respecting Your Users

I spent years in phone support. I was a frontline tech, a manager and, at times, a trainer. I always liked the job but I was one of the few. Most techs hate it and would rather do anything than take calls. I think there are a couple of reasons.

Would You Like a Hot Apple Pie With That Password Reset?

The first thing people hate about working phone support is they are on the phone. That sounds silly but working a phone room feels like a low lever job. You have to wear a headset which always looks funny. Management counts the number of calls you take and coaches you on how to take more and worst of all they monitor you. Even when the pay is good those three things together make employees feel like they are just one step above wearing a hairnet. Heck Some hairnets look better than the headsets.

The big thing techs always complain about though is the callers themselves. Techs go on and on about how stupid the users are and how much they hate them. I never could figure out those techs. I mean the only reason we had jobs was we knew more about computer systems than the callers. Did they really want the callers to be able to figure these problems out on their own?


For the most part I always liked my users and liking the people I supported sure made the job a lot better. Once I was in management and training I did my best to change tech attitudes about users. This was my philosophy. What job would you rather have, one where you take care of a bunch of whiney idiots who can’t take care of themselves or a job where you solve technical problems for intelligent professionals. I always worked with smart professionals and I was always happy in my work. The difference is really in the tech’s attitude and respect, not the users’ education.

For more tips on how to manage check out The IT Project Manager’s Toolkit (below). It’s an invaluable asset for working with people.

The Worst Boss I ever Had

The Reason Skip (not his real name) was the worst boss I ever had was that he had no idea what my job was. At the time I managed a team of web designers. It was not a secret that Skip got his job as my boss because he had more time to spend on meetings and oversight. He had no clue what we really did. He had no skills in the area, knew nothing about programming and had no experience managing a team of designers. The result was most of the time I was on my own.

You Can’t Fight for What You Don’t Understand.

Being on your own sounds great but every time I put in the request for new software or upgraded hardware Skip couldn’t explain to his boss why it was needed and I wasn’t allowed to speak to his boss about it. This meant I had to write reports on the use and need of the for every order. Even with the report it would take several months to get a request approved.

The truth is I liked Skip. He was a great guy, constantly wanted to take us out to eat, to ball games etc. He was just a terrible boss.

We all Need Help From Time to Time

I know many people complain about bosses who yell, cuss, back stab etc, but nothing is worse than having a boss who really is clueless in your area of expertise. We all need support, on occasion and a boss like Skip cannot help you or support you in any way other than saying “great job” even if you are failing miserably.  I like hearing great job but I like not failing even more.

For tips on true leadership check out the IT Project Manager’s Toolkit. It makes the job of leadership a lot easier.

Measuring the Cost of Downtime

Have you ever tried to get an infrastructure project funded only to discover that it is like “pulling teeth” to get your senior manager’s approval?

If so, it is probably because your senior manager is having major difficulty understanding what you are talking about. All he hears is that you are asking for lots of money, and that’s not something he lets go of without understanding the value of what he will receive from the investment.

Senior executives normally do not understand technology, and they don’t want to.

Well, if that’s the case, how do you get a technology project funded that’s critical for the stability and support of your infrastructure? You know how important it is but you aren’t getting the message across to your boss, the CEO.

Something that will help is to discuss the project in terms of business value, , , and certainly not in technical terms.

Discuss “WHY”, not “WHAT”!

“WHY” deals with benefits, i.e., business value. “WHAT” deals with technology.

Unfortunately as former technical people, IT managers tend to discuss the “What” and not the “WHY”. It’s a guaranteed way to put your CEO to sleep or give him a major headache.

Business value includes one or more of five very specific things:
– Increase revenue
– Decrease cost
– Improve productivity
– Differentiate the company
– Improve client satisfaction

When you change your presentation to highlight the business value your company will receive by making the infrastructure investment, your senior manager hears and understands you, and when this happens, he makes a decision that usually goes your way if there is sufficient value for the investment.

A tool that can help significantly is to paint a picture of the ‘cost of downtime’ that your project recommendation will help eliminate.

Calculating “cost of downtime” is straightforward, but first you need to visualize what we are talking about. Below is a simple infrastructure scenario:

cost of downtime template








In this example, we literally “paint a downtime picture” to show the following:
– Corporate HQ Office is home of the Data Center where there are three servers.
– There are five remote offices (Atlanta, Denver, New York, etc.)
– In each office we list the number of Users (500 at HQ, 100 in Atlanta, etc.)
– We estimate the average salary of a company employee is $20/hour.
– The green filled circles are routers.
– Three Downtime scenarios are highlighted:
o If the Atlanta office router goes down or they lose connectivity, the productivity loss at 100% is $2,000/hour.
o If the HQ router goes down (green filled circle on the Corporate HQ box), all remote offices lose connectivity and 100% productivity         impact will be $20,000/hour.
o If the E-mail server crashes it affects productivity of all 1,500 workers. At 10% productivity factor, the impact is $3,000/hour.

Using these assumptions you can quantify the ‘cost of downtime’ for any component in your company, even a zone printer or a single PC.

Once you and your client can visualize the downtime scenario we created above, you can list key components in a downtime chart and refer to it when trying to justify an infrastructure project.

Download Mike’s Cost of Downtime Template Here for Free!

This download is free to all Toolkit Cafe Registered Members. Please login to download

Not Registered Yet? Click below to “Join Us At Toolkit Café”!

Register Button Blue

(Once you have logged in, return to this page and refresh your browser to access your free download)

The Best Boss I Ever Had

I’ve heard that some of the most popular blogs on Toolkit Café have been about best bosses and worst bosses so I thought I would take this week to talk about The best boss I ever had.

Better Bosses Make Better Employees

The best Boss I ever had forced me to be better than I thought I was, to think for myself, and think through problems. If I made mistakes, I had to helped troubleshoot them until the issue was resolved. Fortunately most of the people we supported were patient and didn’t mind if I had to redo a network setup or if I crashed their laptop by installing the wrong drivers.

My boss literally felt that everyone had the capacity to succeed in life and everyone had opportunity if they wanted it. I think the fact that he was gay at a time and place where that wasn’t always accepted influenced those beliefs. He never let what others think get in his way. He had several degrees, stature and respect in his position.

All Good Things Must End

Later in life this boss left IT to get a law degree  but not before teaching me that the best bosses anyone can ever have are the ones who will work with you when needed, get  hands dirty with you, if that’s what it takes to get the job done, and help you achieve your goals…not just theirs. That was my boss.

Being a great boss is tough but worth it. To make it easier check out Mike Sisco’s IT Manager Toolkit. It provides everything you need to for the day in day out grind of managing leaving you more time to work with  your employees.

Don’t Forget Basic Training

In my first IT job I always found it interesting to know more than my boss, the director of IT at my alma mater.  Training him to do his job was very frustrating.  The hardest part was when I tried to explain that we can’t expect all the students to know how to use the new system and the new networking printers and that someone would have to teach a class.  Of course that ended up being me.

You Can’t Reap If You Don’t Sow

The training went well. We ended up having to schedule several more classes for students and faculty. The rest of the semester went much smoother, once everyone understood how the network ran. It was so successful we continued the training through the rest of the year.

What I learned then is still true, even in this day and age.  Everyone on both sides want everything to already just “Magically” work with no effort or training.  To ask them to do basics to get their job done…….out of the question. Even now when everyone should be “in the know”.

Moral of the story

Never know more than your boss or at least pretend not to know or just feel free to apply to your boss position when it opens.

For great information on how to make problem employees implement their own ideas take a look at the PRACTICAL IT MANAGER GOLD SERIES. It’s an invaluable tool.

Pat Vickers, Expert in Help Desk Management

When You Grease, Don’t Forget the Quiet Wheels

As with most idioms, “The squeaky wheel gets the grease,” is far too often completely true, especially when it comes to managing employees. This is not a good thing. One reason is people are not wheels. Noise does not necessarily mean there is a problem and quiet certainly doesn’t mean there are no problems.

A Parable for Our Time

I remember a team with which I worked several years ago that was moved to a new building. We were all quite excited. I was finally going to have an office with windows and my employees would all get bigger cubes. The managers who were squeaky wheels managed to get a look at the new area before it was officially open and laid unofficial claim to their areas. This did not affect me as my team was took calls and required a phone room. It did affect a few of my peers. I asked one, who was by far the smartest, hardest manager on the team, why he just stood by while others got asked for the good offices. He said he figured the VP would make the decisions regardless of what we said.  As usual the squeaky wheels got their choice and the quiet managers took what was left.

Another difference between wheels and people is that grease usually doesn’t quiet squeaky people. As time went on the squeaky wheels increased their teams far more than the quiet wheels did, they got all the best equipment and managed somehow to get a lot of credit for work other teams did. After a while even the quietest wheels noticed that  though they did most of the work and never complained they never seemed to get the thanks or perks the squeaky wheels got. True to their nature they said nothing but one by one they left, leaving the VP with a bunch of squeaky wheels that couldn’t really take him anywhere.  I managed to find another department myself.

And the Moral to the Story is

I understood how it happened. The VP wanted a happy office.  What he didn’t understand is to have happy office you must employ happy people. Giving the unhappy people everything they want doesn’t work, at least not for very long.

I’m not saying managers shouldn’t get out the grease gun when they hear squeaks. What I’m saying is, listen to what people want. If it is reasonable and will help productivity then make sure all your wheels get the grease and give those with the best results just a little more, otherwise you might find yourself stuck in the muck.

For tips on how to handle problem employees, squeaky and otherwise, check out the Practical IT Manager Gold Series.  It’s a great resource.

9 Tips for Creating an IT Service Catalog

Why do you need an IT Service Catalog? Let’s count some of the ways.  A Service Catalog offers your organization an efficient tool you can use to:

  • Define and publish available services.
  • Standardize service fulfillment processes.
  • Establish achievable service levels.
  • Determine the associated costs to manage performance.

When the new catalog is in place, IT organizations can begin to operate as a business.  Services that are not frequently requested by customers can be discontinued, and delivery processes for high-volume services can be optimized. Key Performance Indicators (KPIs) provide greater visibility to control costs and respond to customer demand.

The following describes some crucial hints and tips for ensuring that you reap the benefits of successful service catalog implementation.

1. Pilot the Catalog

Determine which services and attributes need to be included or revised prior to comprehensive rollout. Publishing the initial service catalog without chargeback, targeting a specific business unit, or covering only a few primary IT services may allow for refinement and iterative maturity over time.

2. Establish Your Team

The initial catalog should be driven internally within IT, and should include adequate representation from all stakeholders within each domain to ensure that documented services are appropriate and valid. Executive sponsorship is also critical.

 3. Establish A Baseline

The team should create a list of all the services that IT offers, regardless if whether or not they will be included in the initial catalog of services. When creating the baseline catalog, it is important to consider the following key guidelines to ensure that services offered can be effectively managed moving forward:

  • The service is self-contained and is not part of a larger service offering.
  • The service can be monitored and measured for consumption levels.
  • The service has costs that may vary with changes in consumer behavior.
  • The business could potentially procure the service externally.

4. Refine Service Offerings

The initial baseline should be refined to include only those initial services to be included in the pilot or first iteration of the IT service catalog. If different levels of service will be provided, cost variations should be documented by consumption type.

5. Perform Service Benchmarks

Once services have been identified, service levels should be benchmarked using available monitoring capabilities and measurement techniques.

6. Publish the Service Catalog

After services are documented, reviewed, and finalized, the service catalog should be made available to the business, preferably through an appropriate business relationship manager.

7. Establish Service Agreement

Following business review and selection of services, any formal service selections and supporting agreements should be facilitated through the service level management process and documented in a standard Service Level Agreement (SLA).

8. Improve Services

Any service improvement initiative should be iterative in nature and should ensure that ongoing improvement activities enhance communication with the business. Maximize operational efficiencies and continue cost reductions through a continuous service improvement program (CSIP).

9. Refine the Service Catalog

The cost, complexity, and difficulty of implementing an IT service catalog will vary greatly depending on the details incorporated into the final document.

At the end of the day, Service Catalogs allow us to become more informed of customer desires as well as our offering potential.

Want to Create an IT Service Catalog for Your Company?

The dedicated team at The Art of Service has designed a step-by-step toolkit to aid any IT professional in the implementation of Service Catalog capabilities in any organization. The toolkit aims to introduce Service Catalog concepts, as well as provide you with the tools to successfully create a workable Service Catalog culture in your organization.  Click here and check it out!


Practical Advice for Preparing Your 2014 IT Budget — And Free Templates!

Let’s face it, friends.  Budgeting can be a real pain!

I’ve seen IT managers spend hours upon hours developing what they think is a concise budget and proudly deliver it to their manager thinking it is “accurate” and “what their manager wants” only to have it summarily rejected and sent back for a re-work. In other cases, I’ve known IT managers who spent countless hours developing an approved budget only to find themselves asking for more money four or five months into the year because their actual expenses are blowing out of their budget.

Preparing your annual IT budget does not have to be an ordeal. It can actually be simple and a rather quick process when you are prepared, know what to do, and you have tools to help.

Contrary to conventional wisdom, being accurate is not always your top priority when budgeting. Certainly, you want to have insight into the budget categories and have your estimates fall into the right “ballpark”, but you also need to be appropriately conservative and build the appropriate buffers into the numbers. The reason is simple:

Surprises Happen!

Not only do surprises happen, but those surprises are almost always costly surprises — seldom are they good surprises!

To help you organize your thought process around budgeting I have assembled the spreadsheets I have used in the past to prepare dozens of IT budgets for various businesses.  You can download all of my worksheets for free right here:

This download is free to all Toolkit Cafe Registered Members. Please login to download

Not Registered Yet? Click below to “Join Us At Toolkit Café”!

Register Button Blue

(Once you have logged in, return to this page and refresh your browser to access your free download)

While these worksheets will be quite helpful in helping you organize and plan your budget, I highly recommend you also take a MDE_IT-Budgeting-d-150x150quick hour or 2 and read through my concise eBook:  IT Budgeting:  Operational and Capital Budgeting Made Easy.  This book will reveal my practical secrets for creating a successful IT budget.  Using my methods, I have never missed a plan and now you can benefit from my insights.  Click here to download my book and add a little sanity to budget season!

The 4 words tech support should never say

In this edition of Jeff’s Quick Rants, I’d like to share with you the one thing that should never be said by your customer-facing, level I, level II, and level III support staff.  When an IT person utters this four-word phrase to someone not in IT, the message it sends is, “You’re obviously an idiot because there’s no way on earth that what you’re reporting can possibly be true.  You must be mis-reading or mis-keying or mis-clicking something.” (Unspoken but added in the tone: “You moron!”)

Sometimes, tech support people use this four-word phrase in jest, attempting to use comedic irony to lighten the tone and the mood. That’s acceptable, if the use is truly in jest. Problems occur when the phrase is an automatic response, uttered without thinking first.

Tech Support Rule #1: Listen, Think, Then Talk

IT pros love good, quick answers to questions. Many of us think we have the ability to discern the root cause of a problem and articulate a solution in less than 0.06 seconds – every time. The harsh reality is, however, that most of the time, those snap-quick answers are wrong.

We IT managers and support professionals as a group need to remind ourselves that we have two ears and one mouth for a reason – we should listen twice as much as we talk.  In the early days of tech support, you could solve a lot of problems by asking your customer, “Have you tried rebooting the machine?”

It’s a new world now, folks.  We’re supporting cloud-hosted, Web-based interfaces running simultaneously on desktops, laptops, tablets, and supposedly-smart phones. Our in-house applications are stored on storage area networks and department- and user-level drives are mapped to different letter-names depending on the mood of the tech who built the box or added the user’s access to a resource. You can’t let the first thing that pops into your mind be the first thing that pops out of your mouth.

The four forbidden words

Here are the four words that I recommend we ban from the IT lexicon forever:  “That shouldn’t be happening.” The variation on that phrase, “That shouldn’t have happened,” goes on the list, too.

I’ll tell you why these words make my skin crawl.  Recently I had to move my desktop machine from the sixth floor of the office building to the third floor. While I was waiting on the movers to move the stuff and for tech support to make the ports hot at my new location, I logged on to a public machine in a conference room so I could get some work done while I waited. I logged in, fired up the email client, and sat and watched as the email client flashed various “loading” messages until it timed out and gave up.

I trotted down to the Help Desk Call Center area and said to the tech on duty, “Hey, I’m having problems getting the email client to work on the conference room down the hall. “I’ll take a look at it,” the tech said.  Email access is a big deal on conference room machines, because you frequently need to get into email to pull up the URL for webinars or other online meetings.

The tech “took a look,” all right.  The tech looked at the error message, then went straight into Control Panel and started making changes willy-nilly.  Still the email client wouldn’t load. No problem for me, though, as my new workstation was ready.

Three years of cached email addresses – gone!

I fired up my PC, confirmed my internet access and mapped drives were intact, and launched the email client. I went to compose a new message and — what’s that? The cached email address I needed wasn’t there. In fact, NONE of my cached email addresses were there.  Three years’ worth of email addresses were gone.

I went back to the Help Desk Call Center area and asked, “Hey, did you do something to my email account when you were troubleshooting the machine in the conference room? Because all of my cached email addresses are gone now.”  What do you think the response was?

“That shouldn’t be happening!”

No kidding, Sherlock. It shouldn’t be happening, but is it happening! It happened! Three years ago I got this new machine and for three years the email client had been dutifully caching my email addresses.  Now they’re all gone! And the only response the tech suppport “pro” had to offer was, “Well, gee, uh, doh! That shouldn’t be happening!”

It was as if the person was saying to me, “Come on, you ID-10-T, you must be mistaken.”

What you should say instead

If the support person had simply listened and thought before responding, he might have come up with something like, “That’s not good – let me look into it.”  Or, “gosh, I’m sorry to hear that. Let me look into it.” But no. This person didn’t stop and think, didn’t take two lousy seconds to consider the possibility that whatever he had done while troubleshooting the conference room machine might — just MIGHT! — have resulted in deleting my cached email addresses.

“What did you do to the conference room machine?” I asked. “Well, I deleted your user profile and recreated it and renamed it and….”  I stopped listening.  I said, “So, you did something destructive (deleting the user profile) without knowing with some degree of certainty that it would fix the problem?  “Well, yeah.”

How the story ended

Some of you might be thinking, “Come on, Jeff, what’s the big deal? You just re-enter your email addresses.” Yeah? Thanks for the empathy. Let me delete all of your cached email addresses and we’ll see how much you like it.

The tech who blindly deleted my user profile off the conference room machine kept jabbering about how “that shouldn’t have happened.” Who knows what this schmuck actually did to the conference room machine, but there was no doubt that whatever he did adversely affected my ability to do my job.

I got the tech’s manager involved, and eventually they produced a copy of the NK2 contacts file from backups that contained my cached email addresses, but they didn’t have any idea how to import them back into my email client. “Just copy and paste them into an email address and that should retain them.”  I tried that trick, and it didn’t work.

I’ve saved the NK2 data so I can search it and copy-and-paste email addresses when I need them. But overall, this was an epic tech support fail. I reported a problem on a community machine. The tech support person didn’t stop and think. Didn’t stop and google. He just dove in and made a destructive change that didn’t work. Then all he had to say to me, the client, was “That shouldn’t be happening.”

I was thinking the same thing about his paycheck.

What shouldn’t be happening in your shop?

Listen to your techs when they’re on the phone with customers. Are they making ridiculous statements like “That shouldn’t be happening?” If so, you may want to send them a link to this article, because they’re doing a disservice to your IT organization’s reputation.

To share your “it shouldn’t be happening” story, post a comment below or drop me a note.

Related reading:

Jeff’s Quick Tips: 5 things techies should NEVER do or say (in sales presentations)