Snippets from an email exchange about the H-1B visa program, edited and paraphrased for length and suitability:

Correspondent: Have you ever weighed in on the H-1B Visa concern that bedevils American IT workers? If not, why not?

Bob: It’s a complex topic I know far too little about to express a useful opinion. As someone once said, better to remain silent and have people think I’m a fool than to speak and remove all doubt.

Correspondent: I urge you then to please do research the subject and then speak out, hopefully in favor of the American citizen IT worker. I fear if outsourcing continues this may inadvertently decimate the pool of available native STEM workers who may avoid pursuing STEM professions due to frustration, leaving it to cheaper non-immigrants.

Bob: I’ll think about taking it on, but I won’t promise anything (no, that isn’t ManagementSpeak for “No”).

Correspondent: More likely, it’s that you know who butters your bread, Bob. That’s right, management. And management is about profit for themselves and shareholders at anyone else’s expense, including the indentured servant Indians who suffer under near slave conditions; and your friends, neighbors, and possibly relative American citizens against whom you choose to be, shall we say, less than a champion.

Look in the mirror, buddy. You won’t like the cowardice you see. ^*&# you and your 1% crowd.

Sigh.

In case you haven’t heard of it, “The H-1B is a non-immigrant visa in the United States under the Immigration and Nationality Act, section 101(a)(17)(H). It allows U.S. employers to temporarily employ foreign workers in specialty occupations.”

Here’s what I, in my own, cowardly way, know, suspect, and conjecture about the H-1B program, divided into two parts: Public policy, and management decision-making.

Public policy first

I don’t generally do public policy, because KJR’s raison d’etre (pardon my French) is to give you something you can put to immediate practical use. Opining on public policy doesn’t achieve this.

Because I know too little about the subject to share a Strongly Held Opinion, I won’t. Instead, here are a few points to consider as you form your own:

  • Near-slave conditions? This is like calling your preferred political villain a Nazi. Slavery, and Nazi-ism, are far too deplorable to trivialize.
  • Econ 101: Worker visa programs are all a form of protectionism. In this case it’s the labor marketplace that’s being protected. The extent you favor or dis-favor the H-1B program probably depends on your views about protectionist economic policy.
  • Business ethics: Is the H-1B program immoral? I can’t personally come up with an ethical framework that makes hardworking foreigners less deserving of employment than hardworking U.S. citizens, other than the moral logic of protectionism — see previous bullet. From a moral perspective one might, in fact, plausibly argue that managerial hiring decisions should be purely meritocratic, entirely ignoring citizenship.
  • Recruiting goals: Well-managed organizations recruit the most talented individuals they can attract. Including H-1B workers expands the talent pool employers have to draw on, improving their prospects for doing so.
  • Unintended consequences: To the extent an employer wants to minimize IT labor rates, reducing or eliminating the number of H-1B visas issued would simply move the work offshore instead of moving the workers on-shore. If the work is on-shore, at least that means worker wages are spent here in the U.S.A.
  • Supply and demand: IT unemployment is, right now, very low (~3.9%), so demand exceeds supply. This explains at least some of the industry demand for H-1B workers. Reduced labor costs explain most of the rest.

Practical, immediately useful advice


For IT managers:
If you’d rather employ U.S. citizens than foreign IT professionals, embrace Agile. While colleagues of mine tell me offshore Agile is possible, there’s near-unanimous consensus among the Agile experts I know that team proximity matters, and matters a lot more than when using Waterfall application development methods. Having the team all in one place makes everything easier than when team members interact across multiple time zones and through purely electronic media.

For IT professionals: Recognize that you’re in business for yourself, and that what you can do for an employer constitutes the products and services your business has to sell.

Any time and energy you spend complaining about how unfair it all is is time and energy you aren’t spending making yourself more competitive. (Hint: Embrace Agile. Smart IT managers are looking for Scrum-worthy developers.)

H-1B workers are your business rivals. Your job is to figure out how to out-compete them.

I give advice for a living.

Sometimes my clients take my advice, which is gratifying. When they do, it usually seems to help them, which is even more gratifying.

But in spite of my awesome powers of persuasion, there are those clients who ignore or reject what I … a Recognized Industry Pundit (RIP) … have to offer.

The question this week: Should my clients always take my advice (Yes!), or, more broadly, why don’t people take the advice of the experts they hire for their expertise (long answer follows)?

Some correspondents asked this question in the context of my daughter Kimberly’s experience working with me as a client, where I … well, I didn’t reject her advice entirely but did accept only a modified, more frugal version of it, which resulted in unwanted delays and expenses.

Their question: How is it that I of all people didn’t take the advice of my contracted expert on the subject? Was this a well-deserved case of petard hoisting?

There are two possible answers. The first is that it wasn’t — it was a matter of risk management and its consequences. The second is that risk management my eye — of course I was hoist on my own petard, but like everyone else, your loyal author is a master of the art of rationalization.

I’m pretty sure it was risk management. Just in case you don’t already know this, you have four possible responses to risk. You can:

  • Prevent (aka Avoid) — reduce the odds of risk turning into reality.
  • Mitigate — reduce the damage if it does.
  • Insure — share the expense if the bad thing happens.
  • Accept — live with the consequences of failing to prevent, mitigate, or insure.

I chose to accept the possibility that an inexpensive WordPress theme might not do the job, resulting in delays and additional expenses, and I didn’t complain when that’s how things turned out.

Which brings us back to the question: When you pay an expert for advice, why wouldn’t you take it?

Here’s why:

We just explored one answer. Experts for hire know from hard experience that when something bad happens, relatively few executives remember (or, more accurately, admit) they chose to accept a risk and its consequences. That being the case, most experts, as a matter of self-protection, will usually advocate for the lowest-risk alternative.

Here’s another: Consultants are professional fault-finders. This being the case, we’re prone to fixing what’s broken by breaking what’s fixed. It’s our professional blind spot, reinforced by our habit of introducing metrics that demonstrate improvement, but not corresponding metrics that document any breakage.

Next up is a distressingly common and entirely illegitimate reason to reject a paid expert’s advice: Often, an executive or manager will engage an industry expert and immediately give the expert their preferred answer.

Some paid experts cater to this market, happily reading their sponsor’s script and cashing their check with a clear conscience. The customer is always right after all, and our job is to make our customers happy.

The only real value this advice has is political. It provides ammunition, not insight.

But there’s another, entirely legitimate reason for not accepting an expert’s advice that can be hard to distinguish from script management.

It’s that no matter how careful and thorough everyone involved is in the process, there may be matters of context that affect how well a consultant’s advice fits the specific situation.

This is one reason assertions of “best practice” should induce wariness: Few so-called best practices are contextual. They aren’t, that is, practices that fit best. Recommendations should start by accurately describing your situation and the nuances and constraints that shaped them.

What’s hardest for you is self-awareness — seeing the very blurry line separating your superior understanding of context and nuances from your confirmation bias, and staying on the right side of that line.

Where your self-awareness should kick in is when you find yourself explaining what you think the recommendations should have been before you invest time and effort understanding the recommendations you paid for.

On the other hand it’s entirely legitimate, after you understand the experts’ recommendations, to ask if they explored an alternative you think is a promising possibility; if so what they concluded and why; if not, why not.

Which is to say, as is the case with so many other situations, yes and no are the two worst responses available to you.

The best response (no, not the best-practice response) is an open-minded conversation.

Or as Michael Shermer, publisher of Skeptic once said, “The rub … is finding that balance between being open-minded enough to accept radical new ideas but not so open-minded that your brains fall out.”