We Can’t Know Everything All The Time

A non-technical post today. As a disclaimer, this post is not aimed at anyone I know in particular. It is based on personal observations that I have made.

Over the course of my career, I have worked with many folks. These people may have been subordinates, peers, or leaders. At times, I have noticed at all levels a similar reluctance to admit that something was not known. I’ll be the first to say that I have definitely been in this boat. It is still something that I try to be conscious of. Unfortunately, I still see it quite often in others (a likely in myself after enough self-reflection).

This not knowing might be technical in nature, such as if we are having a technical discussion and a solution is proposed. The ‘not knower’ may just agree to it despite not understanding why the chosen direction. This doesn’t do good for anyone. On my end, I believe that we have just put an issue to rest and they will handle it. When the time comes for action, things might not go well. The issue may be mishandled due to not knowing how / why to proceed. Or it may be ignored in the hopes that the problem will fix itself. Unfortunately, I have seen issues pushed aside many times. It almost appears as if they think magic will solve the problem.

I recall a situation a few years ago where we knew exactly when a process was going to fail (e.g. in a few hours). Rather than bring the service down for emergency repairs, we evaluated the risk and planned an emergency outage at noon. We advised employees to save all work (and make local backups just in case). An email sent out indicated about 15 minutes of work (in reality it would take about 5 minutes – Scotty Principle). I was not in the office, but I called in and reviewed the plan with a sysadmin. He completely agreed that it all made sense. I asked him if he understood the issue, and if he had any questions or concerns. I received an ‘all good’ from him.

I had to be offline when the predicted failure occurred (and it occurred exactly as planned). When I came back online 40 minutes later I was greeted with a slew of emails and voicemails. These came from staff and a sysadmin who appeared to have no idea what he was doing. I quickly found out that nothing was done at the designated time. The sysadmin appeared to have lied and did not understand what was going on. Had he followed the plan ‘we’ put together things would have kept on rolling. Based on log files, and what users saw, he was more or less just clicking around the vSphere interface.

Was I mad? Yes … and the employee was shortly terminated (there were more issues). I was upset because had they said ‘no I don’t understand’ we could have reviewed or altered our timeline to accommodate. Instead, we ended up with unplanned downtime and a lot of upset users.

I understand that people can’t know everything all the time, and believe me, I am intimately familiar with that. But if someone asks you if you understand (whether it be technical or non-technical, a peer or a subordinate) and you don’t, then say so. Do everyone a favour and be honest. Chances are you will actually learn something new in the process. You may also gain trust from other people for being honest.

Note: I actually had this post as a draft for awhile now. I just finished reading Duncan Epping’s post How do I get to the next level – Part 2 and was inspired to finish this off and hit publish.