If I tell you a secret, do you promise to keep it to yourself?

Okay, here it is: In most companies, the IS organization isn’t held in high esteem.

If it’s true in your company, make a list of five likely reasons. Done? Here’s my list of common reasons, which you can use for comparison:

  • Projects take too long, cost too much, and fail too often.
  • Analysts are arrogant, condescending, and speak in gibberish.
  • Systems are slow and unstable.
  • The Help Desk doesn’t.
  • Two words: Money Pit.

In your company it isn’t like this, of course, but I bet you know other IS organizations that have these problems, because they’re as common as dirt, and as hard to get rid of.

Now make another list, this time of how you plan to fix these problems. Take your time … I’ll wait.

Done? Compare it to my list of common solutions:

  • Reorganize IS.

Like high school kids in an old Mickey Rooney movie whose solution to everything is, “I know! Let’s put on a show!” most CIOs try to fix serious problems by reorganizing, which inverts cause and effect. Reorganization only makes sense as a consequence of an improvement program — it’s never the solution to real problems.

Like the old medical practice of draining blood out of a patient’s body, further weakening someone who’s already ill, reorganizations weaken you in three big ways: They distract employees from real work; they eliminate risk-taking, and they focus attention on the organizational chart. Let’s take these in order.

Employees stop thinking about systems architecture, database design and project deadlines during a reorganization. They start thinking about winners and losers. Employees feel loyalties to particular managers and antipathy toward others, so they worry about who’s going to come out on top. It’s a distraction, and no amount of leadership will change that.

And risk-taking? Who’s going to stick their neck out during a management shuffle? If you succeed, the manager who notices won’t be in a position to reward you, and if you fail your new manager will peg you for a loser. The first law of reorganizations is to keep your head down, and every employee knows it.

But the single most pernicious consequence of a reorganization is the attention it gives to the organizational chart. To understand why that’s bad just look at the drawing through an employee’s eyes. The org chart describes what my responsibilities aren’t.

Org charts show boundaries. Anything outside your box isn’t your responsibility — the org chart says so! And if you think that’s a good thing because it helps everyone understand what they’re supposed to be doing, think again.

Do you honestly think you’ve accounted for all the work that has to get done? If so, you’re wrong. In any organization there’s a bunch of miscellaneous stuff nobody keeps track of. Everyone just does what needs doing without thinking much about it.

Until you reorganize and everyone realizes, that stuff isn’t their job.

Even if, by some miracle, you’ve designed your boxes so every single thing that has to get done has an owner, you’re still not safe, because lots of work crosses organizational boundaries. Your new boxes are barriers that create friction — a loss of energy when trying to get work done. The trust that used to lubricate inter-box cooperation has been eliminated along with the old boxes themselves.

Sometimes you really do have to reorganize, but reorganizations always do damage. As with chemotherapy, the benefits sometimes outweigh the side effects.

Sometimes, but not often.

Everybody reacts to certain sounds in ways that range from cringing to anaphylactic shock. It may be chalk squeaking on a blackboard, fingernails scraping a screen, or even two pieces of corduroy rubbing together.

For me it’s the fingernail/screen combination. If I’m ever captured by an enemy bent on learning all of my secrets (both of ’em!), all they’ll have to do is brandish the screen in front of me. I’ll cave in an instant.

Sometimes whole sentences can cause just as intense a reaction. Many InfoWorld readers react to various examples of ManagementSpeak like those that begin this column. (Me too.)

Another source of acoustic chafing: People who tell you what you’re thinking and feeling (“Don’t get defensive,” is the perfect example, requiring extraordinary self-restraint and conversational dexterity in response). Deal with what I say and do, pal. I’m in a better position to describe my thoughts and feelings than you are.

There’s a new kid on the block that puts the others to shame. It goes like this: “The technology is the easy part.”

I hear people say this all the time these days. These people have never written a line of code in their lives, of course, and that may explain why they’re so comfortable saying it while calling programmers “bit-heads” and “nerds.” For them, technology is the easy part. They get to toss out high-level, fuzzily stated requirements. Then they sneer at programmers who bug them with questions, using the popular put-down: “Clearly you’re not comfortable dealing with ambiguity.”

There’s not much point explaining that it’s C++, not you, that’s uncomfortable dealing with ambiguity. These characters are so busy being self-important that they don’t have the time to deal with a mere technologist, who after all gets to deal with the easy part of the problem.

With a little less arrogance and a bit more patience, these important businesspeople would learn that they do indeed have a very difficult job, which they often shirk. That’s the process of clearly and unambiguously defining what the business needs. Usually, this means creating a detailed picture of a business process that doesn’t exist, along with every resource that process will need to be put into practice.

That’s hard. It requires, time, thought, and patience, so it usually goes undone.

Yes, when business planners do their jobs well they make the job of the technologist easier. Not easy, but easier. Somebody has to take the big picture and refine it into the kind of detail a data designer can translate into a schema and a programmer can translate into code. Too often, the people who end up having to do the refinement are the programmers and data designers, who collar the business planner in the hallway to ask annoying questions.

I’ve known IS programmer/analysts who have been assigned to a new business unit to “create the technology” and instead have designed every key business process along with defining the technology, up to and including the invoice design.

(Which, by the way, points to a solution. Place a programmer in a business area, actually doing the work. That puts the programmer in a great position to envision, and immediately build, efficient, technology-centered work processes. Try making this an endorsed system-design methodology.)

The devil is in the details, of course, and the ultimate level of detail is the actual code. It takes talented programmers to write good code that gets the job done. I guess it’s because the devil is in the details that so many businesspeople simultaneously denigrate and demonize the technologists who translate their “important concepts” to reality.