By Ed Hammerbeck

Perhaps you have seen this happen:
Situation: A user is confused about an IT issue and asks the resident IT expert a question.
Response: The IT expert takes on that deer-in-the-headlights look. Then the IT expert utters a polysyllabic string of buzzwords, acronyms, hmms, and haws. The mumbles translate to, “That’s impossible” or “That’s not our job.”

The IT expert does not have a clue as to what the correct answer is, but for some reason, is unwilling to admit this. Many techies are unwilling to say, “I don’t know.”

Maybe it’s ego. Maybe he is afraid he is not the smartest person in the room. Maybe she is afraid that someone will think she isn’t worth the expense the company spent to recruit her. Whatever the inner psychological reason may be, the fact is that technical people do not like to speak those three little words. It is as if they were confessing to a capital crime.

How I got burned
The consequences of choosing bravado over honesty can be very serious. Let’s look at an example where a manager could have spared a lot of people a lot of pain by saying, “I don’t know.”

Not too long ago, I was an entry-level programmer in the IT department of a large organization. Most of the people in my group were mainframe programmer analysts. I was one of a growing pool of Windows programmers—all inexperienced.

A large client/server development project came up. I was the only one available with the skills to even get it started. Green as I was, I made sure to tell my boss what I did and did not know. In meetings with the customer, however, my boss talked as if our group was highly proficient at this sort of development.

In the manager’s defense, there was a very real threat of the customer outsourcing the project, and keeping projects in-house was a top priority for our department.

Everyone agreed to all their requirements, and the group (meaning me, actually) was locked in to a classic case of the poorly conceived, poorly designed, poorly specified, and poorly managed project.

An unhappy ending
The project dragged on for over six months. Everyone involved was tired and frustrated because of the rework, mistakes, and “requirements creep.” This could easily have been avoided if someone in management had said, “Our group does not have those skills right now, but if you give us two weeks, we can talk more intelligently about satisfying your needs.”

Whatever my manager saved by keeping the company from outsourcing the project was blown away as we limped and struggled along. Ultimately, we had to hire a consultant to help finish up the project. When I left the company, the project was more than 200 percent over budget.

I left with a bad taste in my mouth about the organization and my choice in careers. The development group lost whatever reputation it had, and the customer outsourced later segments of the project that would have greatly increased the skill sets of the in-house developers. Nobody won.

The benefits of admitting ignorance
Information in the IT field has a limited life span. New versions and product upgrades make our knowledge base obsolete quickly. In this context, it is strange that “I don’t know” is so hard for some people to own up to. It’s likely you are not fooling anyone by this act anyway. People see through it.

I knew a manager several years ago who embodied this perfectly. When it came to technology, he professed to be an expert, even though technology was peripheral to what he did. Even so, he gave his opinion at every opportunity, giving mini-lectures on the technical ramifications of whatever was being discussed. He was usually off base and sometimes completely wrong. Consequently, no one took him seriously. No one ever acted on his unsolicited advice.

That is the danger of this sort of obfuscation. The worst thing that can happen is that someone takes the IT professional’s babbling seriously and makes a business decision based on it.

Ignorance is not bliss in IT. Ignorance has consequences if not managed responsibly. I recommend that you gain the courage to say, “I don’t know,” and you show the professionalism to ask for time to learn. We are knowledge workers, and solving business problems is our job. No one will fault us for taking the time to get prepared.
Have you ever seen IT workers get burned because they pretended to know the answers? Are people in other professions just as likely to tap-dance their way through a sticky situation, or is IT more prone to this problem? Post a comment below or if you would rather, send us an e-mail.