Having no answer vs having the right answer

I've noticed in many lines of work, especially IT, that having an answer is almost better than having the no answer.

I've working with many techs over the years that will either say "yes", or "no", or something as long as it's an answer; rather than saying they don't know.

I've gained respect from peers by not doing this but fear this can actually be harmful in careers sometimes.

I think 90% of the time these techs get away with having the wrong answer because the people/persons asking never bother to check or never follow up.

Please share your thoughts and experiences.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Shanman

I honestly tell them the truth. If I don't know the answer then I just tell them I will have to look into it. I think they respect me more for tell them the truth. I get the "you are suppost to know everything" at me but in a joking way.

rogue2shadow

Shanman wrote: »

I honestly tell them the truth. If I don't know the answer then I just tell them I will have to look into it. I think they respect me more for tell them the truth. I get the "you are suppost to know everything" at me but in a joking way.

+1. This definitely gets you more kudos unless this is a chronic action lol.

cyberguypr

Agree. I am not a religious person but I do believe the truth will set you free. Sometimes the right answers is "I don't know, but I'll find out and get back to you."

undomiel

It depends upon if you leave it at "I don't know." It should always be qualified with a next step. "I don't know, but the developers should know so I will escalate it to them," or, "I don't know but I can call a vendor that does know."

Zartanasaurus

If I have no idea, I say so.
If I'm making an educated, yet speculative, guess I say so.
If I'm dead certain, I say so. Then I go double check to make sure I was right.

ColbyG

Providing no answer is infinitely better than providing the wrong answer.

networker050184

I just say I'm not 100% sure so let me do a little research and I'll get back to them. That way they know you are working on the issue and ensuring you get them correct info.

Turgon

Mc5ully wrote: »

I've noticed in many lines of work, especially IT, that having an answer is almost better than having the no answer.

I've working with many techs over the years that will either say "yes", or "no", or something as long as it's an answer; rather than saying they don't know.

I've gained respect from peers by not doing this but fear this can actually be harmful in careers sometimes.

I think 90% of the time these techs get away with having the wrong answer because the people/persons asking never bother to check or never follow up.

Please share your thoughts and experiences.

You must always do your own research, but sometimes it's best to keep your mouth shut if you are not on top of the facts. Retreat and gather. It also helps to have positive relationships with co workers who can assist. If someone's area of expertise beats your own it often makes sense to let them get on with it. The main thing if you dont know is to handle the situation properly.

blargoe

ColbyG wrote: »

Providing no answer is infinitely better than providing the wrong answer.

Yes.

/endthread

njkt

To be honest its easy to say "i always give the right answer or tell them i don't know it" but in practice i'm not so sure. When i have an O6 (Captain) or above (Admiral) breathing down my neck the "I don't know" is simply not good enough.

Sometimes, when you're in a high stress situation (network just **** the bed and you're the only worth-a-damn tech on watch) you just gotta use that logical troubleshooting skills to try and bring it back from the brink of hell... then explain in detail -why- it went down... confidence helps, then when you're done telling them 40% educated guess and 60% BS you can look up your answer and email the boss your corrections (or not, your decision).

edit: the above situation generally happens on a critical but undocumented system that has little to no logging capabilities (because adding those capabilities would be a violation of the licensing agreement with the contracting company)

MrRyte

Would it be wrong to say that you've found a possible answer (truthful or not) but you still need to double-check just to be safe?

powerfool

As some of you have come to notice, I don't play the political games that others find necessary. I have had managers get extremely squeamish and "reprimand" me for saying "I don't know." If I don't know the answer, I will flat out state such... no qualms about it. If you are respected for what you know, it is a profound statement. It highlights a few possibilities: 1) the issue is more complex than the questioner has realized, 2) it is not your area of expertise, or 3) you are too busy with other priorities to dedicate the resources to knowing the answer. If they aren't satisfied with the answer, they will let you know and you can respond. Sure, there definitely are folks that will detest the response because they want you to fluff up the response... I don't care about that stuff.

Take a look at "The Fountainhead." It is about an uncompromising architect. Develop your own principles and don't back down. History is full of morals and stories of this character attribute being virtuous.. butt weasel managers without backbones try to convince you otherwise. Its just like the current trend of "soak the rich." Parents always tell their children to stay in school, get an education, and then get a better job than they had and be successful... but these same parents (like my step-father who espoused those same ideas) are critical of people that did just that and claim that they aren't earning their wages. Let's stop equivocating and be firm in our beliefs. Let's strive for excellence based on our own principles and beliefs because they should be higher than "society's."

networker050184

njkt wrote: »

To be honest its easy to say "i always give the right answer or tell them i don't know it" but in practice i'm not so sure. When i have an O6 (Captain) or above (Admiral) breathing down my neck the "I don't know" is simply not good enough.

Sometimes, when you're in a high stress situation (network just **** the bed and you're the only worth-a-damn tech on watch) you just gotta use that logical troubleshooting skills to try and bring it back from the brink of hell... then explain in detail -why- it went down... confidence helps, then when you're done telling them 40% educated guess and 60% BS you can look up your answer and email the boss your corrections (or not, your decision).

When ever I hit this situation during my time in I'd just tell them flat out I'm working on it and will have a full synopsis on the issue to my supervisor shortly (which is who they should be talking to anyway). Throw in an estimated timeline with some tech words they don't understand and that should hold them off for a while. If that's not good enough for them then they can see my superiors. Remember, the chain of command goes down as well as up!

When something like this happens its really a breakdown in management. The person working the issue at hand should never have to field questions about it from users, execs, officers etc. Your manager should be the one getting updates from you and passing them up. People interrupting the actual fixing to ask whats wrong is never a good practice. Unfortunately it always happens though.

njkt

networker050184 wrote: »

...

While i 100% agree with you, i think i may have just been unfortunate enough to have -that- type of commo
I was the supervisor/tech on watch so there was never anyone to redirect questions to because the O6 knew the other folks had no clue what they were saying.

generally i could fend off the hounds and send them elsewhere with a "i'm actively engaged" or "the system blah blah blah estinated time of restoration blah blah blah" or say something technical and let them wander off to chew on it.

I don't advocate giving the wrong answer, but giving no answer is not always an option. Some body always answers to some body else, and as they say **** rolls down hill :P

instant000

njkt wrote: »

While i 100% agree with you, i think i may have just been unfortunate enough to have -that- type of commo
I was the supervisor/tech on watch so there was never anyone to redirect questions to because the O6 knew the other folks had no clue what they were saying.

generally i could fend off the hounds and send them elsewhere with a "i'm actively engaged" or "the system blah blah blah estinated time of restoration blah blah blah" or say something technical and let them wander off to chew on it.

I don't advocate giving the wrong answer, but giving no answer is not always an option. Some body always answers to some body else, and as they say **** rolls down hill :P

Yeah, I guess it depends where you are on the totem pole.

If I'm actively working an issue, I tend to inform my superiors of the severity of the issue, and current plans to mitigate.

One of the most-hated things is attempts at providing an estimated time to repair, and I will say "it cannot be determined" if we don't know a root cause yet (such as 30 seconds into the alarm).

What does help, though, is if you can at least pinpoint the device that is the source of the issue as quickly as possible. Most issues occur due to changes: power fluctuations, reboots, code upgrades, config changes, etc. As long as we have decent logging/monitoring configured, we can usually pinpoint most problems rather speedily. Then, it becomes a matter of having spares available, and how far away is the spare from the site that needs it. If necessary, we can route traffic around the failed device (after it's identified) and make temporary working solutions for a site.

If it's a server, then same thing, but hopefully there is some level of redundancy with your servers (as should also be with your network devices), such that you don't lose all of them at once, and/or you can connect to another site (albeit slowly) to provide those same server functions while your local ones get restored.

Hope this helps.