I’ve just made the transition from renting to owning. Someday I’ll understand why the Constitution of the United States, which describes our entire system of government, has so many fewer pages than the papers I signed at the closing.

Obtaining a mortgage was bad enough — while mortgage companies understand YUPPIES (Young Urban Professionals) and DINKS (Dual Income, No Kids), they don’t understand how a SITHY such as myself (Single Income, Two Households) could manage to pay a monthly mortgage lower than the rent I’d been paying all along.

Compared to everything involved in moving from one place to another, the mortgage was the easy part. Getting the new place to my liking, transferring my utilities, sending out change of address information to everyone who might care, and especially unpacking (unable to cope, I paid a moving company to do as much as possible) … there’s nothing about this experience I enjoyed, except the result after it was over.

Employees who experience business change react the same way, except that often, the result of the change is no fun either. Their natural inclination is to resist it.

Heck, nearly everyone’s inclination is to resist change. Since in IS we’re in the change business, we need to be good at overcoming that resistance. This is an important subject, so this isn’t the last you’ll read about it in this space.

Everyone resists change. Those who do real work resist change, because “If it ain’t broke, don’t fix it, and besides, I spent years mastering this job and now you’re making my skills irrelevant. Not only that, but the whole point of the change is increased productivity, and I’m not stupid — you’re going to downsize when you’re done.”

Managers resist change, because “We must have been doing something right all these years. Besides, right now I still understand the work because I was promoted from the ranks, but after you change it all my teams will know more about it than I will. Not only that, but part of every change is reorganization, and modern reorganizations ‘de-layer’ the company. De-layering leaves fewer management positions, so even if I do grab one of the remaining chairs when the music stops, I’ll have fewer opportunities for promotion than I have now.”

Executives resist change, too, because “I spent years getting to the exorbitant level of compensation I receive now, I’ve entirely forgotten how to do useful work, and the distance I can fall if the change makes me irrelevant is a heckuva lot longer than the distance I can climb if I survive it.”

How about the CEO? Surely this paragon of leadership will embrace the painful changes needed for the company to navigate the dangerous shoals of the future. “Sure, except that I only have five years until I retire, this change is going to be tremendously disruptive to our short-term profitability, and my compensation depends on how well our stock performs, so why should I go through this pain when it’s my successor who will experience the benefit? Besides, this may be the wrong change to make because the whole point about the future is that you can’t predict it.”

And then there’s you. Whatever position you hold in IS, what you really end up holding is the bag, because information technology isn’t just built into every modern business change — it’s the most visible part of it, and usually it’s the critical path. Succeed and employees blame you for the pain they experience. Fail to deliver the technology and your name is on the failure. Even when you deliver the technology, if employees resist the change your design must be the problem.

That’s OK, of course, because there’s nothing more fun than a software development death-march, so the joy of creation will make it all worthwhile.

And that’s the silver lining part. It gets worse, because you know every silver lining is accompanied by a nasty dark cloud. In this case the dark cloud is this: Companies that fail to change end up looking a lot like Amtrak in an age of airplanes, only without the subsidies — mostly irrelevant.

That means that when it comes to change you have only two choices: Hurt now, or hurt later.

Pick one.

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.