Greetings Coachman ...
here are some thoughts that have worked well for me over the years ...
One of the hardest things for me to do, is to step back and let our Maintenance staff try to solve a problem without getting involved.
that “non-involvement” idea might be considered a mistake ... would you hand a student a math book and remain “non-involved” until he figured out all of the material on his own? ...
let me suggest an alternative technique that I’ve found to be VERY effective ... try watching the student’s approach to a problem while you “keep-your-hands-in-your-pockets” so to speak - and then “get involved” at key points along the way ...
for one example: suppose that the student takes a “correct” troubleshooting step ... by “correct” I mean that it was a LOGICAL step - taken in the RIGHT direction ... here I’d tend to “get involved” by asking why that particular step was chosen ... maybe (hopefully) the reason makes PERFECT sense - in that case, I’d try to reinforce the idea with a compliment ... if it was just a lucky shot-in-the-dark guess, then I’d tend to be much less complimentary ...
for another example: suppose that the student takes an “incorrect” troubleshooting step ... by “incorrect” I mean that it was either an ILLOGICAL step - or it was a step taken in the WRONG direction ... (for the sake of discussion, let’s suppose that there are no SAFETY issues involved) ... here I’d tend to “wait and see” ... specifically, I wouldn’t immediately “get involved” - just as long as the “incorrect” step won’t take too much time - or take too many resources - to try out ... basically I’d want to see if the student can realize - and recover from - his mistake on his own ...
suppose he DOES realize his mistake - or suppose that he DOESN’T ... either way, I’d still “get involved” at some point along the way (usually sooner rather than later) by asking why that incorrect step was chosen in the first place ...
was it because the student didn’t understand the basic concepts of what he’s working on? ... or maybe he misinterpreted something that someone had told him previously? ... or maybe just a dumb, wild guess that didn’t pan out? ... whatever - I’d try to help the student better understand the troubleshooting process by pointing out the differences between “correct” steps - and “incorrect” steps ...
“positive reinforcement” ... “constructive criticism” ... whatever buzzwords you want to attach to it, the idea is to help the student recognize the patterns between what WORKS - and what DOESN’T ... if he doesn’t appreciate those PATTERNS, then he’ll be doomed to using hunt-and-peck techniques forever ...
let’s look at another example this way: ... a machine is down - a technician is trying to troubleshoot it and repair it ... there are basically only TWO possible outcomes to that situation ...
(1) the technician is SUCCESSFUL ... so maybe he learned a lesson along the way - maybe he didn’t ... and life goes on ... or ...
(2) the technician is UNSUCCESSFUL ... so maybe he learned a lesson along the way - maybe he didn’t ... and again, life goes on ...
my point is that EITHER WAY there might have been MANY valuable lessons to be learned from that one experience ... but ... if no one was “involved” in watching - and reinforcing - and correcting - all of those individual steps along the way, how much actual LEARNING did the technician accomplish? ...
it’s sort of like the old debate on the “tree falling in the woods with no one there to hear it” ... if a student covers a new idea (either good or bad) and there’s no one there to reinforce it - or to correct it - has the student really “learned” anything? ... maybe yes - maybe no ... but personally I’d say that some constructive “involvement” can quite often pay off with big dividends ...
it’s hard to explain in just a few words - but I’m basically trying to draw a distinction between (1) “teaching” the student - and (2) helping the student “learn” ... in my opinion, most “teachers” spend far too much time “talking” - and not nearly enough time “asking and listening” ... even constantly encouraging a student to “ask questions” is often a losing proposition ... in many (most?) cases the student never considers that what he “already knows” is correct might actually be WRONG ... therefore, he sees no need to ask a question - and misses a valuable lesson ... in my opinion, it’s the INSTRUCTOR - not the student - who should constantly be asking the questions ... but then that’s just my personal opinion - I’m sure that others have their own ...
what I’ve found is that the students who have the hardest time learning NEW skills invariably have previous MISCONCEPTIONS about the subject stuck in their heads - and that these simple mistakes are keeping them from understanding the new material ... once that “junk” knowledge has been removed, you can almost SEE the lights come on upstairs ... I’m constantly amazed at instructors who keep repeating the same material over and over - trusting that somewhere along the line it will eventually “sink in” ... usually all it takes is asking the student a few simple questions to find out WHY he can’t seem to grasp the subject ... then quite often a slightly different explanation - or a quick demonstration - will remove the mental hurdles and succeed where mere repetition simply will NOT work ...
I know I have to learn to do this so they will learn, but
it sometimes leads to a lot more downtime.
congratulations! ... there aren’t a lot of managers out there who realize how much “on-the-job” training actually COSTS in dollars and cents ... for many plants there’s a constant battle between the “bean counters” who can easily track the cost of “training” vs. the “maintenance managers” who understand just what “in-house” training is actually costing the company in lost production, wasted raw materials, and in missed deadlines ...
in my mind, the word “troubleshooting” refers to a logical step-by-step process of systematically searching for a problem ... as an illustration, consider the material posted above by my distinguished colleagues brucechase and kamenges ...
Keith brought up the “direct consequential relationships” between some of the different items that Bruce had posted - and then he specifically mentioned a “solid consequential progression” from one item to another ... this is EXACTLY what I have in mind whenever I’m helping students learn “problem solving” and “troubleshooting” skills ... many of them get extremely frustrated with me when I refuse to let them hunt-and-peck their way through a lab assignment ... eventually I convince them (well, at least MOST of them) that “FINDING the problem” is not nearly as important as learning a “LOGICAL and SYSTEMATIC APPROACH to finding the problem” ... lucky guesses are great - when they work ... but when they fail, SOMEONE needs to know how to track the problem down ...
some technicians are GOOD at this type of thing ... others need help ... teaching people to “DO” is one thing ... teaching them to “THINK” (as you’ve apparently discovered) is quite another ...
The good thing is, these guys want to get better. I just don't want to let them down.
I’d say that you’re fortunate to have a crew with a desire to improve - and that they’re fortunate to have someone who wants to help them along the way ... that combination isn’t nearly as common as it should be - and I’m always encouraged whenever I find it ...
hope this helps ...
