This train don’t stop for trainers, this train

So. Whenever Your Humble Blogger attends a training session of any kind, the actual training takes a backseat to a sort of training connoisseurship. I have run training sessions, mostly small and always in person, and so I have not experienced the specific challenges of the webinar. This morning’s webinar was about the new version of the on-line catalogue.

Digression: Webinar? Webinar? I do not ever want to be the person to can use the word webinar without wincing. I am also going to keep putting a u and an e on the end of the word catalogue until they come and take my us and es away. I can’t reasonably defend the extra letters, but then they can’t reasonably defend the word. End Digression.

I have, however, prepared quite a lot of training sessions, and for similar sorts of things to this software. And I am stunned—seriously, I am stunned by how bad professional software trainers are at running training sessions. It’s their job. They run these things for a living. They should be good at it.

It’s not just the technical stuff. I mean, I do think that, having chosen to do the bulk of their training and meetings via webinar, they should be prepared to use the meeting software with a level of fluency far beyond the people receiving the training. I know it’s not their software, but it’s their session. I mean. If people attending are going to need to call in on a phone line, there should have been advance notice of that; if VoIP is an alternative, then the trainer should know (1) how to set it up, and (ii) whether it works. And there is no reason why a session that is slated to start at nine should wait for half an hour whilst the problem with one group of attendees is addressed. Seriously. If they don’t have tech people on hand to deal with that, then they aren’t serious about running meetings over the web.

So, in case any Gentle Reader finds herself doing this sort of thing, and you never know, this is the first piece of advice from YHB: Beginning your presentation by making the trainees doubt your technical competence whilst simultaneously making them cranky and distracted is bad. And by bad, I mean, worth putting some resources into preventing. This is spilling-coffee-during-your-job-interview level stuff.

OK, then: if a training session involves doing a database search, it is really, really important that the trainer plans out a sample search beforehand. I mean, if the point is to take suggestions from the crowd, to show how versatile the database is, that’s fine, but that would be after a search that has been vetted to make sure that it works the way it is supposed to work. Just as a f’r’ex, if you happen to be showing how tags work in a system, you don’t want to mention that you are interested in skydiving, set up a tag and then end up tagging one book about gay sex and one album of ambient music. Both items look pretty good, actually, but neither of them have anything to do with skydiving, and a room full of librarians is going to (a) notice that, and (2) be horrified by the idea of patrons putting wildly inaccurate tags on their items. Especially—and I want to emphasize this so I’ll put it on the reverse side of the page, away from everything else on the page, in parentheses, quotated, capital letters—especially when they are already cranky and think the trainer is technically incompetent.

Another Digression: If you are training people on library software, you should be aware that the idea of using folksonomy in the system is fraught with fraughtness. Like, add the tag fraught to almost any library tech in the first place, but when you are training a bunch of front-desk librarians about stuff users are doing to their card catalogue, you have entered the heart of the Fraught Zone and if you haven’t prepared your Fraught-fighting engines, you will never break down the fraughtifications. Seriously, you can’t walk into this situation without knowing that. Not if it’s your job. End Another Digression.

OK, here’s the tricky part: in any presentation, the Iceberg Principle comes into play: the audience should be convinced that what the trainer is showing them is the tip of what the trainer knows. The way to do this is to make it true. This means the trainer have to learn an awful lot about the program (or whatever) that is not going to be included in the presentation. This is not wasted. The primary reason why it is worth the company paying a trainer to learn all that extra stuff is that people are going to ask questions (ideally during the now I’d like to answer your specific questions and see what you want to go into in more detail part) and if the response to three of the first five questions is along the lines of I will make a note of that, find out and get back to you, the quantity and quality of the questions will drop off. And, furthermore, people will become convinced of their earlier suspicion: the trainer is incompetent. This is bad, and worth the money to avoid.

And that’s my real point. Once people think that the trainer is incompetent, they will be resistant to the training, and furthermore will think that whatever system they are being trained on is a worthless hunk of shit. It’s about mood and worldview and that. It’s about making the irrational part of people’s head work with the rational part. It’s kairos and ethos. I am utterly astonished that people who do training for a living don’t understand that. Do they think they are not engaged in persuasive speech? Do they not get any sort of training themselves? Do they not read the literature, see the responses in the sessions and afterward, attempt to improve? I can’t really accept that most people who do software training for a living are lazy bastards who can’t be bothered to do the necessary preparation, or that software companies routinely hire crap people and encourage them to run crap sessions, but that is my direct experience over several years, and the alternative seems to be that I’ve just had a bizarrely unrepresentative sampling, which isn’t much more comforting in itself.

Tolerabimus quod tolerare debemus,
-Vardibidian.