It’s time for another re-run – this time from the ancient days of 1999. It’s about … well, if you read on you’ll find out. – Bob

# # #

A recent column (recent when this column first ran) 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.

Let’s clear something up: Submitting a ManagementSpeak to KJR isn’t whistleblowing. What the two have in common: If the manager you’re quoting catches on and figures out you were the source, you might be in for some personal discomfort.

What they don’t have in common: Congress has passed no laws protecting ManagementSpeak submitters from retaliation.

Send in what you hear anyway.

Speaking of whistleblowers, the estimable Randy Cassingham, who also writes and publishes This is Truea weekly compendium of strange happenings from headlines around the world — told of the recently deceased Shuping Wang in his Honorary Unsubscribe.

In the 1990s, Wang discovered that the Chinese government’s methods for managing its blood supply promoted the spread of blood-borne pathogens; her tests showed contamination rates of 83% for Hepatitis C alone.

Wang attempted to bring the problem to the attention of her management, and when that had no impact tried jumping a level, with predictable results: Dr. Wang’s research was stopped and one official bashed both her and her equipment with a club.

If you’re interested in the full story I encourage you to click the link. If you’re interested in how it relates to you and the organization you work in, read on.

In your career, you’ll run across all sorts of, shall we say, opportunities to improve how things get done around here. Not improving how you and your organization do things, but how other managers and their organizations do whatever they do to accomplish whatever they’re supposed to accomplish.

Some of these will be true opportunities. But some might be opportunities in the sense of the drivelous “there’s no such thing as a problem, only an opportunity.”

The problems probably won’t be as dire as actively spreading fatal diseases. So let’s be less dramatic about it and imagine you’ve discovered a data breach. It hasn’t exposed millions of customers’ credit card information yet … just a few thousand thus far … but the risk of larger losses is, in your estimation, quite real.

You figure your employer will want to eliminate this risk, so you send an email to the managers in the company’s org chart most likely to be in a position to do so, explaining the breach, its root cause, and suggestions as to what a solution might look like.

And … nothing happens, other than your receiving a pro forma email thanking you for being so conscientious.

The question: Why do organizations as diverse as the Chinese government and sadly not atypical large corporations do their best to ignore problems like these instead of fixing them?

Start here: Organizations don’t “ignore” problems, any more than they might be “greedy” or “evil.”

Ascribing these behaviors and motivations to the organization means something quite different from ascribing them to, say, human beings of the Homo sapiens persuasion.

Humans might and often do ignore problems and act greedily. Depending on how a person’s attitudes and behavior stack up against your moral code you might run across the occasional evil villain as well.

But an organization isn’t just like a human being only bigger. It’s different. If an organization appears to ignore a problem, what this means is that its systems and practices aren’t designed to accommodate reporting problems and fixing them.

In many cases organizations are inadvertently (?) designed to conceal, compartmentalize, and in some cases cause problems, as when fixing one would cause a manager’s P&L to go negative, creating one would make it shine, and everyone from the top on down manages to the numbers.

Compounding the metaphorical felony is that someone’s name is on the problem and the practices that led to it. If fixing it would be embarrassing and expensive, well, raises, bonuses, and promotions don’t go to managers who own embarrassing and expensive situations, so relying on luck can be quite appealing.

That’s especially true in the many organizations that consider identifying whose name is on a problem and “holding them accountable” (ManagementSpeak for “punishing them”) to be the essence of root cause analysis.

While it might seem logical that the company would want to fix a problem while it’s still small and manageable, companies don’t want anything. What’s good for the organization doesn’t matter unless it’s good for someone important in the organization.

So when something needs fixing, the first step is asking who, if anyone, will benefit from fixing it.