Awhile back I wrote a column differentiating responsibility, accountability, and blame. In case you missed it:

Someone takes responsibility for a result — it’s up to them to make sure it happens. You hold someone else accountable — it’s what you do after delegation, to make sure whoever you delegated it to lives up to it. You blame someone after the fact, as a pointless alternative to fixing the problem. People who spread blame rarely accept responsibility for anything. It’s always someone else’s fault.

Which is a problem with the current debates about the IT labor shortage. Too many out-of-work IT professionals would rather blame age discrimination and employers who prefer H1Bs than take responsibility for being more effective applicants. Hiring managers would rather blame a lack of qualified applicants and unduly strict H1B limits for their staffing woes than take responsibility for failing to train the employees they have. And nobody is holding corporate recruiters accountable for methods that are demonstrably ineffective.

The root cause of this fiasco is not in doubt: It’s the recruiting industry’s insistence on precise skills matching — and worse, on automated skills matching — as the preferred way to screen resumes. Heck, if staffing is simply skills inventory management, let’s give the Purchasing Department responsibility for recruiting. After all, Purchasing is good at replenishing depleted inventories for a fair price.

Okay, we all agree, right? It’s Recruiting’s fault. So you’re an over-40 Cobol programmer who’s out of work. Do you think you’re off the hook?

Of course not.

I get a lot of mail from angry out-of-work IT professionals. Their old employers didn’t give them a chance to update their skills; they have good skills but can’t get past HR’s screening; they get an interview but can’t get hired because twenty-something hiring managers can’t cope with their advanced age.

I sympathize. I really do. Which is why I offer these words of empathy and encouragement:

Tough bounce. Get over it.

If you can’t get hired in today’s job market, there’s only one possible conclusion to draw: You’re doing something wrong in your pursuit of employment.

For example, are you reading recruitment ads and sending your resume to HR in response? Don’t be a schmuck. Maybe one job in ten is filled this way. Don’t even waste your time.

What should you do instead? Here’s one strategy you might try: Sell yourself as an independent contractor. Independent contractors don’t deal with HR. They sell to those who are buying – managers who need more people than they have.

So look at the recruitment ads and call whatever managerial title seems most likely to be the hiring manager. Don’t request an interview for the job. Consider not acknowledging that you know there’s an open position. Just offer your services for a fee.

Huh? You don’t want to be an independent contractor? That’s fine. Offer a “try before you buy” deal — you’ll serve as an independent contractor for six months, so both of you can decide if it makes sense to bring you on as an employee.

Independent contractors don’t interview — they sell a product.

What exactly do you think a job search is, anyway?

I’m mad at Bob Metcalfe.

But first … IS Survivalist Roger Crawford points out one of Microsoft’s business practices that’s even more unfair than its antitrust shenanigans, namely, how it describes new products or product plans: “We are developing product X that does functions a, b and c and we expect these types of people to use it.”

Its competitors, who say things like, “We intend to leverage our strengths in the buzzword arena to provide our customers with the tools they need,” are handicapped, because it’s never quite clear what they’re planning to produce, nor for whom.

For fairness’s sake, the courts should prohibit Microsoft from clearly explaining its plans ever again. Based on what I’ve read so far about Microsoft.NET, it appears the Redmond contingent is already complying, because just what the heck are they mumbling about, anyway?

As soon as I read about Microsoft.NET, I thought, “This is Microsoft’s SAA!” I figured I’d write about it eventually. Metcalfe had the same insight, though, so there goes my claim to originality. Nuts.

If you don’t remember SAA, it stands for “Systems Application Architecture”. IBM, in the early days of its implosion, developed it to do for applications what its Systems Network Architecture (SNA) had done for networking: Provide a standard architecture IBM could control. SAA wasn’t a product. It was a framework within which IBM’s future products would, in theory, fit.

IBM’s core strategy was to control architecture. Even when companies bought non-IBM components, everything fit the IBM model for functional elements, specifications, and interfaces. The strategy worked because you could buy every component from IBM if you wanted to. SAA failed because the only thing IBM had was intentions.

Sound familiar?

Microsoft.NET is a non-starter. Ignore it. If, miraculously, it succeeds, you’ll pay little penalty for waiting. You have absolutely no reason to be an early adopter (and of what? There’s no product!), and lots of reasons to wait and see what happens.

But this column isn’t about Microsoft, nor IBM, nor, for that matter, about Metcalfe’s beating me to the punch. It’s about you and your IT organization.

Take a look at your mission statement, vision statement, strategic intent, program charter, or whatever defines what you’re trying to accomplish these days. While you’re at it, read some of your recent communications. Does it all look like Microsoft.NET, or does it mean something?

Meaningless visions like Microsoft.NET are punishments for the sins of our forefathers. American industry, paralyzed by a generation of bottom-line managers who couldn’t see past financial statements, awoke one day to the need for vision. Ever since, every self-styled leader in business has made sure to start at least one sentence per day by saying, “My vision for this is …”

Don’t do that. Let others decide whether you’re a visionary or not. Your job is to paint a compelling vision for the future. While it’s tempting to be an artist, painting blurry abstract swirls others can interpret as they choose, abstract artistry isn’t leadership. It isn’t vision. It’s Microsoft.NET.

Grand visions are wonderful things. But if nobody can figure out that you’re developing product X, with functions a, b and c, you aren’t a visionary.

You’re just daydreaming.