The Fastest Way to Lose Credibility in IT: How to Admit You Don’t Know

How to Admit You Don’t Know Without Losing Credibility in IT

One of the quickest ways to damage your credibility in IT is to confidently give someone an answer that turns out to be wrong. Yet, we do it more often than we might like to admit, sometimes because three simple words can be surprisingly difficult for an IT professional to say: “I don’t know.” There is, however, a right way to say “I don’t know” and that’s what this article is about.

How to Admit You Don’t Know

People come to us because we’re supposed to know. A user can’t connect to the VPN. A server is behaving strangely. Microsoft 365 is doing something it didn’t do yesterday. A client wants to know why an application suddenly slowed to a crawl. They look to IT for an explanation, and we feel pressure to have an answer.

That’s when some IT professionals make a serious mistake. Instead of admitting they don’t know, they guess. They speculate, start talking in vague technical language, or confidently offer an explanation that sounds plausible but isn’t supported by the facts. In other words, they bluff. The problem isn’t simply that the answer might be wrong. The bigger problem is what happens to your credibility when the customer or coworker discovers that you presented a guess as fact.

“I Don’t Know” Is Not the Same as “I’m Incompetent”

One of my Five Principles of IT Customer Service Success is competence. You have to know how to perform the tasks of your job. Compassion, empathy, listening skills, and treating people with dignity and respect are all important, but none of them will compensate for someone who consistently can’t solve technical problems. Competence matters…a lot.

Competence, however, does not mean knowing everything. Technology is too broad, too complicated, and changes too quickly for any one person to have every answer. Even within a specific specialty, you’re going to encounter unusual configurations, undocumented changes, obscure error messages, and problems you’ve never seen before. Forgive the cliche, but no one knows everything.

The competent IT professional isn’t the person who always knows the answer. It’s the person who knows what to do when they don’t know the answer. That’s an important distinction, particularly in an industry where people sometimes confuse confidence with competence.

The Problem With Pretending You Know

Imagine you’re working for an MSP and a client asks w Forgive the cliche, but no one knows everything.hy their internet connection keeps dropping. You don’t know yet because you’ve just started investigating, but you feel like you need to say something. So, you blurt, “It’s probably your firewall.”

Now the client believes the firewall is the problem. Thirty minutes later, you discover the firewall is fine and the actual problem is an issue with the ISP. You may think, “No big deal. I figured it out.” The client, however, remembers that you told them the firewall was the problem.

That’s how credibility gets damaged. It wasn’t because you didn’t immediately know the answer. It was because you presented a guess as a fact.

The same thing happens in internal IT departments. A manager asks when a system will be back online and someone says, “Maybe in about 20 minutes.” Sometimes that answer is based on experience and available evidence. That’s a reasonable estimate, as long as you clearly identify it as an estimate. Other times, “20 minutes” is just something someone said because they felt pressure to provide an answer. Twenty minutes later, the system is still down and the manager is wondering whether anything IT says can be trusted. It’s not fair, but it happens often.

Try This Instead

Admitting you don’t know doesn’t require a dramatic confession. You don’t need to hang your head and apologize for your lack of knowledge. Just be direct: “I don’t know yet. Let me investigate.” You might also say, “I haven’t seen this particular issue before. I need to do some research,” or, “I have a couple of theories, but I don’t have enough information yet to give you a reliable answer.”

That last response is especially useful because it tells the customer or coworker that you’re thinking about the problem while making it clear that you won’t present speculation as fact. When appropriate, explain what you’re going to do next: “I don’t know why the service is failing yet. I’m going to check the logs, review the recent changes, and see if there are any known issues with the vendor. I’ll update you by 2:00.”

You’ve admitted that you don’t know the answer, but you’ve also demonstrated competence. You have a process, a plan, and a commitment to communicate. For most reasonable customers and coworkers, that’s far more reassuring than an immediate answer that turns out to be wrong.

How to Admit You Don’t Know? Never Stop at “I Don’t Know”

There is a bad way to admit you don’t know: “I don’t know.” Period. Years ago, I asked a technical person a question and got a dismissive “I don’t know.” The tone and body language made the rest of the sentence clear: And I don’t particularly care. It’s similar to saying no to a customer request without offering an alternative.

That’s a customer service failure. When someone brings you a legitimate technical problem, “I don’t know” should usually be followed by a next step. “I don’t know, but I’ll find out.” “I don’t know, but I know who to ask.” “I don’t know, but let me do some research and get back to you.”

The point isn’t the specific wording. The point is to move the conversation from uncertainty to action. Customers don’t necessarily expect you to know everything, but they do expect you to take ownership of the problem and help move it toward a solution.

Be Careful With “I Think”

There’s nothing wrong with forming a hypothesis. Troubleshooting is often a process of developing theories and testing them. The problem is how we communicate those theories.

“I think it’s a DNS problem” may be perfectly appropriate when talking with another technician who understands that you’re troubleshooting. The same statement may be interpreted as a definitive diagnosis, however, by an end user or client. Be aware of your audience and intentional about your language.

You might say, “One possibility is DNS, but I’m still investigating,” or, “The symptoms are consistent with a DNS issue, but I need to confirm that.” You’re not weakening your credibility by adding those qualifiers. You’re being precise, and precision is part of technical competence. Frankly, however, if you suspect it’s something highly technical such as DNS, your best response is something like this: “It looks like a server issue on the back end. We’re working to confirm and repair it now.” Most end users aren’t familiar with DNS or other highly technical matters.

Don’t Blame Someone Else to Cover What You Don’t Know

Another temptation is to redirect uncertainty toward someone else. “The vendor must have changed something.” “The network team probably pushed an update.” “The user must have clicked on something.” Maybe, but until you have evidence, you don’t know.

Blaming another person, team, or vendor may temporarily take the pressure off you, but it creates a different problem. If you’re wrong, you’ve damaged trust with the customer and potentially with your coworkers. Stick to what you know: “We haven’t identified the cause yet.” “The logs show the failure started at 9:17, but we haven’t determined what triggered it.” “We’re investigating whether a recent change is involved.”

Facts first. Draw conclusions after the evidence supports them. It’s a good troubleshooting practice and a good communication practice.

Knowing What You Don’t Know Is a Professional Skill

Socrates is credited with saying, “I am the wisest man alive, for I know one thing, and that is that I know nothing.” Whether you’re a help desk technician, network engineer, sysadmin, developer, CIO, or MSP owner, there’s wisdom in recognizing the limits of your knowledge.

The most dangerous IT professional isn’t the one who says, “I don’t know.” It’s the one who doesn’t know that they don’t know. Technical competence includes knowledge and experience, but it also includes judgment. It means knowing when you have enough information to give an answer and when you need to investigate further. We discussed that last week in the blog about the Dunning-Kruger Effect.

The next time someone asks you a technical question and you don’t know the answer, resist the temptation to bluff. Say you don’t know, then explain what you’re going to do about it. Admitting you don’t know doesn’t undermine your competence. When you handle it correctly, it demonstrates it.

Next Level IT Customer Service Training

Enroll your team now in Compassionate Geek IT online customer service training so they can work together, get things done, and take care of customers.