I’m sure you’ve heard this; “Educate your user community” because the more you educate them the less dependent on you they’ll be for every little thing. Educate them on security awareness, educate them on basic computer maintenance, educate them on getting the most out of their applications, educate them on using the “Help” feature, educate them on basic troubleshooting, etc. We’ve seen this philosophy advocated in everything from best practices manuals to Microsoft TechNet articles.
While I agree with this principle in most cases, I think it can be taken too far. In fact, I know I’ve taken it too far in the past.
I’ve educated some of the more technically inclined people that I’ve worked with over the years and I’ve benefited from it. For instance, a supervisor will tell me, “Don’t worry, Dan, I updated the Java version on all my people’s PCs” or “Hey Dan, remember how I wanted John’s PC moved to that desk over there? Don’t worry, I took care of it.” It has saved me time and allowed me to focus on things that require more technical expertise. Also, they really seemed to get a lot of satisfaction from accomplishing something and being considered “tech savvy.” Win-win.
That’s great, BUT I have to remind myself that although my users may be independent to some degree, I’m still the one responsible for keeping the computers running. That means that if (when) they make a mistake or an oversight, it’s my responsibility to fix it. When it comes to the information systems, the buck stops on my desk. Let me share one time where things really went wrong in this regard.
I worked with a corporate trainer who liked technology. He seemed to really enjoy taking care of the computers in his training room and over time I became more and more comfortable with him doing so. At this company we ran two different Call Centers, each on its own network segment. Since each Call Center’s applications could only be reached from their segment, we would switch the training room back and forth between the segments by plugging the room’s unmanaged switch into the drop for the one or the other.
One day I got a call from my trainer friend as he was teaching a new-hire class. He said, “When the person in the back corner tries to log in, she gets an error saying the computer can’t reach a domain controller.” Since I was in the middle of another problem (is there any other time?) I told him “Check for a loose cable, that’s probably the cause” and I went happily back to my work.
After about 20 minutes I start getting reports that IP phones for the one Call Center are dropping and that reps aren’t able to reach their applications when they try logging back in after break. When I rush over there and do a little investigating I discover that these phones and PCs are picking up IP addresses from the wrong network segment. I know you’ve probably figured it out already, but in my panicked state it took me a little while longer.
I’m thinking “Is someone running a renegade DHCP server on this segment? What’s going on?” Slowly the thoughts start to come together. “What was that conversation I had on the phone about 45 minutes ago?” “What is the only room in our building that contains a drop for both network segments?” The Training Room! Then I rush in there and start frantically yanking out cables.
Yes, my friend the trainer had unplugged and replugged multiple cables in his quest to find the loose one. Sure enough, while doing so he had inadvertently plugged the unmanaged switch into the drops for both network segments at the same time, negating the segmentation. Since the one DHCP server was a little quicker than the other, it started handing out addresses to both network segments. End result; dropped calls, angry customers, angry management. Not a good day.
So while educating users and letting them do things for themselves can save us time and effort, where is the line? Where are you comfortable drawing the line in your organization? Does your organization have a written procedure that spells it out? What experiences, good or bad, have you had in this area? I’d love to hear from you.
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.