All Posts in Leadership

|In: Business Ethics|Last Updated:

“Better,” said Voltaire, “is the enemy of good.”

I used this quote last year, describing it as a healthy attitude, to finish a column proposing seven warning signs of a culture of complacency. In response, the estimable Frank Hayes, who writes “Frankly Speaking” for Computerworld and is one of the best commentators in the industry, was kind enough to respond:

“It’s an incorrect translation. What Voltaire wrote, possibly quoting an existing French proverb, was: Le mieux est l’ennemi du bien. “Mieux” does translate as “better.” But “le mieux” is always translated as “the best.” (No, I don’t know how they say “the better” in French.)

“So the translation should be: “The best is the enemy of good” — (unattainable) perfection is the enemy of (attainable) quality. Which is a worthwhile thing for us to remember, but it’s the flip side to the point you were making: better is (and should be) the enemy of good enough.

“Which doesn’t need to be translated from French — just translated into a lot of people’s brains.”

It’s an outstanding point (as you’d expect from both Voltaire and Frank Hayes): While satisfaction with mediocrity defines complacency, insistence on perfection is paralyzing. It’s pointless anyway, because the universe is a stochastic place where just about anything can happen. All the molecules of air in your bedroom could congregate in one corner while you’re sleeping, leaving you in a vacuum to asphyxiate. All of the uranium atoms in the nuclear reactor closest to you could decay at the same moment, causing a colossal explosion. Microsoft could release a version of Internet Explorer without security holes.

Hey, I didn’t say these events were likely. But they’re possible given the laws of physics as we know them. All that’s kept them from happening to you are the mathematical laws of probability.

In IT, competent project managers, system administrators and application developers all recognize the stochastic nature of their domains. Project team members get sick, hired away, or reassigned. Servers fail for indeterminable reasons and won’t come back up. The state-of-the-art development tool being used for a bunch of mission-critical code turns out to multiply wrong under certain unlikely circumstances.

Based on much of the correspondence responding to last year’s columns on complacent IT organizations, it appears some readers don’t live in a stochastic universe at all: In a truly well-run IT organization, they assert, everyone can leave promptly at 5pm every day because everything is always under control.

I don’t think so. Yes, in a well-run IT organization there will be days where nothing untoward interrupts the plan. In large, well-run IT organizations, though, the laws of large numbers take over and the odds that something goes awry increase to the point of inevitability. If a culture of complacency permeates, that won’t matter — everyone will leave at quitting time. In a healthier culture, professionals will work late to get the job done.

Quite a few readers agreed with my point — that if IT is a ghost town at 5pm it’s a symptom of complacency — but argued I shouldn’t have said so, because many executives would read it to mean that if anyone leaves at 5pm there’s a problem. That’s in spite of my also saying, in the same paragraph, “If everyone works late hours and six or seven day weeks all the time, it suggests a very different problem: Desperation. It comes from strong motivation — usually fear — coupled with severe ineffectiveness.” Their argument, while correct, is dangerous advice.

Writers are responsible for clarity. We’re responsible for avoiding ambiguity to the extent possible given constraints of space, limitations of language, and last-minute changes imposed by the copy desk. We’re responsible for marshaling persuasive facts and logic into a narrative framework that guides readers through the complexity of the subject matter.

We aren’t, however, responsible for every reader’s ability to comprehend. Some can’t. Others choose to mischaracterize because they read to gather ammunition, not new ideas.

This matters to you. As an IT leader, communication — listening, informing, and persuading — is a critical skill. Often, you’re informing and persuading non-technical executives of the need for hard-to-explain yet vital investments, such as those required to maintain a healthy IT architecture.

Communicators who spend their time and energy worrying about the ability of others to misunderstand them avoid controversial topics altogether, concerned that the consequences of someone misunderstanding their message are too large to risk. Business being a political environment, it’s a valid concern.

If you allow this concern to outweigh all others, though, you’ll have earned two labels: “craven,” and “politician.”

If you’ll forgive the redundancy.

Comments

|In: Leadership|Last Updated:

“It was a failed mail server.”

In response to my assertion last week that if IT is a ghost town at 5pm it’s a sign of a complacent organization, a correspondent described the situation: “At 6:00pm I wandered down to ‘see how it was coming’ and found only a contractor, who was there on his own nickel, but felt this was a critical issue that needed to be solved that evening. Many of the IT employees no longer work there, but the contractor is now a key employee.”

A thought: The employees might have needed firing. If the manager who hired them and allowed them to become so complacent didn’t leave with them, equally complacent employees undoubtedly took their place.

Say you’re leading a complacent IT organization — one that’s “good enough.” It’s time to shake it up. Great: How? Good intentions aren’t going to get you there.

I’ve seen IT leaders start by giving everyone a good scolding. It’s worse than useless — it’s stupid. It assumes everyone shows up every day thinking, “I’m going to do the minimum,” a complete misreading of the situation. In a complacent organization the problem isn’t malfeasance. It’s ignorance of what’s possible.

There are lots of other ineffective actions you can take. It’s pretty easy to spot them: They’re easy, entail minimal risk, and require relatively little of your time and attention. The effective ones require hard work, courage, persistence, and a thick skin. Most of all a thick skin.

So how exactly do you deal with a complacent organization?

For any change the place to start is a clear articulation of what’s going to be different. Tiresome as it sounds, it’s the old Vision-and-Mission thing — the bumper sticker summary. It’s a redefinition of IT’s brand: An easily-remembered touchstone for everything you’re trying to accomplish and a hook on which you’ll hang all of the hard, complex realities you’re about to undertake.

Next, define no more than three initiatives whose accomplishment requires the culture of discipline, urgency, and excellence you’re looking for. They should be broad in scope, clear in intent, and the criteria for recognizing improvement should be unambiguous.

They shouldn’t, however, be about the elimination of complacency. It’s the difference between “We’re going to tune the engine,” and “We’re going to win the Indy 500 — we need to tune the engine.” Your strategic initiatives make the culture change important.

Your new mission and strategic initiatives are the public face of the change. The place to start making it real is always your management team. If the departmental culture is complacent, the department’s leaders have accepted the complacency, might have caused it, and at a minimum have been ineffective in breaking through it.

At least one of your direct reports has to go. It’s usually best if at least one stays, too, at least for awhile. One has to go because there’s no way the whole organization could be complacent if all of its senior leaders are providing the right direction. It’s best if one stays because (1) it’s pretty unlikely that every member of the team is unsalvageable; and (2) even if they are, the IT staff needs reassurance that you don’t view every problem as a personnel problem … that you’re willing to invest in people and give them a chance, rather than simply replacing them all.

Almost certainly, among the ranks of your direct reports you have an apologist for the status quo. It’s your Dr. Pangloss, adept at explaining why you currently live in the best of all possible worlds. Fire Dr. Pangloss and replace him (or her) with an outsider who’s led a high-performance organization, and so is accustomed to and expects strong performance. In addition to adding a strong leader to your organization you send a message as to what will be required to succeed from now on, and you provide direct evidence to the remaining leaders of what’s possible.

For the same reason you also need to recruit a sprinkling of strong performers to the IT staff. It’s very easy for staff members to wave off management exhortations as the unrealistic ravings of those naive enough to fall for the platitudes that appear in the IT trade press. It’s a lot harder to wave off the successes achieved by their peers.

And finally: Get out of your office and get to know the IT staff directly. Create a presence for yourself. Make yourself real to them. Visit their cubicles; sit in on project meetings; invite them to “skip lunches.”

It’s easy to ignore the inhabitant of the corner office on executive row. It’s more difficult to discount someone with whom you’ve just had a productive, intelligent conversation.

Comments