There’s only one long-term answer to the IT labor shortage, and that’s Tom Swift Jr. If you aren’t familiar with the series, Tom Swift was for science fiction what Nancy Drew and the Hardy Boys were for mysteries. Swift was a genius in his late teens who invented cool stuff, had lots of adventures, and always saved the day.

I grew up on the Tom Swift stories, and dreamed of doing stuff like that too.

If Isaac Asimov is to be believed (and if you can’t believe Ike, who can you believe?) there’s a very strong correlation between reading science fiction as a child and entering a technical profession as an adult. If, as a nation, we want more home-grown scientists, engineers and programmers, the long-term solution is obvious.

In the meantime, you need to hire some IT professionals, you can’t find them, and you can’t wait until the science fiction curriculum is added to the schools, kids grow up in it, and they graduate and enter the workforce. What are you supposed to do right now?

I wrote about the IT labor shortage two years ago, and to show you just how much influence we pundits have, very little has changed between then and now. The fact of the matter? There is an IT labor shortage, but it’s mostly self-inflicted.

Recruitment ads still specify computer science degrees and long lists of specific products. Why? Companies run too lean, hiring only when there’s a specific, urgent need. They can’t afford the time needed to retrain good employees or new hires. Voila! Instant shortage. When nobody is willing to train their employees, it’s inevitable.

For example, some companies are laying off their Y2K staff, who don’t have the “right” skills, while simultaneously recruiting other IT professionals who do — a process that may easily take three months and a $20K+ signing bonus.

Well gee whiz, kids, you are in a pickle, aren’t you? I wonder what would have happened if you’d spent the $20K and three months retraining the poor schmuck who worked his eyeballs out fixing your Y2K problems instead.

Are these companies really that dumb? It’s possible. According to astrophysicists, stupidity may be the “dark matter” that makes up as much as 90% of the universe’s mass. Unlike IT labor, there’s no shortage of the stuff.

But there’s another possibility.

Firing unproductive employees is difficult. It’s emotionally draining, procedurally intense, and legally risky. Sometimes, layoffs are smokescreens that allow companies to terminate employees who aren’t making the grade. They may be incompetent, hard to work with, or they may have just run afoul of company politics, but for one reason or another they’ve been labeled as “undesirable”.

Three decades ago Harold Sackman showed that the best programmers are 20 times more productive than average ones. Imagine what the other side of the bell curve produces. If you factor these folks out … and if you’re hiring, you should … you find another reason there’s a shortage.

One thing is certain. IT managers can’t find the people they’re looking for. So if you’re looking for work in IT, that puts you in the catbird seat. All you gotta do is to be that person. Which also means that if you can’t find work … and there are a lot of programmers and analysts who can’t … it’s time to take a long, hard look in the mirror.

Companies are hiring. If they aren’t hiring you, there’s a reason.

In the beginning was Electronic Data Processing (EDP). In EDP we wrote computer programs to automate business processes. Ignorant about methodologies, we just talked with the people who were going to use the system, figured out together what it should do, and tweaked things until everyone was satisfied. Eventually these programs turned into legacy systems.

Like baseball managers, most of whom once played the game, the guy who ran EDP was a former programmer who could talk to the company’s business leaders without scaring them. A lot of his conversations started, “Didja know …” as in, “Didja know we could automate that and save you a lot of money?”

Then database management systems happened, and some genius decided our real job was to manage information – a clear case of confusing means and ends. EDP became Information Systems (IS), the person in charge became Chief Information Officer (CIO), and theorists inflicted bulky methodologies on project teams. The result? Long delays before the writing of actual code, and an organizational hierarchy to separate programmers from the people who need their product.

Along the way we gave up on the baseball manager theory of CIO selection. Instead we focused on the need for “business knowledge.” If that wasn’t bad enough, we defined “business knowledge” as “understands how to perform a Return On Investment (ROI) analysis”. We got what we asked for: Late, bloated projects, fictional ROIs, and a management-fad orientation leading to the belief that late projects and fictional ROIs are fine so long as we “satisfy our internal customers”. Mired in these time-wasters, most CIOs missed the Internet. Oops.

So now we have Chief Technology Officers (CTOs).

Sometimes the CTO is the CIO’s peer, with the former focused on the Internet and the latter on everything else. This is worrisome from the organizational design perspective because it has strong potential for dividing accountabilities.

If your company insists on having both titles, minimize conflict by giving the CTO application-layer authority only, but responsibility for all customer-facing applications, not just the Internet. Why? If your CTO owns the Internet, your Telecommunications Manager (presumably re-titled to “CVO” for “Chief Voice Officer”) will own your interactive voice response and call centers, another bizarre title will own sales force automation, and the chance customers have of getting consistent service across all channels is exactly zip.

In most companies, though, CTO is the new title for “the person we hold accountable for all of our computer stuff”, accompanying a name shift from IS to IT. “CTO” implies rejection of a lot of the intellectual baggage we’ve accumulated since EDP first changed its name.

Like the EDP manager, but not the CIO, the business wants its CTO to have a strong technical focus, because that’s how you figure out what the business can do today that it couldn’t do yesterday. And where EDP lacked formal methodologies, in the CTO’s world they exist but they’re pretty lightweight, because the ones we’ve been using are way too slow. Mostly, programmers work with whomever to design the customer interface, then work backward to design the system’s innards.

Best of all, CTOs reject the whole, ridiculous concept of “internal customer”. They’re far too busy worrying about real ones.