Are You Getting Enough Say In Your Training?

DrEducator asks: "Has your company ever contracted external instructors to train its programmers? Have you been satisfied with the lecturer's level of expertise? I think we all have a good grasp of how vital the role of training is to both a corporation and its employees, but given its importance should you have more of a say in selecting or evaluating instructors before they deliver training? I firmly believe in the tenet that 'geeks should train geeks'. Moreover, I think that the geeks themselves have to take a more active role in the whole process. So, I'm curious - do you think you have enough say in your training? Do you actively refer instructors that you've seen at conferences or previously taken courses from (university, college, or adult ed)? If not, have you had the opportunity to interview an instructor, or at least review their qualifications? Share your experience - how much input do you want/need/have?"

Comments

of course

[tanveer1979]

yes you are right. But mostly while delivering such training programs the company has a number of constraints.

• Current Market demands
• Project Goals
• Long term investment to gain ratio
• Value addition Index

So though geeks for geeks is a good idea, managers need to intervene. The right balance should be struck between employee gain and company gain.
But then deciding is not a easy job, and in my expirience employee gain is sacrifised for company gain.
One option would be to be slightly more vocal and talk it out.
The complete geek way is also not theway to go coz then company wont gain everything.

Re:While "Geeks should train geeks" might seem ...

[CynicTheHedgehog]

I recently attented API training class offered by one of our vendors. It was a 3-day class taught jointly by a customer representative and one of the engineers. The first day ran smoothly; the representative managed to make the class personal and comfortable, and he seemed at home with the slides and printed material. He deferred most of the questions to the engineer, who clumsily spat out biased answers and misinformation. The rep had to leave on some personal errand on the second day, and the class dissolved into a programming exercise reminiscient of a 10th grade BASIC class, wherein the engineer spent all of his time hopping from desk to desk trying to get things to compile on an IDE none of us was familiar with. The agenda and printed materials went right out the window. We learned no new material that day.

The rep stayed at a pretty high level, but it was useful background and it was organized. Between him and the engineer I learned quite a bit. I a figured out a few things myself while I was fighting code on the second day, but not as much as I would have had there been some semblance of order. I much prefered the rational, methodical training offered by the rep and the printed materials to the chaotic, hands-on approach of the agitated engineer.