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.
In my early days in computer support, my manager kept a 'recipe book' of the things that commonly went wrong, and the fixes to them. Today this is known as the FAQ.
We were encouraged to add to this collective journal anything that we thought would help other helpdesk people, and to use it to help solve problems. This covered all the operating systems in use and any gotchas about making them interact.
As far as training goes, you need to know what problems you are trying to solve, then plan around those. The recipe book was a huge resource for the types of questions being asked and answered. We used the tools to raise our own questions, and try to solve the problems.
If you are supporting (for example) staroffice, then have the helpdesk people actually use it in their own work producing real output. Give them some time to work out problems among themselves. Don't pressure them do be as productive using the new tools as they were with their old favourites. This will give them a chance to apply any knowledge they may have of general principles from other office suites, and also highlight any needs to bring in expertise for training.
Another tool used by the same manager was to encourage game playing (and game writing) at suitable times on the systems that he wanted people to become familiar with. At different times, our team devised tetris for a dumb ascii terminal(!!) and an interactive game run in a spreadsheet(!!!) While all this was happening we were enjoying the pleasure of hacking while gaining useful (to the organisation) familiarity with systems that we otherwise may not have chosen.
Slashdot Mirror
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.
Is that an Amiga 4000 that you had years ago, or is it an Amiga you had 4000 years ago? ;^)
Every squid fisherperson has a story about one that was "thiiis biiig" ...but it got away!
In my early days in computer support, my manager kept a 'recipe book' of the things that commonly went wrong, and the fixes to them. Today this is known as the FAQ.
We were encouraged to add to this collective journal anything that we thought would help other helpdesk people, and to use it to help solve problems. This covered all the operating systems in use and any gotchas about making them interact.
As far as training goes, you need to know what problems you are trying to solve, then plan around those. The recipe book was a huge resource for the types of questions being asked and answered. We used the tools to raise our own questions, and try to solve the problems.
If you are supporting (for example) staroffice, then have the helpdesk people actually use it in their own work producing real output. Give them some time to work out problems among themselves. Don't pressure them do be as productive using the new tools as they were with their old favourites. This will give them a chance to apply any knowledge they may have of general principles from other office suites, and also highlight any needs to bring in expertise for training.
Another tool used by the same manager was to encourage game playing (and game writing) at suitable times on the systems that he wanted people to become familiar with. At different times, our team devised tetris for a dumb ascii terminal(!!) and an interactive game run in a spreadsheet(!!!) While all this was happening we were enjoying the pleasure of hacking while gaining useful (to the organisation) familiarity with systems that we otherwise may not have chosen.
Seems like a good idea to me too, but I'm sure that the tape drive manufacturers would like to sell more stackers for their existing range of drives.