Open Source

Breaking out of the training catch-22

Here's the catch: Your team lacks the skills to work on the hot new project. But senior management won't approve training because they aren't working on a project that required those hot skills. Let Bob Artner guide you around the impasse.


Call it the training catch-22. You can’t get your team assigned to the hot new projects because they don’t have the necessary skills. However, you can’t get them approved for training on the new technology because they aren’t working on those new projects.

So what do you do? I suppose you could you just put your head down and keep slogging through the department’s maintenance technology projects. However, your team members won’t appreciate being stuck on low-interest efforts and won't appreciate seeing their skills (and market value) atrophy. For that matter, it won’t do your career a lot of good, either.

In this column, I’ll give you some strategies for getting around this impasse and tips on justifying training for your team.

Start with a skills inventory
Answer this question: How do you determine which skills your people currently possess? If you’re like many IT managers, your approach isn’t very systematic. You start by looking at the current mix of projects and responsibilities that your staff has mastered. If you hired many of these folks, you might remember from your interviews (or their resumes) what other kinds of work they did for previous employers.

If you haven’t done so already, I strongly recommend that you do a skills inventory of your staff. Chances are, you’ll be pleasantly surprised at what you find. After all, just because you haven’t assigned them a project with a particular technology doesn’t mean that some of your staff doesn’t have good experience with it.

As an example of what I’m talking about, consider the research survey TechRepublic did not too long ago on Linux in the enterprise. (If you’re interesting in purchasing the entire survey, here is some more information.) One of the surprising discoveries we made during our research was that organizations were much more likely to be able to support Linux than they were to have already deployed Linux. As the chart indicates (see Figure A), almost half the survey respondents indicated they could support Linux.

Figure A


We believed that one of the reasons for this finding was that many IT professionals taught themselves Linux on their own time because they were interested in the open source phenomenon in general and Linux in particular. Since we did the research, I’ve wondered more than once if TechRepublic knew more about the Linux capabilities of some IT departments than the people running them!

So before doing any request for training, find out precisely what your people can already do. Once you know that, here are some other things you can do to build support for additional training.

Do a demonstration project
Demonstration projects are how a lot of IT pros brought Linux into their organization. They found a server that wasn’t being used, installed Linux on it, and used it to run some applications that were internal to the IT department. After doing that for a while, they would let their supervisors know and use their work as a justification for additional investments in Linux.

While this kind of “skunks work” project is usually designed to sell a new technology or hardware, it can also help sell your boss on the need for training. You could say something along the lines of, “Look at what we were able to do with just 20 percent of my staff trained on this technology. If we could increase that to 100 percent, think of what we’d be able to do for you.” It goes without saying that you need to make sure the demonstration project is dead-bang perfect before showing it to your boss.

Tie your training request to a strategic initiative
Most organizations publish an annual list of strategic goals or initiatives for the upcoming year. Even those that don’t have such formal objectives often have informal goals. When it comes to funding your department’s training, finding a tie-in between your request and one of these goals can only help.



Build cost of training into your project's funding request
Building the cost of training into your funding request isn’t a new idea, but it is a good business practice. However, as most of us know only too well, if a project starts to come in over budget, training is often the first thing thrown over the side. The thinking seems to be, well, let’s get the thing done and come back and get the training funding later. While that approach might work for some, my experience has been that senior management is most enamored of a project while it’s under way. After it’s launched, they are focusing on the “next big thing.” In that kind of environment, you’re unlikely to get the funding afterwards. Better then to keep the training budget in the project and fight for the original request.

Don't wait for your boss
Whatever you do, don’t wait for your boss to solve the training quandary for you. As I said earlier, if your team can’t get the training to support new projects, they’ll be stuck doing maintenance work. And you’ll be stuck right there with them. Don’t forget that it’s your career, too.

Editor's Picks