Is culture change the only path to sustainable success, as last week’s column suggested?

“Only” is a pretty strong word. And there are alternatives. Rigid, ruthless enforcement of policies, standards and procedures can get the job done too. Comparing the two, though, enforcement has several disadvantages:

  • Effort: Managers who rely on enforcement have to work a lot harder. Yes, cultures are normative — they enforce themselves — but it’s through the magic of peer pressure, not through managerial exertion.
  • Expense: Policies, standards and practices don’t write themselves, and once written, someone has to enforce them when an employee violates one of the rules. That “someone” turns into actual staffing.
  • Ugh: Use your empathy, and if you don’t have any, pretend. Imagine you’re on the receiving end of an enforcement-driven regime. It’s unpleasant. The practical consequence is that the best employees will be lining up in droves (assuming, of course, that droves form lines) to work anyplace not overseen by an enforcement-oriented manager.

It’s entirely fair to point out that not all good employees are a good fit to all business cultures, and that the ones who don’t fit will also line up to work someplace else.

But there’s a difference: You want the ones who aren’t a good fit to leave, because … culture is how we do things around here. If you’ve designed and implemented the culture you want, employees who don’t fit are employees who don’t do things that way.

Now: Culture might be how we do things around here, but how about that design and implement part? Culture isn’t software. How can a manager design and implement it?

Designing and implementing culture

First, please forgive my compulsion to make a perhaps-fine distinction — the difference between managers and leaders.

Management is about organizing and tracking work to make sure it gets done and gets done right. It’s about getting results out the door. Leadership is about getting others to follow you — to get them to go where you want them to go under their own power and initiative. Those in positions of authority wear both hats, but they’re different hats.

Culture is a leadership, not management responsibility, and in fact, defining and implementing culture is one of the eight tasks of leadership.

How to go about it?

While the short, informal definition of culture is how we do things around here, it’s a definition that aids understanding but not engineering. Understanding culture design starts with the definition used by ethnoscientists: The learned behavior people exhibit in response to their environment.

Next, you need to recognize that most of the “environment” employees respond to consists of the behavior of their fellow employees, and of their fellow employees the behavior of the manager they report to has the greatest impact.

There are other environmental factors, of course, like the size and style of the work environment, whether co-workers are face-to-face or virtual, and the communication technologies available. These all have an impact, so they are tools leaders have at their disposal when trying to change a culture.

But the primary tool in every leader’s culture-change toolkit is the mirror, because every business culture is, more than anything else, a reflection of how that leader behaves.

Only, behavior isn’t enough. This is the great unspeakable reality of modern, litigation-averse human resources: Attitudes aren’t supposed to matter. Not only that, but we aren’t supposed to try to influence them at all. Our job is to get employees to behave properly. How they think? Not our problem.

Only it is our problem, and perhaps our opportunity.

No, you don’t want to place yourself in the role of thought police. If, for example, someone who reports to you is inflexibly bigoted against, oh, say, skinny women with freckles, “Stop hating skinny women with freckles or you’re fired!” just isn’t going to work, while “I don’t care what you think — just because Anne is skinny and has freckles doesn’t mean you’re allowed to treat her differently from anyone else,” is entirely legitimate.

But ask yourself: If you were hiring, and it came out during the interview process that one applicant just hates all skinny women with freckles, would you hire that applicant?

Attitudes drive behavior, so pretending they don’t matter is just that — pretending.

So while you aren’t allowed to judge employee attitudes, that doesn’t mean you can ignore them. Culture change requires a change in attitudes.

Which will require a change in your behavior. Which usually will require a change in your attitudes.

Did I mention that culture change is really, really hard?

* * *

Eight years ago in Keep the Joint Running, I wrote about religious diversity in the workplace and how you, as a manager, need to approach the subject (“A difficult balance at best,” 1/9/2006) — this week’s blast from the past.

Close runner up: It’s eleven years old, but who can resist taking potshots at ’em, so here’s my “Total Cost of Gartner” (1/13/2003).

Want to know the secret of lasting organizational success? Go on a diet.

No, losing weight won’t change the organization you lead. But then, going on a diet probably won’t result in you losing weight and keeping it off, either, and for very similar reasons.

Want to lose weight? Eat less, exercise more. This doesn’t require brilliance, expertise, or a book. (But if you want to buy a book that will help you lose weight, read The Moral Hazard of Lime Daiquiris by Bob Lewis and Dave Kaiser. On a treadmill. While snacking on carrots instead of Little Debbies.)

Anyway, losing weight is a poor goal, and when you set a poor goal, even if you reach it you’ll be in a poor place.

A better goal is to live the weight you want, not to lose the weight you don’t want.

It’s entirely parallel to the secret of lasting organizational success.

Choose a problem — the organizational equivalent of weight you want to lose. Perhaps it’s a proliferation of custom-coded point-to-point system interfaces, a common-enough problem. How do you go about fixing it?

I see a hand raised. Yes, Clark?

“Implement a service bus?”

Uh … Clark? What exactly do you mean by “implement”?

“You know. Select a service bus technology, and launch a project to convert all of your interfaces to services that run through the bus.”

“Thssspffft!”

Nice Bill the Cat impression, Kent. Did you have something to contribute?

“Thanks. I feel like Rodney Dangerfield in Back to School saying this, but seriously … in my company the IT Steering Committee would never approve a project like this. They’d compare the new business value we’d get from it to the latest requests from, oh, I don’t know, say, Marketing? And that would be the end of that.”

“Even if it did get approved, while the project team was busily converting interfaces to the new technology, all the other application project teams would be just as busy creating new interfaces using the old technology.”

Thanks, April. But that line of thought points to a solution. Any suggestions, June?

“Well, obviously, in addition to the conversion project you’d have to train all the other developers how to write interfaces using the new technology.”

Why are you making a face, May?

“Maybe I’m just old and cynical. I just remember our old COBOL programmers who got trained in C++. Most of them ended up coding 60,000-line-of-code “objects” that looked almost exactly like COBOL programs. So I’d bet if you trained everyone in the new technology, half of ’em would write the same old custom point-to-point interfaces. The only difference would be the language and transport.”

Thank you! Right on the money.

Okay, class, here’s the deal. If you want to clean up an interface tangle, you want the wrong thing, or at least the not-right-enough thing. I gave you the wrong problem to solve and you fell for it. As leaders, part of your job is to recognize when someone does this.

The wrong problem is fixing an interface tangle. What’s a better problem to solve? Yes, Bruce?

“Well, you told us the answer, didn’t you? The right problem to solve is how to change the IT organization so it only builds well-engineered interfaces. Do that and every project team will replace the old-style interfaces with new ones as part of every project.”

Bingo. So how do you change an IT organization so it works this way?

“Training?”

Necessary, Wayne, but not sufficient. What else?

“Standards?”

Nice try, Newton, and yes, you would need standards. But standards are usually about enforcement, and if you have to enforce you’ll be working way too hard. And besides, once you start to rely on enforcement you’ll need professional enforcers. Sound like the kind of organization you want to run? Yes, Mr. Boaz?

“Vell, I tink ver you’re going mit dis iss to change der culture.”

There you go. There are a lot of definitions of culture out there. From a purely practical perspective, a useful way of thinking about it is that the culture is “how we do things around here.”

Want well-engineered interfaces? Make the interface style you want “how we do things around here,” and the problem will, as Bruce suggested, solve itself. Yes, Isaac?

“Any suggestions on how to change a culture?”

Gee, what a shame … that was the bell. Class dismissed.

* * *

Until next week, at least. See you then!

* * *

New feature: This column marks the beginning of year 19 for Keep the Joint Running and its predecessor, InfoWorld’s IS Survival Guide. To celebrate, each week this year I’m going to pick out a favorite from the corresponding week from one of the past 18 years. This week’s blast from the past has to be the column that started it all, “Welcome to the IS Survival Guide,” (1/8/1996). All in all it holds up pretty well.