Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Education

What Qualities Make Good Technicians? 14

rderek asks: "I am an instructor at an educational, and my focus is on computer technicians (not sys-admins). The course that we run is very demanding, and produces (we think) very good techs. We are allways in the process of adjusting our cirriculum to remain current, but it may be time to adjust our teaching process. What we want is not simply to create people who know how a computer works, but who also have the attitude and mindset of good technicians. I would like to know what each of you consider to be the qualities necessary for a person to be a good tech."
This discussion has been archived. No new comments can be posted.

What Qualities Make Good Technicians?

Comments Filter:
  • by He Who Suffers ( 260461 ) on Sunday February 25, 2001 @04:21PM (#403900)
    Having worked as a tech, in a variety of organisations, I have noticed that my colleagues with the 'right stuff' were all very curious about how things are, and how they work.

    Any new toy^H^H^H piece of equipment that comes into the office has the lid opened to check for new stuff. Articles about novelties must be followed up - it took me weeks to search out enough information to be comfortable with how sterling engines run.

    Much to the distress of my mother, I must plead guilty to having a track record for pulling things apart from a very young age, but mostly putting them back together in a working state. Of my friends who are techs, most have the same story.

    Hardware of all sorts is fascinating. The first time I see anything new, I find myself thinking out how such a machine would operate. If it is not immediately apparent, then the lid must come off, or the plans be searched out to satisfy my need to know. In this way a general knowledge is built up so that tech people have a feel for what is right, and get hunches about a faults, that then pay off when repairing unusual faults.
  • Exactly! Another important part I think, is having a gut instinct on how something is meant to be. Even if a good tech doesn't know how something works, having the instinct about how it must work, is very important for making a new toy work. Once you've got the basics down, then you start working on the fine details, by RTFM'ing or something lame like that =)
  • IMHO, i think all technicians should read Zen and the Art of Motorcycle Maintenance. Excelent book discussing the qualities of a good mechanic(which all geeks basically are, computer mechanics) and the philosophy behind the mechanic's lifestyle. Some parts are rather irrelvant or boring but, most of it is very interesting.
  • Curiosity is definately a personality type that helps, but as for teachable skills, I find that the ability to quickly disect and isolate a problem has been most helpful to me.

    I went through a Mechanical Technologist program at our local tech institute and the problem solving skills used throughout engineering disciplines are useful for isolating and locating problems.

    For a fun in-class example, use the old game 20 questions. One person thinks of anything they want, and the other has 20 questions (yes or no answers only) to guess what the other is thinking of.

    If it takes more than 10 questions, then you need more practice.


  • In my job as Hardware support on Sun enterprise class systems, one of my most important abilities is being able to handle stress effectively. In certain situations (i.e production machine crash) I have to remember to stay as calm and level-headed as possibly no matter who might be pusing for a resolution such as a CEO or upper management. So i think a good teachable skill is being able to handle that aspect of the job while still performing the main task of repairing a machine. It seems to me at least me persoanlly, the hardest part of my job is handling all of the red-tape associatied with my job, such as conference calls, long meetings, and project managers. It is easy to get frustrated having to deal with all of that especially if you arent acustomed to dealing with it.

    Just my .02
  • Keep in mind, of course, that their careers will take them to see hardware that is beyond what you might be able to show them. Teach them how to narrow down the focus of their problems, and how to deal with the unexpected.

    In other words, don't teach solely with textbooks. Use real-world examples. See if you can give labs where you create a problem, and they try to fix it. Teach them how to teach themselves new things - give them enough to get started, and try to hone their instincts to be able to isolate causes, not just symptoms of the problems.

    Also teach them that "I don't know" is an acceptable answer. Too many technicians get so caught up when they don't know an answer that they begin to blame problems on totally unrelated things (ie: I can't connect to the database. It must be that damned Linux box on the network causing the problems - and yes, I've heard this one). Teach them how to research their issues. After all, the wisest of people don't have all the answers, but rather they know where to look or who to ask to find them.
  • As a tech working for a consulting firm
    that often gets called in on business
    critical outages i think the most
    important and hardest skill iv had to learn
    is how to handle people in a stressfull
    situation. With fellow puter geeks it is
    easy but 99% of the time it wont be a
    puter geek your dealing with.
    I have seen some awesome techs that were
    no good in the field because they didnt
    have the people skills needed to deal
    with non-technical people in a stressfull
    situation. I have also seen some lousy
    techs that get good reviews from clients
    because they have a good "computer side"
    manner.

  • by Get_Plover ( 78671 ) on Sunday February 25, 2001 @10:46PM (#403907)
    seems like there are at least (2) types of tech - those who work with the afflicted machines in a shop/back-room and those who do the same under a barrage of human induced stress at client sites. Clearly the latter is more difficult, so a good tech ought to recognize early on whether they can manage themselves and others; stay in the back rooms if not. here are some things that proved helpful:
    Whenever meeting a client, regardless of situation, i usually find myself in stronger positions when i've kept my mouth shut - meaning only that they will almost always ask "do you think its xx or maybe Z?" - Safe answers sound something like..."I don't know, could be. You have my full attention now and I'm sure we can straighten this out." . Expounding with a client on all the things that COULD be wrong wastes a lot of time. Get used to " I've not seen that before. Tell me about the.... " --sometimes helps to seem a little impatient with the conversation ( if it seems pedantic), to keep walking toward that which is misbehaving.
    Helpful too is an ability to nicely shut them down when they begin relating the long list of corrective measures they have already undertaken to fix the problem. i don't mean to say don't listen to them (one MUST!) instead initiate and control the verbal exchange with something like:
    " You may have taken steps to correct this but please understand that even if you did I MUST be thorough... which may even mean repetition of some of your actions. I know this may be difficult but you will only distract me and prolong the analysis by bombarding me with questions. Let me ask you questions, and you try to be concise with the replies- we'll figure this out." --Clients like to think they played a part in finding the solution. Often they do.
    -Empathy helps too. especially with MS products. <scratch head> "I am as perplexed as you, let me scan the newsgroups and see if anyone else has this problem" <--buys time.
    A cardinal rule- never insinuate that anything anyone did was "stupid" either outright or by tacit agreement. This goes on alot. The bigwig or your contact or a guy who walks up to check on progress may be trying to cast a co-worker in a bad light, don't provide the ammo. everyone has expertise in their arena, recognize that, try to give credit to people for any positive actions and remain neutral.
    and don't forget to eat beforehand if you think its gonna be a long one....

  • I think it is substantial for a technician to understand how things work.
    I remember a dialogue between me and a colleague some weeks ago:

    Me: "Now I've got something strange: everything works the way it should, but I don't know why."
    He: "So be happy, this is everything you want."
    Me: "I don't think so."

    As a technician, you should not be satisfied if things work - you have to know why they are and, in the case that they don't, how you get them working.

    Just my $0.02.
  • I've worked in the Systems industry for almost 8 years now, and I've had the opportunity to work with other technicians, consultants, trainers and administrators. I've seen good and bad hardware and software and support technicians. I think one of the biggest problems that you can find with hiring technicians is that they are not consistent in performing job functions. You may not need a genius to swap out boards and plug in cards, but you do want someone that can follow through with his tasks and can perform regularly.

    I've met a lot of younger techs that are really sharp, but have a lot of attitude and do not follow through on tasks. I would look for professional technicians with open attitudes that can work well in team environments with little leadership and that are consistent in performing their jobs' functions.

    -Pat

  • I'll be honest: I think the best techs have aptitudes and a mind-set that can't be outright taught in a classroom. Some students will have the gift, most will not. The only thing you as the instructor can do is learn to recognize which students DO have the gift.

    A technician with the gift easily deduces answers about the inner-workings of an unfamiliar system by observing and experimenting. One without the gift will shrug and insist that without a user-manual or a technical support number he/she cannot learn anything new about the system in question.

    There are other signs, but in general this is IMHO the most noticeable. Some students who have the gift need to be more enticed than others in order to be discovered.

    The most effective way I've found to help students discover the gift for themselves is to present them with a "hypothetical" system and ask them how *they* would engineer the system to make it work a certain way. Then show them how the "hypothetical" system actually *was* engineered. Do this over and over building upon each lesson with a new "hypothetical" system. Soon some of the students start to predict how the systems work without you having told them. That is when you *really* know that they understand the systems they need to work with.

  • The best technicians I've ever known always have two lists in their head:
    1. What are the possible causes of the problem and how likely is each one?
    2. How hard are these to check?

    The best technicans balance these, usually picking the most likely cause of the problem first, then working their way down. Occasionally, they will take an "easier" thing to check because it'll take less time. Correctly balancing these lists often leads to the quickest, process-of-elimination style victory.

  • In particular it is important to be humble enough to be methodical, and check the simplest things first. I believe this is true for technicians, motorcycle mechanics, engineers, medical doctors, detectives and computer programmers. Maybe it is true for Zen buddhists too.
  • Since when is ANY hardware FREE? And why do you have such hatred toward Sun?

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...