Slashdot Mirror
Creating an IS Department?
brainee28 asks: "I work in the IS department for a manufacturer in Arizona (a
one-man-show). I do mostly everything; from systems, to networks, to procurement, to implementation. I can't mention who I work for since we deal
with government contracts. My problem is this: The company didn't start out with an IS department. Up until 6 years ago, a few computers were scattered around, but processes and business was still being done the old-fashioned way (with paper). When the IS department was started, it was started by a hobbyist (he was named
IS Manager before I showed up), who knew nothing about management or any of
the major issues that befall a traditional IS dept. I joined 6 years ago
(I have 5 years of IS Management experience, and 15 years of experience
with IS in general) with the idea that I would be managing day-to-day
operations. That has still not come to pass. The hobbyist left the company
4 years ago, and I've been on my own ever since." What is the best way for new IS managers to convince their superiors of the need for widespread change?
"Management views IS as a facilities function; computers are a tool, and
only a tool. I presented a proposal to them about 2 weeks ago which
completely negates that and several other ideas they've had about IS.
Management accepted the proposal; however I'm now faced with additional
mountains to climb.
I have 3 things that management and I currently don't see eye to eye on:
1) The main job of IS is connectivity. Connectivity is the core of why we have IS. Anything else is extraneous, and I shouldn't be dealing with it.
2) IS involvement in other divisions isn't necessary. IS is involved with other divisions when physical products get connected to the network, but not before. Software should be evaluated by IS only when it becomes necessary for purchase and implementation, not before. Any developed piece of software (we have an in-house programmer in accounting who uses Access -- I know, I know...) should be evaluated by IS when the software is ready to install.
3)I'm too overloaded. With 93 permanent users and 110 workstations (some are floaters), I can't do both systems work and admin work (my title is Systems Administrator, but I carry no management authority) on my own. My proposal stated the need for the creation of staff (a tech and a clerk). Management thinks because things are running, I have no issues, but I'm falling apart from all I have to do to keep things running. I need to offset the load so I can do more of the 'bigger picture' things to help guide this company out of the IS dark ages. (We have no CTO or CIO; Management is made up of engineers from different disciplines)
How would Slashdot users attack this? I've done my Google searches; went back to traditional books from Barnes and Noble; and even contacted my alma mater, Northern Arizona University, to find some answers. How would you prove the need for change on these three points? Can I institute change here?"
I have 3 things that management and I currently don't see eye to eye on:
1) The main job of IS is connectivity. Connectivity is the core of why we have IS. Anything else is extraneous, and I shouldn't be dealing with it.
2) IS involvement in other divisions isn't necessary. IS is involved with other divisions when physical products get connected to the network, but not before. Software should be evaluated by IS only when it becomes necessary for purchase and implementation, not before. Any developed piece of software (we have an in-house programmer in accounting who uses Access -- I know, I know...) should be evaluated by IS when the software is ready to install.
3)I'm too overloaded. With 93 permanent users and 110 workstations (some are floaters), I can't do both systems work and admin work (my title is Systems Administrator, but I carry no management authority) on my own. My proposal stated the need for the creation of staff (a tech and a clerk). Management thinks because things are running, I have no issues, but I'm falling apart from all I have to do to keep things running. I need to offset the load so I can do more of the 'bigger picture' things to help guide this company out of the IS dark ages. (We have no CTO or CIO; Management is made up of engineers from different disciplines)
How would Slashdot users attack this? I've done my Google searches; went back to traditional books from Barnes and Noble; and even contacted my alma mater, Northern Arizona University, to find some answers. How would you prove the need for change on these three points? Can I institute change here?"
Sorry to say, but if the acronym you use is not IBM, introduce it before you use it, or you risk leaving your intended audience by the road side.
Time to update the ol' resume and make for the exits.
There is no intelligent life there.
I've been in a similar situation. Company went belly-up a few years later.
You can't talk about Wikipedia's flaws on Wikipedia
This might not help with all of your complaints, but have you thought of taking the longest vacation that you can get away with? You get a nice break and when you get back everything will be so f$#%ed up you'll be the god the big bosses worship.
Well...ideally...
Sounds like you like to live in a more compartmentalized IT shop at a larger company (insurance?) where you can be isolated from reality. I'd start looking for a new job - there are thousands of other IT people who love the jack-of-all-trades hat.
What is the best way for new IS managers to convince their superiors of the need for widespread change?
Quit?
I hate to say it. My experience is that management usually won't take any action until things get bad. As long as you are keeping things running, management won't be willing to make any changes (read as: spend any money).
Managements *JOB* is not to "do things right". Its to discover the absolute minimum of funding at which a task can be accomplished.
It's the same situation at my work -- they put my department (RND) under incredible stress because incredible stress is *CHEAP*. Doing the right thing is expensive. This is why engineering and management are always at eachothers throats.
Religion is a gateway psychosis. -- Dave Foley
I'd have to disagree with you, the core purpose of IS is improving ROI.
If connectivity does not help the bottom line, it is indeed pointless.
To make your point, I'd find out what it would cost the company if the
computers were down for one hour, two hours, etc. Compare those costs
versus the costs for your requested help. Present that information to management.
For any new prjoects, I'd compare the estimated time/cost savings.
If you can put it in dollar terms you have a chance of approval.
Service guarantees Citizenship! Questions Guarantee GITMO.... Amerika Uber Alles!
In the words of Darth Vader, "it is unwise to lower your defenses." Drop the firewall; stop updating the anti-virus. Spend more time on /. until the network begins grinding to a halt. Shuffle from machine to machine, fixing each one slowly and deliberately. Don't answer the phone, pages, or emails. And get your résumé in shape, but forget about expecting a good reference.
You can't make them understand if they don't already. An IT infrastructure doesn't just spring up full-blown overnight and this cobbled together system you're trying to run is inherently unstable. Without any controls and with no support staff, you can't hope to cope.
GetOuttaMySpace - The Anti-Social Network
At the place at which I work I have the same problem. The department has dwindled from about 6 to 3, and the third guy just put in his two weeks. Thankfully, I've been able to convince the owner that we need at least one more person. I compiled a list of all things we do on a daily/weekly/monthly/yearly basis, plus all the projects that the rest of the company wanted done. Then I estimated the hours it would take to do all of this.
When I showed him with 2 guys that I could just keep things running at the status quo - no projects, no improvements - he saw the need for another guy. We're still not going to get the skill I would like - but at least it'll be another useful body.
I suggest you do the same. Along with documenting when things do go wrong - for yourself - and to present to management. You have to show them that it is because you are doing your job that they do not notice problems or downtime.
In addition - make sure to establish policy and procedure for interacting with the IS/IT department as soon as possible - otherwise you'll be bothered constantly and will never get anything done.
I hold a weekly "user" meeting where I let people know what I'm working on, what issues are still open, etc. The key is communication.
My suggestion is get a simple book on change, perferably something on Six Sigma practices. Something like this book from Amazon (or elsewhere, it's not a referrer link) would be appropriate for you I think: Lean Six Sigma for Service : How to Use Lean Speed and Six Sigma Quality to Improve Services and Transactions.
The key things to focus on to get management to see your plight is to determine a way to measure your current state (how long does it take to perform workstation maintenance per day, per week, per month? How much time is spent doing any kind of security auditing? How many security incidents have you had this year? etc.), and then present suggestions for improvement on your current state as your expected future state that will SAVE THEM MONEY. This is always what business cares about: making or saving money! So if by being able to hire a clerk or tech to offload some of your current responsibilities it will save you company twice as much as the tech's salary per year, you've just proven the obvious and glaring need to do just that.
Also, provide them with a documented measurement startegy for the future to ensure that their investment in another employee is benefitting the bottom line.
If management still says no, and you've clearly made the case that another body is necessary to help you out in your current position, keep yourself open to the possibility that another company can use your help more than your current employer. Healthy companies are open to change when its needed. Unhealthy companies bury their head in the sand and cannot look past maintaining the status quo.
Avoid tech slang at any cost.
Propose your plan. A well documented document. Describe all the potential failures the current network may face and the potential dammages. Don't go too much in the details. Use simple sentences, with the potential dammage clearly indentified.
Define the rules you would like to apply.
For each rule, set the goal. Tell them simply and clearly why the rule should be applied and what do you want to avoid.
They arenn't technicians. But they are smart. Simply use words they will understand.
If you tell them that without any backup for the mail server, the company may face up to 4 days without emails, they will understand.
If you tell them that the pop server is using outdated hardware and there is probabily that the hardisk may break. Most won't understand.
Don't send the report without any "face to face" introduction, try to organize meetings. If you are unable to put them all in the same room at the same time, try to meet them one by one in their office, and finish your "lobbying" by emails.
Once the executives boards is convinced by the neccessity, define a step by step plan. Don't try to change everything in the same week. Propose it and negociate it.
Once you've got their agreement. Try to make a mailing list and explain clearly to the employees why you will perfom the change and when. Invite them to ask any question they want.
Olivier
(I'm assuming that the acronym IS stands for Information Services. I would've said IT, but that's a quibble. If you meant something different, please disregard everything I'm about to say.)
The main job of IS is keeping the system running. Any technical issue that prevents someone from doing their job is yours. This alone should be enough to convince your management that a lone guy in an office isn't going to be sufficient support for your organization.
You're correct in that it's a mistake to view computing as just another facilities issue. However, that doesn't mean that it doesn't reach the same level of importance, and simply put, there's nobody else whose job it is to fix it. That means it's yours. (Or at least, that's what I'd be saying if I were your boss.)
See, you think this is what you want. Trust me, it's not. Otherwise, you can find yourself in the situation I was in, with a rack full of Linux servers and a department chair demanding to know why the $10K+ Windows-only web app he just bought isn't gonna run.
You're absolutely right about being overloaded, but you appear to be laboring under the misconception that a "Systems Administrator" is usually a management position. In my experience, it almost never is, unless by chance you tack the word "Senior" to the front, and even then the only people you'll manage are other Systems Administrators.
Your management will likely be unsympathetic, but you're not without hope. What I'd do is to brief them on the three biggest issues you're facing. Each brief should be about a minute in length, and all three should be delivered back-to-back. Each one should follow the structure: "this is the problem; here are the consequences of not addressing it; here is what i will need to address it." The trick: the third should be, "My time is fully committed just keeping what we have now together; if left unaddressed, neither the previous two issues, nor the multiple issues haven't mentioned, can be accomplished, resulting in the failure of X, Y, and Z; hire me another tech and an administrative assistant and give me some time to get them up to speed."
Best of luck.
I am a firm believer that almost all IT work can be broken down into 3 major groups: Hardware, Software and Network. With that in mind let us proceed with further discussion.
The easiest to deal with is probably the hardware. The key of course is to keep items under warranty with proper replacement cycles. By doing this the job is pretty simple. If a part of computer X breaks then you can simply call (or use web-based customer service) to receive a replacement part or have someone come out to do the work for you. In my previous place of employ we used Dell hardware on a rotating 3-year cycle. If a warranteed item broke we simply called and had them send out the replacement which we promptly shipped back. The only exception to this was laptops and for those we made them send a service person out, because replacing a motherboard in one of those is not my idea of fun.
Next up is the software. All software presently in use should be tested on a machine of the desired hardware mentioned above. You will of course have uniformity in machines, because this means you have a lot less problems to worry about. It is the Apple approach, sort of. You will want to be using a single operating system (well maybe two). In this case either Windows 2000 or XP. Build a machine with the specs of all the others and install and test all the software on the machine, once it is running properly, using Symantec Ghost to create images and since you will have the same hardware, you can quickly roll out new machines or re-image bad ones.
Finally the network. Please tell me they have a properly created network using nice switches and a good hardware firewall. We once found a network closet at a previous place of employ that was connected to the rest of the network with a HUB. Several of us almost died at how horribly setup this was. You are dealing with a small number of computers so I do not expect you to have several grand worth of networking equipment. So long as this is maintained properly, it should never really be a problem.
Now, how do you sell them on changes being necessary? First off, if you have sporadic and out of warranty hardware, be sure they are perfectly aware that if the machine(s) die that it could take several days or weeks to replace. I know this might be a huge overestimate, but it will give them an idea of the sort of down time that a user could face.
Next, do a similar survey of the software. Also if you can verify the licenses on everything. If you find any missing licenses tell them of the ramifications and be sure to give them the worst case scenario. We had an instance like this at my last job and several people were upset when they were cut off from software, but at several thousand dollars per license, the company was willing to make a huge deal out of it with us. Any software that is out of warranty also must go or be removed from the network. So those NT4 and 9x machines you might have running around (I hope you don't), need to be taken care of. Once again a proper explanation might do the trick.
Remember, no matter what all management always wants productivity. So if you show how their system can result in losses of productivity, not only for you but for users, they are more willing to consider change. The key of a good IT department is always going to be to maximize uptime and minimize downtime.
One final suggestion, request the power to hire and fire. Then remind them of reasonable salary expectations. I am not sure what they are paying you, but a true IT manager should be making 70k or more and good staff at least 40-50k. If you convince them of this, well give me a call because I know a thing or two about straightening out IT departments, I helped fix two of them before I finally started getting engineering jobs.
"Some days you just can't get rid of a bomb."
It sounds like you are having the same problems that we had back in the 70s and 80s when companies who's product wasn't IT related (we called it MIS back then) couldn't accept the concept of why a good IT infrastructure was important.
I went through several companies back then where I was either the first or one of the first people on staff when the IT department was created. The problem really isn't that you need an IT staff but that since you came up through the ranks you aren't really being respected. This is a problem that is not unique to our industry.
Unfortunately, I found several times that the only way to deal with the problem of respect for your skills was to leave. At your next job, your background is that you formed the IT department at your previous company (even though it was only you), and you built their network from nothing to roughly 100 users. True, jobs aren't as plentiful as they have been at other times, but the industry is not as bad as it has been and you might need to consider this option.
If it is safe to make the assumption that you are also not being paid a salary equal to the work you are doing start with that. Tell them that you are doing three jobs and that you want to be paid for at least two of them. They will either a) give you a raise, b) laugh off your comments or c) fire you. If they fire you then you've got a valid case against them for wrongful termination -- especially since they work with government contracts and have to adhere to higher employment standards than other companies.
If they laugh off your comments then they obviously don't have the ability to ever learn to respect you. That when you take the resume that you updated TODAY and start sending out copies.
But if they do offer to give you a raise, ask the followup question: and when does my assistant start so that someone is doing the third job now that you are paying me for the first two?
Believe it or not, that actually worked for me once. Unfortunately, five years later when there were ten people in the department they decided to replace me with two kids fresh out of college that they could get for half of what they were paying me. I was closing in on 30, which even in the 1980s was starting to be considered over the hill as a programmer. ARGH!!!!!!
And don't rip up the resume if they give you a raise and an assistant. I learned that lesson the hard way back in 1981 when I got the raise and then was squeezed out a few months later after they thought that my newly appointed assistant knew enough to do the job. He didn't, but he did do something that I didn't do when I left. When he was fired three months later he wiped out all the source code from the production system libraries and erased the backup system disks (this was on a Data General M600 with the old 20lb zebra drives). They had to call me and pay a ton of money for me to come in and restore everything.
"Management views IS as a facilities function; computers are a tool, and only a tool."
And they are correct. If it doesn't provably add to the bottom line, they don't care. How do you view motors, electrical outlets, and HVAC systems? How do you view pens and paper? Computers are analogous. Your management's view is at least the most popular view. If you don't like it, you will be unhappy working as an IS manager in most environments.
1a. Pragmatically, the main job of IS is to do whatever company management thinks IS should do. You are part of a relatively small enterprise; it is your job to help out that enterprise any way you can with whatever resources you have. If that means you draft, proofread, and type a memo about employee parking, you do it. And you don't complain. The 'leet crowd will disagree, I'm sure, but unless you are abslutely irreplaceable (and no one is), you don't make yourself appear to be a prima donna whose willingness to work is limited.
1b. The main job of IS is to make sure that everyone can use their computers. Connectivity is included in that, but so is installing software, reconnecting keyboards, writing login scripts, patching servers, and (insert your least favorite computer-related task here). IS is the department with the people that make working with computers seem as easy as breathing. It is their job to make it easier for everyone else to deal with computers.
Corollary to 1b: This includes the secretary who is incapable of rebooting her own computer, can't use the Start Menu, and tries to scan documents by running the optical mouse over them. ("At my last job, we had a business card scanner had a light on the bottom, so I thought...") And you do it with a smile and reassure her that everyone has this trouble.
2a. IS involvement in other divisions is the purpose of IS. What, you're only providing connectivity and computer services to your own division? Or perhaps you're pushing cookie cutter solutions onto a company that doesn't need them? ("Hey, 'IS Manager' magazine says ALL the cool manufacturing IS managers are doing it!") If you're not talking to other division managers and finding ways that you can help them, you will find yourself replaced by someone who will.
2b. IS involvement in everything that affects IS is essential. Otherwise, some bright, eager, manager is going to put lots of time and effort project that will consequently be impossible for you to kill, and will ruin your whole year. Standardizing the product design department on Macs, perhaps? Or converting all the legal department's documents to WordPerfect format? This is a political struggle. You want to be present at the meetings where bad ideas are born so that you can strangle them. If you limit your involvement to saying "No, that's not a good idea" just when someone else is ready to hand their project over to IT, you will be disliked and frequently over-ruled.
3. What you've proposed is tripling the payroll costs of IT for no appreciable benefit to the company. In the eyes of company management, things are running fine. If you are really falling apart, you need to find yourself another offer of employment. With that in hand, find out if your company is amenable to improving your situation. If not, walk. I doubt that you are going to succeed in setting yourself up as a CIO, which is what your situation really needs. You have no management authority, and getting some is the only way to really fix the situation.
I've been in your position and held your mindset before, and it's not easy. I cannot emphasize enough that you must both understand management's mindset AND be prepared to leave. Otherwise, you will be unable to negotiate a satisfactory resolution to your issues. At the very least, I would agree that you need a tech to work with you; a ratio of 1:100 is ridiculous.
Good luck; you'll need it.
Get it through your head you are not an IT manager. As your title states you are a sys admin, From what you've said your job is to keep things running not to make sweeping changes.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
I agree with the parent; if you can take some time to put together a business plan, you are more than halfway there. Some suggestions to help you along the way:
* Identify a "champion" in upper management and work together to get approval for the plan. If you don't have a higher-up who thinks what you are doing is worthwhile, you will continue to be a voice in the wilderness.
* Tie your project to a pain point. You and your champion need to identify something that's bothering the CEO and CFO, and figure out how to fix it. Most CxOs don't care if the receptionist's PC is running Windows 95 and takes more time for you to fix it. They will care if you can accelerate revenue (ship product faster) or reduce expenses (reduce time inventory sits in the warehouse).
* An alternative is to improve the decision-making ability: deliver more accurate information or deliver information faster. This gives a business the basis for a competitive advantage.
* Start small. Keep your project's scope simple and discrete. Grand plans to integrate systems don't fly; things to eliminate redundancy or repetitive data entry work better (wireless inventory updates from the warehouse, for example).
It's tough to see this situation when you are a person who cares about the job they do, can see how to improve the network, and yet can't get the initiatives approved. As others have pointed out, you may be working for a company that is a late traditionalist / very late adopter. If they think things are running "good enough" they will resist change in spite of evidence to the contrary.
In that case, go to where your years of experience are appreciated. Get your resume together and get another job.
While I am in complete agreement with you, I don't think it will work in this situation.
Since the company hasn't made a complete switch to computers, they'll just fall back on their old habbits if the one of the computers die one day that week or they'll just log onto a friends...
In this situation, and I hate to say this, it would probably be best if he went on vacation on a Friday and mid-morning Monday or Tuesday,login to one of their routers and kill internet access. That will fubar their email, shopping, etc. At that point, they WILL call him if no one can get anything to work. At that point, the best thing to say is "I can be in tomorrow, I'm out on the lake right now..." When he comes in, act all pissed off and say that it was a simple fix (like restarting a router-but use the techno babble) and tell them this wouldn't have happened if a second person where brought onto the team.
When he explains that he needs more than one person for the network, he also needs to use an analogy for their situation. If they make vehicles something like 'currently, its kind of like only having 1 welder for the whole production line - it can work but it doesn't work well..."
If I where in this hard headed situation, this is honestly what I would do. I'm not a mean person, but some people have to be forced to change habbits and see the light. When working for an ISP, I cannot count how many times people canceled our service because we changed our homepage - people just don't like change.
I might point out that he not forget specific examples over his tenure that could have been addressed more effectively with an organized IT department. He should put all of this into a well-organized report and schedule a presentation in front of both his boss(es) and those of affected departments.
Gamingmuseum.com: Give your 3D accelerator a rest.
If you are not in the IT business, then your goal as a manager/owner is to minimize your costs (real and "soft") to the absolute lowest point possible that is bearable. If, on the other hand, your business is IT (ie: consulting company or something), then you might put much more into it.
This isn't rocket science. IT, for most companies, is a cost center. Treating it as otherwise is bad for business and will lead you to spend lots of dollars with little return. THIS IS HOW IT HAS BEEN AND HOW IT WILL BE IN THE FUTURE.
240:1 servers:admins. Admin = me. I did have a backup, but only in the sense of "help help everthing's on fire and he's out can anyone help?". Elsewhere, I've done 20:1 users:admins w/ mixed NT + Unix workstations, 100:1 users:support staff (30 staff = 8 server admins, 14 helpdesk staff, 8 managers; and yes, that's too many managers), and 10:1 servers:admins in an overstaffed gov't Unix shop. Right now it's something like 50:1 servers:admins for the boxes I'm dealing with.
:)
Automation is your friend. If you don't know a scripting language, learn one. Hell, spending an hour reading the output of 'help' from an NT command prompt and going through each command to figure out what it does and doesn't do is a good starting point if you're not already familiar with Windows batch files. You're going to have to learn some combination of shell scripting, Perl and Expect in the *nix world. PHP + MySQL are good to know too, for being able to throw up a quick web-based solution to a business problem, or to modify an existing open-source LAMP application to suit your purpose.
It's doable, and I still have time to spend hacking on side projects, doing additional automation + scripts for other people and departments, writing/customizing reports and reading Slashdot.
Look at ways to reduce or completely eliminate time spent on repetitive tasks. Fewer bigger servers > more smaller servers. Consider your architecture in terms of what users need to do and how to do that for the least possible effort and cost. If you have a fast, reliable network and users don't need to run local I/O intensive apps (2D/3D manipulation programs like Photoshop or AutoCAD are classic examples) on their desks, look at using Citrix or Tarantella or NoMachine or SunRays to serve desktops remotely and cut down on admin costs for supporting apps. Put data in a central location and BACK IT UP. Databases are good. Performance monitoring is good. Centralized management is good. But remember that not all solutions work for all environments, remember to be flexible and aware of your organization's needs because the Gods of Good IT Practice won't pay your rent at the end of the month.
Look at possible points of failure and figure out what it would cost to eliminate or reduce them, and come up with a cost/benefit picture for management. There will be times when management says no, but as long as they recognize that not spending $2k now could lead to a weeklong network outage, then you've at least let them know the consequences.
"We can categorically state that we have not released man-eating badgers into the area." - Major Mike Shearer, UK
Karma Whoring?
The first, most common, and most significant mistake that most IT shops make is that they are managing technology. This is wrong. The computer has no wants or needs, no defined function, no need to connect with other computers, save for what the user imposes on it. The computer is a tool, no more and no less. It is a high-tech hammer for pounding digital nails. Never forget this. Your job is to provide the best tool possible for the person using it. That means that you must understand for what it will be used, which in turn means you must understand the person, which means that the primary job of IT is customer service. You, dear computer geek, to be successful, must be a People Person.
Users have certain needs, desires, and expectations of their tools. If the tool does not give the desired result, it is a useless tool. If you are in charge of that useless tool, then you, too, are useless. No amount of ranting, railing, policy, or scope statement to the contrary will change this simple fact. If you're not part of the solution and all that. You are in charge of the whole tool, not just connectivity. In a larger organization with thousands of connected devices you can break the job up into different groups (network, desktop, development, helpdesk) - but with 110 machines, it's all you, baby.
Talk to your users. Sit in on planning meetings that involve technology or new software. Know what they want to do and why they're looking at this piece of software or hardware to do it. You may be able to offer insights. Maybe the desired result is an unexplored function of software you already have. Maybe there's a different package available that will do what they want better than what they're looking at. Maybe what they want isn't exactly what they're asking for. You won't know any of this unless you participate.
Use the staff you already have. You said you're on your own. You also said that there are 93 permanent users. Use them. Deputize one or two technically savvy people from each department and make them your first line of defense. Your personal noise level will drop more than you'd believe by weeding out all of the problems that can be solved by rebooting and checking that connections are tight. Spreading this over a dozen people significantly lightens your day without negatively impacting theirs.
Know, also, that your users don't understand the tool. They understand what they do with the tool. They know how to run a sales report without having the foggiest idea of how a database works. They know how to go to Google without having ever heard of TCP/IP, or knowing why T-568A and T-568B are different. They'll hand you a 4" square piece of plastic and report that "their hard drive is broken". So what? They don't need to know nuts and bolts. (What percentage of automobile drivers could change their own crankshaft? What percentage of residential electric customers could troubleshoot voltage drop on a generator?)
That's why you, the expert, are there. You, dear people person, to be successful, must be a competent Computer Geek. Don't try to teach technology to your users. It wastes your time, and annoys the users. Save the acronyms, jargon, and 1337-5p34k for the tech groups. Answer their questions as simply and as directly as possible. Learn to recognize blank stares or nervous fidgets. If you see either, then you've gone on too long or shot too far over their head with your answer. Wrap it up or dumb it down. Communicate, absolutely, but let them be happy with the answer on their own level. An informed user with a fixed problem (or at least the knowledge that you're on the case) is a Happy User who will sing your praises. This is the lifeblood of job security and a pleasant workday. Cultivate it.
"Hey, the third matrix movie would have been good except for the plot,story, and acting." --AC