Policies and Procedures – Page 128 – IS Survivor Publishing

IT labor shortage, or IT smart hiring shortage? (first appeared in InfoWorld)

I spoke recently at the Making Statistics More Effective in Schools of Business conference. My host, Jon Cryer, figured the odds were pretty good that I said something useful. Since he teaches statistics and authored a nifty CD-ROM to help with the teaching process, I trust his judgment.

Flushed with success from having talked to a bunch of professional statisticians I’m ready to take on yet another ridiculous statistic floating around the industry. That’s the supposed deficit of a-whole-lotta IT professionals we’re trying to overcome these days.

(Ironic tidbit: While lots of readers responded to my recent columns on Microsoft by restating the BIG/GAS theory (“Business Is Good/Government and Academics are Stupid”) saying government should just stay out of things and let business handle it, lots more are blasting the government for considering a bill that would allow more foreign IT professionals to compete for jobs in the U.S.A. I guess the government does have a role to play after all … protecting our jobs from a free market.)

What does the job deficit mean? As calculated, it means we create many more jobs in IS/IT each year than we graduate computer science students. Where, the doomsayers ask rhetorically, will the rest of the talent we need come from?

Answer: The same place they’ve been coming from since before I entered the field. As regular IS Survivalists know I learned to program analyzing data I collected studying the behavior of electric fish. My co-workers in my first job in industry were a former meteorology student and a former marketing analyst, and we built systems as fast and successfully as any of our co-workers.

Before you read any more of this column, take a look at your open job requisitions. Do they ask for a computer science degree? Probably. Does the job require a computer science degree? Probably not.

The people you’re hiring will analyze real world problems and envision solutions that incorporate information technology where appropriate. They’ll design system architectures, legacy system integration strategies and effective user interfaces. They’ll code, compile and test applications. They’ll help end-users solve problems, too, and troubleshoot network problems.

A few of these jobs would benefit … not require, you understand, but benefit … from a computer science degree. Many would be better off with a student of physics, anthropology, or international studies who figured out how to use computers creatively to solve real problems.

The position you have open may not require any college degree at all. Despite decades of evolution, we’re still designing databases, business logic, legacy system interfaces, user interfaces, and reports. Yes, these tasks require a level of sophistication. I’ve worked with quite a few trade school graduates who did a fine job at them.

You can fill other positions with “power users” — non-IS professionals who have learned to use computers on the job and figured out lots of innovative uses for them during the years IS ignored personal computers as pointless toys.

When you create a position description that includes the phrase “computer science” anyplace on the page, you’re begging human resources to screen out hordes of candidates who could succeed in the job. Think of it this way. We know we have a shortage of computer science graduates. We don’t know if we have a shortage of candidates who would succeed if we gave them the chance.

Some positions may go unfilled for three to six months while you wait for the perfect candidate. If you choose someone less qualified but who has the right smarts, attitude and motivation, you could provide enough training in a month to make up the deficit.

Then you’d have a smart, motivated, very loyal employee with a good attitude.

A few pointers about Extranets (first appeared in InfoWorld)

Some ideas pop up in every culture.

An old Islamic proverb advises you to “Trust in Allah, but tie your camel.” Former President Reagan translated the Russian version — “Trust but verify.”

And we chip-heads have extranets.

I gave my first speech about extranets to the Minnesota Telecommunications Association in 1993, not that I was smart enough to coin the term.

It was a simpleminded speech. The World Wide Web was just getting started, e-mail gateways were expensive and unreliable, and the office suite wars were still raging with no clear winner yet in sight. So I guessed wrong on many of the specifics. The key point was right, though. IT’s focus was typically internal — on WANs, which improved communications with ourselves, not on ways to improve communications with customers.

An extranet is a private network connection between two or more companies built around standard Internet technologies. I’ve recently moved from speechifying to setting one up, finding out first-hand that successful extranets have some tricky, trust-but-verify-related design issues. For example:

Security policy: Does yours describe the level of trust you assign to your customers’ employees? You can’t toss this problem over the transom to your security group either: Their job is to implement your security policy, not to create it.

Firewalls: You need one per company, of course, not a particularly sophisticated insight by itself. Each company needs to protect its network from its trusted partners. Don’t, by the way, economize by using the same firewall for your Internet and extranet connections. Each implements a different security policy. Internet users are total strangers. Presumably you trust extranet users more.

Authentication servers: If an extranet is a good idea for one customer it’s a good idea for lots of them. And once you’ve established an extranet connection to two customers, you’ve connected their networks to each other. They may even be competitors.

Authentication servers restrict the use of extranet connections to trusted individuals, protecting your customers from each other. A key point here: Your role is to encourage your customers to implement this technology. They each have to install and administer it. Otherwise you’ve taken ownership of their network security, along with the liability if something goes wrong.

In the Fun-You-Don’t-Need department, think about compatibility testing. Authentication servers require client software on every system that accesses the extranet. Different customers may choose different authentication servers.

Server ownership: In some cases this is a non-issue. What if you’re running a joint project, though? Like a lot of issues, this one’s easy to resolve if you remember it. One company or the other owns and administers the server and puts it inside their firewall.

Mobile users: This is the toughest design issue your network engineers face. When you’ve established a joint project team and a customer’s team comes to visit, you should be able to provide desks and network connections. They should be able to work without right-clicking on Network Neighborhood to reconfigure their IP settings.

Problem resolution: Don’t forget this one. Although every device on your extranet may be fully managed, the end-to-end connection is not. When something fails, nobody knows whose device is at fault. You’ll need reporting and escalation procedures. Probably, each company’s employees will call their own help desks. Instead of pointing fingers at each other, the help desks will work together to solve the problems.

And last but by no means least: Make sure everyone involved knows why you’re doing this. “Improving communications with our customers” sounds really great, but as Gertrude Stein said about Oakland, there’s no there there. If you think through the tangible benefits up front, everyone involved will know what they’re trying to accomplish.