I have a new set of hearing aids. In the instruction manual, well before the explanation of how to change amplification and programming, is this:

You are not allowed to operate the equipment within 20 km of the centre of Ny Ålesund, Norway.

There’s no explanation for the rule, just the fact, which is why my wife and I were briefly tempted to burn some frequent flier miles, just to break it.

But cooler heads prevailed. Actually, colder heads — we live in Minnesota, which we figured is bad enough (Google Maps reveals Ny Ålesund is on an island roughly 1,000 km due north of Lapland).

Which gets us to another disadvantage of relying on policies, standards, and enforcement to make sure how you want everyone to do things around here becomes how everyone actually does do things around here, beyond those mentioned last week: You have to explain your reasons, which makes your policies and standards burdensomely long. If you don’t, you’ll tempt employees to violate the ones that make no apparent sense, just to see what happens.

Changing the culture simply works better. When enough people internalize how we do things around here, peer pressure becomes your primary means of enforcement.

How to change it? You’ll find a detailed account in Leading IT: <Still> The Toughest Job in the World. Glad you asked.

The short version is to change your own behavior, because culture is the learned behavior people exhibit in response to their environment, and leader behavior is the dominant aspect of their environment.

Before you do, you have to describe the culture you want, and there’s a gotcha. The temptation in describing “how we do things around here” is to be procedural: “When someone contacts the service desk, we first identify the caller, next assign a ticket number, then get a description of their issue,” and so on.

But culture isn’t a matter of procedure. It’s a reflection of shared attitudes. Your behavioral description of culture should reflect this — something like, “When someone contacts the service desk we assume they’re experiencing a real problem, and we take ownership of it.”

<SnideComment>Given my experience with service desks, and in particular with my current mailing service after many subscribers received five copies of last week’s column, I’d say this would represent a radical cultural shift in far too many.</SnideComment>

To change your culture you have to describe both the culture you have and the culture you want. You have to figure out what about how you currently behave results in the culture you currently have, and how you’ll need to behave to get the culture you want.

If there are other managers between you and the employees whose behavior you want to change, you have to pay close attention to how those managers are behaving, how you want them to behave, and what you have to do so they’ll behave that way.

A few subscribers asked if there’s a way to change the culture quickly.

The answer is yes. Actually, there are two.

The first is to lay off a significant number of the employees you have and hire to the new culture. It’s unpleasant to say the least — unpleasant for you, more unpleasant for the surviving employees, and … and I hope this is obvious … even more unpleasant for the dear departed.

Although to be fair, on the pleasantness scale the employees you hire as replacements might very well find the change quite positive, all in all.

Anyway, massive layoffs are quick-culture-change tactic #1. The second one is slightly less draconian — fire all of the managers whose behavior seems to be driving the old culture and replace them with managers who seem to have the attitude you’re looking for.

Yes, it’s ugly. No, I don’t generally recommend it. But if you need to turn around a seriously dysfunctional culture quickly, this is your most efficient alternative.

Start with the ringleader, and perhaps his/her chief acolyte. Reason #1: Fire all the managers at once and the disruption will be too great. Reason #2: Persuading HR to go along will be a challenge. Reason #3: Do you really want to be that kind of person? And most important, Reason #4: Once you’ve fired one or two, the rest will usually figure out you’re serious and change their behavior to match what you’re looking for.

And, in case this isn’t clear, you still have to change your behavior (and attitudes) too. Otherwise, the culture will gradually revert back to the one you say you don’t like.

And you’ll have to go through the unpleasantness all over again.

* * *

Four years ago in Keep the Joint Running, Gartner predicted that in just two short years, 20% of all companies would have no IT assets of their own — it will all have moved to third parties and the cloud. KJR’s rebuttal was suitably pungent.

And eight years ago you read about a popular technique for manipulating people.

A popular outsourcing rationalization has it that companies should “keep the core and outsource the rest.”

I call it rationalization rather than rationale because:

  • It solves nothing: Outsource something you don’t know how to manage and you still don’t know how to manage it, only now, you’re badly managing a company that wants as much of your money as it can get.
  • It suffers from recursion failure.

KJR has already covered the first two points—click on the links or buy yourself a copy of Outsourcing Debunked (Bob Lewis, 2011). But what’s recursion failure? Glad you asked.

Outsourcing is like anything else in business—to succeed, you have to be good at it.

But as anything that isn’t core must be outsourced, and as the notion that managing outsourcers might be a core competency is absurd, the only logical conclusion is that companies that outsource must outsource outsourcing management to an outsourcing management outsourcer.

To succeed at that, the company must be good at outsourcing outsourcing management. And so on, ad infinitum—recursion at its finest.

Okay, I wouldn’t want to try that logic on a business executive weighing the pros and cons of outsourcing, but it was fun, wasn’t it?

What isn’t fun: Why an increasing number of American business managers are receptive to the even-more absurd arguments in favor of IT outsourcing, both the traditional kind and its current commodity end-point, cloud computing.

Look, even those unenlightened IT shops that thought they had internal customers usually involved themselves in the business processes and practices they were helping improve through automation to some extent. Few business analysts strictly limited their conversations to “what do you want the software to do?”

IT outsourcers, in contrast, deliver software that fulfills requirements and meets specifications. If they do that, all is good with the world, whether or not the software does anything useful.

Deep down inside, every business executive who ever endorsed an IT outsource understood this difference, and yet it didn’t matter. They considered overseeing IT to be an aggravation, and so they willingly “kept the core and outsourced the rest.”

Now we have the cloud, and software as a service (SaaS). The “new” question is, “Why should we spend lots of time with IT on a CRM implementation when we can call Salesforce and be up and running the next day?”

What’s sad is that they know the answer to this seemingly rhetorical question: If they do this they’ll be up and running with what we used to call, in more enlightened times, an island of automation.

Multiple islands, really — as many as they have sales representatives configuring Salesforce as they prefer. Add to that a database that’s completely unusable for reporting and analytics, as each sales rep stashes the data they want in whatever data fields appear convenient for that purpose.

Heck, IT could do that in a day, too, if it was amateurish enough to be satisfied with an implementation that banal. It could buy Act! licenses for a fraction of what SalesForce would cost, too, installing the software on individual sales rep laptops with no attempt to integrate them.

Nothing to it.

We in IT have failed in at least three respects, and we’d better fix all three soon, or we won’t be around to say “I told you so.”

The first is that we thought business executives long-ago absorbed the islands-of-automation argument, so we stopped making it. They had absorbed it, but ideas have a half-life, and because we stopped repeating it, this idea long ago lost its potency.

The second is that we argue rather than discuss. Faced with a sales executive who is thinking about Salesforce, too many CIOs say, “You can’t do that. Here’s why …” instead of, “We can do that … in at least three different ways, depending on what you want to accomplish and how much you’re willing to invest to get it.”

Then there’s the third — failing to focus everyone in IT, from the CIO on down to every help desk analyst—on the importance of managing relationships throughout the company. Without this, nobody will give the CIO or anyone else the time to have these discussions, or the patience to listen to the to-them complex engineering issues we need them to engage in.

So of course they outsource, and go to the cloud without involving us.

We’ve given them no reason not to.