The growth in online courses is truly amazing. You can learn pretty much anything. I think that people with extensive IT experience in an enterprise environment are perfectly situated to create courses, provided they avoid some of the beginners' pitfalls (all of them mistakes which I have made).
These tips are aimed at the very many IT people who are able to offer online training through a series of emails, short videos or podcasts. But the following tips (mainly the result of the lessons I've needed to learn) aren't just for online courses. They can be helpful in a job interview, or in your annual performance review in your existing job.
Here are the tips I wish I had known before I had ever thought of writing a blog or putting together an online course:
Tip #1: Solve a Specific Problem
It's a funny thing about technical people. Throw us a technical problem and we're ready to dive straight into it to solve it. So what is it that makes us want to write about the big picture topics? If there's one piece of advice that applies to creating an online course, it's this: solve a specific problem.
Now that doesn't mean you have to solve every problem. Just mine. Or somebody's. The more specific the problem and the more specific and concrete the results, the more traction you'll get.
So, for example, instead of:
"How to improve your IT processes"
you could make the course:
"How to close off five problem tickets in 17 minutes."
The idea is to give people a concrete take away.
This blog has been running on and off since 2009. The top post with over 56,000 visits was about a single command - getconf - which displays the size of a disk. Concrete solutions win. Technical how-to tips win. Give me something to take away quickly and tell me why it's going to save the world.
2. Make it short
If you don't want to boil the ocean with your topic, you also don't want to with your content. A series of three emails is enough to get people interested. Or even a three-part blog series. It helps you to guage the interest to see whether there's an audience for something more substantial.
If you have an IBM developerWorks blog such as this one, it's got a couple of great feedback loops. One is that people can add comments which is a great way of refining your content, building your profile online and, most of all, engaging with your readers.
Another excellent reason for a developerWorks blog is that you get to see the number of visits for every blog post ... and so do your readers. Not that you're going only for numbers. Still, it's nice to see what's hot and what's not when it comes to topics and writing styles.
3. Address the Pain and the Problem
Whether you're preparing an online course, going for a job or trying to get onto a particular project in your current job, this is a biggie.
Don't focus on your skills alone. They're not so interested in your skills as they are on solving their problem. In fact, if you talk mainly about your skills, you're leaving it to the employer / project manager / course student to translate that into addressing their problem. If you do that leg work for them, you're far more likely to arouse their interest.
But how do you do that?
Easy! Speak to their pain point. Empathise with them. Make it clear that their pain is your pain, and that your solution or skills are going to help them through their pain.
Now this is important. They're actually more focused on their pain than on their problem. That's why people will go for a temporary solution, a workaround, if it solves their pain ... even if it doesn't fix their problem. "I've stopped getting alerts about my full file system, so let's move onto the next crisis." Ah yes, they've stopped getting alerts, but that's because the alerts have been turned off, not because the file system now has lots of free space.
You, however, don't work like that. You want to get to the underlying issue: the real cause, not just the noise that results from it. You may be able to get to the real problem behind their pain. But they're focused on the pain. So this is a delicate balance: you (the techie) want to fix their problem, but they are after someone who is going to fix their pain. If you can manage both the pain and the problem to make them both go away, you're much better than the guy who "fixes" the problem by turning off the alerts.
You're a surgeon, not just an anaesthetist! So the real money is with those who can wear both hats. It's about problem management and pain management.
Now, I said to make it specific, so let me do that myself right now.
Pain Management 101
Supposing you know that there's a data centre migration project, and the company is running behind time and over budget. Every month that they are still in the old data centre is costing them hundreds of thousands, or maybe millions. That's the pain to talk about.
So, maybe you've done these data centre migrations before. And you've found a way that will shortcut the process. For instance, maybe someone is trying to copy the data from a database to a staging area, and then copying that dumped data to the target system. What if you were to come up with a way of turbo-charging that write to the staging area? Or maybe even bypassing the copy to a staging area altogether?
Now if you're working on AIX, you could speed up the staging area by making it on faster disk, or perhaps turning off JFS logging, or even increasing the queue depth on the disks. The thing is not to jump into the technical details of how you're going to do that. Instead, you can put it this way: "how about we reduce the time copying to the staging area by 40% (or 20 hours or whatever metric you can come up with)?" The project manager probably doesn't know about the queue depth or the JFS logging, and maybe doesn't even want to know. But he may very well be interested in a process that is going to slash the time it takes to copy his biggest database.
That's one way of focusing on the pain but still addressing the real problem. Deal with the pain and the problem and both of you can walk away happy.
4. Offer a short free course
The free course seems to be counterproductive. After all, you're probably in the game to make some money. But offering a free course helps you build an audience and build an email list. Most people are going to come to your web site 8 times before they buy for the first time, so you want to make it easy and inviting for them.
5. Don't let me talk my way out of it
Do you know the number 1 reason people won't sign up to your course? No, it's got nothing to do with the quality of the course. It's this: they're wondering if it's right for them. Sure, it's a great idea offering an online course on how to optimise your SAN with your IBM Power System, but would this be right for me? Maybe my SAN doesn't need tuning. Or maybe it's somebody else's problem. Or maybe it's a good course, but I'm too busy or not technical enough to be able to follow it.
That's why you need to guide me, step by step. Concrete, simple steps that walk me through the process.
6. Use Case Studies
Related to tip #5 is this: if you want me to sign up to your course, I need case studies that help me associate your experiences with my environment. The more I can relate to your customer, their problem and their pain, the more I'll say to myself: "wow! That's exactly what I'm facing." But be careful, though, not to reveal anything that could in any way be considered the customer's IP (intellectual property) or even identify the customer without their explicit permission.
So, for example, if you want to show in a case study how your upgrade methodology saved the IT team 15 hours per logical partition, it might be fine to refer to the customer as "a major retailer" or "a large financial institution".
The point is that people want to see not only what you've done for others, but what you can do for them. You've got to deal with that demon that is whispering in their ear: "sure, this is good and interesting, but my situation is different. I'll think about it."
Power People are Well Poised
If you've been working on IBM Power Systems for a while, then chances are you've worked with many different teams, such as SAN teams, network people, application teams and so on. That already gives you exposure to a world of IT that many players in smaller, or home-based, businesses may never get to see.
The business experience you have from working on IBM Power Systems, maybe across large and small environments, makes it pretty likely that you've got finely-tuned antennae when it comes to business problems. Perhaps you can translate technical solutions into business solutions by making it easier for a decision maker to see how your work will either save them money, make them money or make them safe. And that makes for a very interesting course topic, or job application, or career path.
The more you can connect your course content to the customer's problem, and especially address their pain, the better chance you have of building an online course that is going to generate a lot of interest.