“I can live with doubt and uncertainty and not knowing. I think it’s much more interesting to live not knowing than to have answers which might be wrong.” – Richard Feynman
As a culture (both professionally and at-large), we have a real problem with the expectation that we always have the answer. Not just an answer but the answer – the answer that is both correct and, even more importantly, pleasing to the person who is asking the question.
We see it in interviews when we’re asked questions that we would never encounter in our day-to-day work and the literal answer for when we do encounter them is to do a bit of research. Algorithm questions are a good example of this, though my favorite example is probably when a couple of relatively newly minted developers decided to ask me how certain things in Java were implemented in the JVM (as in literally how they were written).
The largest part of our job as software developers, infosec people, devops, etc is research and thinking about possible solutions, tradeoffs, etc. It’s a normal, and indeed healthy, thing for us to say “I don’t know” and then to go off and find answers. We don’t have all of the answers and shouldn’t be expected to.
Even when we do have an answer, there may be a better answer that can be uncovered with just a little bit of looking. After all, bubble sort works and is pretty simple to implement from scratch, but would you actually use it for a production sized dataset?
Over the years, I’ve noticed a correlation between the refusal of people to accept “I don’t know” (followed by some variation of “I’d have to look into it” where appropriate) with people who are either absolutely terrible at their jobs or a nightmare to work with. Correlation isn’t causation, but this one seems to be a pretty strong correlation.
The worst example is arguably one manager I had who would literally make up answers to things in order to avoid admitting not knowing something. When the “answer” turned out to be wrong (sometimes disastrously) he would try to come up with some reason it wasn’t his fault or blame it on “miscommunication”. Even worse, he tried to get my mentees to do the same – going so far as to tell one of them that he was never, ever, supposed to say “I don’t know” to a person above him on the management chain.
This is after I’d spent a year trying to foster the psychological safety in my people to allow them to be comfortable with admitting they didn’t know something and asking for help if they needed it while looking for an answer. Thankfully my mentee came to me afterward and we avoided most of the damage that could have been done if he’d followed my manager’s demands – both from a standpoint of professional development and by not feeding wildly wrong information to upper management.
Saying “I don’t know” isn’t a bad thing. It’s the first step to finding out the answer. It’s a strength, not a weakness. Pretending to know is the weakness – it prevents you from growing and giving bad information can even lead to horrible consequences later.
Foster the mindset in the people on your team that they are allowed to not know an answer, provided they take steps to find a suitable one if it’s needed. Foster that mindset in yourself too and take it as a major red flag if your managers (or even worse, the organization as a whole) try to force you into providing answers that you don’t yet have without giving you the ability to think and look into a problem.