Not Just "How?", but "Why?"

I was talking with my coworker, Stephen the other day about him teaching an internal "Intro to Python" class. He asked what I'd like to see in that class, and when I thought about it, the answer was simple: "How does this make my life easier?"

I feel like that's the oft-overlooked part of most training. I wrote lots of training when I was working for MAD Security/The Hacker Academy, and I have taken a nigh obscene amount of product training throughout my various jobs over the years. I've seen a lot both good and bad training, and it usually comes down to how well it answers not the how, but the why. A common trap that training tends to get sucked into is that they spend a tremendous amount of time on the "how?" of whatever it is they're training on, but totally neglect the "why?".

Going back to the Python example, I spent 2 years as a Computer Science major back in college. I took a year and a half of classes on Java, and a semester on C++. As a result, I'm pretty familiar with the basics of programming. I like to say that I can read code, but not write it. I learned how to declare variables and arrays, create functions, and all sorts of other things. But I always struggled with the "why?" of those classes.

It's the same thing that frustrates me these days about product training. I spent the past few years as a consultant, which means I had to get comfortable with lots of really cool products. These are products that promise the moon in a box if you talk to the sales guys, but when you sit down to go through the training, they spend the whole class bogged down in how to set up the IP addresses, or configure backups. That's all well and good, but well written documentation (don't get me started on that) can take care of that. As a student, wouldn't you rather see just what a tool is capable of? How it can make a network more secure, or how a programming class can help automate things you do every day? Part of why I'm interested in a class on Python right now is because Editorial uses it for workflows.

But here's the thing: as someone who has written tons of training, it can be incredibly easy to overlook that simple question of "why?". I was asked to put together a few slide decks on a tool I had been using full time for a year, and it was incredibly difficult for me to get the thoughts on paper because they seemed so basic to me. Once I had, I had to go back to them to put in use cases, because the need for them didn't even occur to me when I was writing the slides. Once I realized that, though, the whys came to me quickly and the training was much better for it.

So the next time you're sitting in a training class trying to figure out what the point of it is, try asking the instructor why you would want to do the thing that they're so explaining. You'll probably get a neat answer with a story behind it. And if you're the one responsible for writing training, try making sure that all of your training answers not just the "how?" of whatever it is you're teaching, but also the "why?".