All Posts in Leadership

|In: Industry Commentary|Last Updated:

If, except for the concussions and bruises, you’d enjoy an old fashioned bar brawl, come on by the forums on InfoWorld Electric. They’re great places to test your thoughts in the marketplace of ideas.

They’re lousy places to learn diplomacy, but great places to float a concept.

A recent column and forum addressed the frequent complaint that “I only need 10 percent of the features. The rest are useless frills.” It suggested that instead of complaining about feature bloat, you should learn more features, because there’s a lot of useful stuff in there. (Code bloat, of course is a different matter entirely.)

Somewhere in the lively discussion that followed, a question occurred to me: The people who claim they only use 10 percent of the features don’t know the features they don’t use. How do they know they’re only using 10 percent? Since you don’t know what you don’t know, you only know the numerator, not the divisor.

No matter: If software follows the everyday laws of probability, you’ll use 10 percent of the features 90 percent of the time. The two questions are: (1) What’s your personal point of diminishing returns? and (2) If you don’t use a feature, does its presence constitute feature bloat?

And then a colleague of mine asked one of those questions that make you lose interest in the original issue: “Never mind the software, Bob,” he asked me. “Do a lot of managers only make use of 10 percent of the capabilities of the people who work for them?”

Now there’s a question to conjure with. Can’t you just hear the feature-bloat arguments extended to employees?

“I only asked you to document the network, Jill,” a systems manager might say. “Your recommendations on how we can optimize it wasted space on the server and made me spend more time reading your report.”

The answer to my colleague’s question, then, is a resounding, “Yes, and ain’t it a shame?”

We’ve come a long way from the check-your-brains-at-the-door days, but nowhere near far enough. Most of us do understand the benefits of empowering employees, pushing decisions out to the people who do the day-to-day work. We do require thinking rather than forbidding it like we used to. That’s good.

It’s good, but it isn’t good enough, because when you’re in a leadership role you don’t get the most out of your employees by keeping them in their comfort zones.

Here’s an exercise for you. For each of your direct reports, list three responsibilities you think they’re capable of that aren’t part of their current job but are part of your department’s charter. Now ask your direct reports to do the same for themselves, and compare their thoughts to your own. Your list is a set of menu options the employee has never clicked on; their list describes features and capabilities you’ve never tried to use.

Every employee should have stretch assignments – responsibilities that require unproven skills and abilities – on a regular basis. In the list you and your employees have just created are the opportunities. Stretch assignments are good for both of you. For the employee, a stretch assignment is the fuel that propels career growth. For you, stretch assignments expand the capabilities of your department.

The rules for stretch assignments are simple. First, they have to be important, but not vital. By definition, they’re riskier than other assignments, so while success has to generate real benefit, failure shouldn’t result in serious harm.

Second, don’t expect perfection. People rarely do things perfectly on the first try. Sometimes, a feature is buggy in the first release but gets better in the next one. Employees should se stretch assignments as opportunities, not as potential career busters.

Third and last, you must offer enough support that the employee can succeed, but not so much that you eliminate the risk of failure. When employees can’t fail … when they don’t make real decisions, deal with real uncertainty along the way, and make the correct choices when doing so … they can’t succeed, because without the possibility of failure there is no success, only completion.

Comments

|In: Industry Commentary|Last Updated:

Let’s play telephone. You know the game – it’s the one where each person at a party whispers a message in the ear of the next person, until the message has gone full circle. By the time the message returns to the original speaker, it’s completely distorted.

Only we’re going to play it the IS way. We’re going to have only two people in the room – a CEO and a CIO. And instead of whispering, they’ll speak in loud voices. Let’s listen in:

CEO: “We always seem to be one year away from achieving high value. The high cost of undelivered promises is a continuing and increasing problem.”

CIO, trying to repeat the CEO’s message verbatim: “IS isn’t very well aligned with the business and we need to do a better job of getting involved in setting the company’s strategic direction.”

The CEO quotation comes from quotes in a recent InfoWorld article reporting on a census conducted by the London School of Economics. The CIO quotation paraphrases conversations I’ve had with CIOs and articles I’ve read by various pundits describing what they think the big problems are with IS.

I guess we weren’t paying attention during all those seminars where they taught good listening skills.

Why do we keep getting this wrong? The answer, I’m afraid, is simple: Strategy is fun and easy. Done the usual way, it requires neither deep thought nor intellectual rigor. Not only that, it’s prestigious, and provides a wonderful boost for our egos: We’re involved in setting the company strategy!

Delivery, in contrast, is hard work.

Pick up the clue phone, folks. If you want to be involved in the fun stuff you have to earn the right. Do you know why the directors of manufacturing, customer service, accounting, and sales and marketing all get to play? Because manufacturing gets product out the door, sales and marketing gets it sold, customer service keeps ’em coming back for more, and accounting makes sure the bills are paid and taxes are kept as low as possible.

Meanwhile, IS projects have a failure rate worse than the Cubs’ infamous shortstop, André “Double-play” Rogers (so-called because when he batted with a man on first, you could count on his hitting a grounder to the second baseman). With projects of any size, we bat about .100 – about 10 percent get done with some semblance of success.

In the data center, our servers go up and down like yo-yos. Sometimes it’s deliberate, too – I know of some data centers that still take down servers in the middle of the business day because that’s a more convenient time to do it … for the data center staff. Sometimes servers crash a lot because the data center manager expects servers to be unreliable. Trying to make an NT (or Novell, or whatever) server reliable, to these mainframe jockeys, has about as much point as Don Quixote’s tilting at windmills.

Never mind that lots of data centers run reliable NT environments (hint: reboot the server every Sunday night) – these fossils subconsciously want the servers to crash, because that will justify their dislike of the new technology.

Then there’s the Help Desk. Many CIOs staff it with the lowest-paid, most poorly trained people in IS, and use it largely as a dispatch center. Then they complain when end-users try to bypass it. Run an actual information center, staffed with experts in PC applications who actually enjoy helping end-users succeed?

Bring up that sorry subject and you’ll hear the same explanation you’ll hear when you ask for a raise: “It isn’t in the budget.” What a sorry excuse that is, too – if you want to be the CIO, you’d better learn how to justify important expenditures, even those whose benefits are hard to quantify.

The funny thing is, CEOs aren’t complaining about lack of quantifiable return on investment. That’s our hang-up.

The CEOs are complaining about broken promises and simple bad management.

Want to be involved in your company’s strategic planning?

If you want to get picked for the All Stars, first you have to succeed at the fundamentals.

Comments