I’ll never forget the first time I got really mad in the office. This was pretty early in my career when I was the hands-on senior engineer responsible for the Active Directory, Exchange, and the (very, very new) VMware infrastructure. I took a lot of pride in our environment and spent quite a bit more than my “full time hours” just watching it. If I do say so myself, it was probably the closest-managed environment for an organization our size. I wouldn’t just review alerts – I would actually watch the queues and run replmon in between other things – even if those “other things” were spending time with family or having dinner with my fiancée (now wife).
We tell kids not to lie, but is bluffing that you know something you don’t a lie?
Yes. Yes, it is.
I had just reviewed the environment and it noted that everything was running pretty well, and thought that I should probably get something at the Dunkin Donuts next door. As a side note: if you have a coffee problem (as I did back in 2006), having a Dunks in immediate proximity to your office does not ultimately benefit your quality of life. On the way down the hallway, I was walking by the phone support area and overheard one of the phone technicians say: “…yes – we know there’s a problem. The email servers are down.” I stopped in my tracks, backed up, and walked into the phone support area. I was aware of no such outage, and needed to investigate.
I poked in that technician’s cube and asked what he was seeing that made him think the email servers were down. He said that the user was getting password prompts in Outlook. After a brief conversation, I asked that tech to check on the user’s account – and it was locked out. They were getting password prompts because their ticket expired and the account was locked out due to a bad password. This is all expected behavior. I got pretty pointed with the tech and asked them why they said the email servers were down, and their answer – poor as it was – was that they didn’t know what was wrong, so they made something up.
Zack Morris would have been a great IT pro, you know… if he wasn’t such a jerk.
Let me pull a “Zack Morris” and stop the show to talk to the camera for a second. I would like to report that I used this as a coaching opportunity and helped this technician grow. I did not. I was young, and I was almost certainly brusquer than I should have been. I was angry – I felt like this kind of bad answer made IT look incompetent and/or poorly connected and even worse – made my services seem unreliable. I wasn’t entirely professional and I should have done better. How I have grown in this area may be a topic for another post – I have digressed.
This kind of fibbing is maddening to me because it served absolutely no purpose. The end-user got no service, the technician got no benefit, and everyone had a worse day because of it. Worst of all, this was not the first time I had seen something like this happen. I’d seen it in electronics stores, conferences - and now my own IT shop.
I think we can all agree that this story is a pretty extreme case of making up an answer, but I am shocked how often this comes up in IT. From talking to paying customers where you are supposed to be the expert, to that person who just keeps asking question after question after question to the manager who expects immediate gratification or answers – there can be real pressure to make you feel like not knowing is an unrecoverable unforced error.
And let me be clear - I’m not immune to feeling like I need to make something up on the spot to save face, either. I’ve been caught in the situation where I feel like there is immense pressure to know the answer immediately – that people are looking to me to be the wizard that knows everything about this particular software, or infrastructure or service. All I can say is that every time I’ve seen it done – every single time – it comes back to be a lot more pain than it’s worth.
I know I got into technology because so often there is a right answer to something, and I love solving problems and finding answers that can be elusive. I also admit that I know the rush of being in a room full of people trying to figure out a problem and being the only one to solve it. I admit that I like that particular dopamine rush. In many ways, I think IT attracts people who like to understand things that many people find incomprehensible. It’s certainly not everyone, but I think a lot of us do like having a skill that isn’t as common as others. Lots of people try DIY plumbing for instance, but not many people roll their own DIY operating systems.
In spite of that, I want everyone reading this to know that you do not always need to have the answer. You do not need to be the infallible wizard. And if you ever feel the need to make up an answer to seem like you are – you’ve done yourself and the entire industry a great disservice. I’ve written before about how virtually everyone in IT is in the service business – and humility is an underappreciated quality in serving others. If you’re trying to bluster your way through something to seem like you have all the answers, you’re actively serving yourself and not the people you’re supposed to be serving. You’re attempting to make yourself look good – not make the team or company look good.
DuckDuckGo: It’s like the other search engines, but less evil. Also, patently ridiculously named.
This is so important to me that I try to get to it in an interview – I make sure we ask progressively complex technical questions, ultimately culminating in some that are effectively impossible to answer without consulting that great oracle of knowledge – Duckduckgo. (What? You use a different search engine?) Here’s the thing: I don’t care nearly as much about how well folks do on the technical questions as far as getting them right or wrong – I care how they let me know that they don’t know the answer. I want to see them have some humility. Why? Because I firmly believe there is nothing in the world more dangerous than a technologist who needs to make everyone else believe that they know everything. It’s a disaster waiting to happen. That’s how big red buttons get pressed without knowing the consequences.
So, since I have some evidence that there are a fair number of people in IT who like to pretend they know more than they really do, I wanted to give you two ways that you can say you don’t know and still come off gracefully.
The first way (and my personal favorite) is to just be direct and honest. Something like “I’m sorry, I don’t know, but let me take some notes and get back to you later today with some thoughts.” So long as you actually follow up it shows humility, resourcefulness, service-orientation, and perseverance. There are exceedingly few answers that you have to come up with immediately or risk severe consequences to the organization.
The second way is if you think that time is absolutely critical for whatever reason, you can defer to someone who is more likely (or guaranteed) to have the answer. An example would be “I don’t know off the top of my head. However Julia uses this stuff all the time and she would probably know immediately. Can I [bring her into the call | confer with her | etc.]?” This shows that you may not have the answer on the tip of your tongue, but that you know your team well enough to make sure that the job is taken care of in a timely fashion. It shows teamwork, dedication, resourcefulness, and a willingness to share the limelight.
Both of these options give you a graceful way to admit that you don’t know everything. And I want to repeat that you don’t have to know everything to be a great IT Professional! If you work in an environment where you are expected to know every answer right away, you are working in a toxic organization. That kind of pressure is not conducive to long-term success for you as an individual or for the organization as a whole. I think we owe it to each other to make sure that we all know that we don’t have to have all the answers.
If you think that we don’t need this as an industry, I dare you ask 100 IT Professionals how they would deal with retrograde JFABS errors in a SQL cluster. I guarantee you that more than you want to admit will spew out some garbage to make you think that they’ve seen it before – when you just made it up on the spot. And if you’re one of the people who would be tempted to make up how you wrote a script to fix JFABS errors, then please take this entry to heart.
And if you happen to lead people - if you are a manager or team lead - you need to know that your team doesn’t expect you to have every answer. They want guidance from you, but if your team is using you as the documentation for something they operate or manage, you have an unhealthy relationship with them. Your responsibility is to guide and coach them. You should never feel like you are a better manager when you know more than your team. You may have a broader view than they do, but you don’t need to know everything. I have found that I get more respect when I admit that I don’t know, because when I do know something and give some advice, they can trust it without hesitation.
So whether you are managing a team, an infrastructure, or a single server - you don’t have to bluff your way through your career. In fact, if you do try to make answers up someone is going to call you on it sooner than you expect and rebuilding your credibility is going to be an arduous task.
Some questions for reflection:
Have you ever caught someone making something up? How did you deal with it?
Have you ever been in a situation where you felt like you needed to have an answer that you don’t have ready? How did that make you feel?
What can you do to make sure that people in your team don’t feel like they need to know everything to be valued team members?