Knowing and not Knowing
In the IT field, people have the expectation that we’ll always have an answer or a solution. The problem is that we usually don’t have the answer. A lot of the time, we don’t even have the beginnings of a clue. Your reaction when you don’t have an answer speaks volumes. I’m going to use a story to illustrate this point.
The Story
Adam and Bill work together at Amalgamated Spats. During a design meeting Adam mentions a product that could solve some of the problems the developers at Amalgamated Spats are facing. Although Adam is a specialist, he has a great deal of work on his plate and Bill is designated to develop the features. Bill isn’t a specialist, he’s a generalist. Bill is a great developer, but he’s unfamiliar with this specific product. Over the course of development, Bill makes great strides. Unfortunately, there are some features that he isn’t able to solve programmatically even though they are included in the product. These features are features that were sold as part of reason to use the product. When Adam and Bill’s manager talks to Bill about his progress, Bill tells the manager that he wasn’t able to get the features done because it isn’t possible using the product. The problem is that the features do exist in the product, they just weren’t available the way Bill was using it. Adam and Bill’s manager is upset that they’ve put so much faith in this product. While the manager trusts Adam, Bill has been working with the product day in and day out, trying to implement these features – why wouldn’t Bill tell the truth? As a result, Adam loses credibility. He can get that credibility back, and certainly will, but for a while it’s gone.
The Problem
There are a couple of problems with this situation:
- Bill has effectively thrown Adam under the bus (we call this bussing). Adam has lost credibility with the manager because he gave “wrong” advice.
- Bill said “No” when he should have said “I don’t know.”
Of these, the second is far worse. Ultimately, the first problem will go away and Adam will gain that respect back and everyone will be happy again. But the second problem speaks volumes.
It’s Not Okay to Say “I don’t know”
But I just said that Bill should have said “I don’t know,” right? Wrong. Saying “I don’t know” and ending it at that is not acceptable. In this crazy software development world, it’s our job to find the solutions to problems. Did you read that correctly? I didn’t say that it’s our job to code the solutions to problems, it’s our job to find the solutions to problems. Sometimes the solution is to use an existing solution or feature which you can only find through research. Do you see what I’m getting at yet? “I don’t know” isn’t acceptable but saying “I don’t know, but I’ll find out” is perfectly acceptable.
What’s the difference?
When you say “I don’t know” and you stop there you’re effectively throwing your hands in the air and giving up. You’re not only admitting that you don’t know, but that your lack of knowing is the end of it. It ends the conversation If you say “I don’t know, but let’s find out,” you’re telling the other person that you don’t know the answer and it bothers you. It bothers you so much that you’re going to find out the answer. You’re advertising your inquisitive mindset and the way you solve problems.
What Should I Do?
The next time someone asks you a question where you don’t know the answer, tell them you don’t know. Be completely upfront about it. Follow that up with “but I’ll find out.” Then, actually find out the answer. Research the problem, research the product, and consult with experts – even if you think you are one.
