Humble Pie Actually Tastes Pretty Good
This consultant started at the company on a 3 month contract when he was fresh out of college. His last day is next month… unless we extend his contract, since there’s some loose ends he could tie up for us.
When I was pretty early in my career, I had the opportunity to work with a consultant who was on a six-month contract at my employer. He had been hired before I was to build an Active Directory and Exchange environment for the organization as they didn’t have the in-house expertise to do so. I was effectively hired to come onboard and take over responsibility as he phased out, because apparently you can’t just keep consultants around forever.
I had recently completed a ton of studying and had successfully passed my MCSE with specializations in Security and Exchange beyond the base Windows skillset, and so I took that knowledge and viewed almost everything through the lens of some experience, but quite a bit more self-study in a lab and working through Mark Minasi’s books. I would occasionally ask this consultant (let’s call him Ralph) what the logic was to a certain setup or element that I didn’t think was in compliance with best practices. I was often rebuffed with a curt answer and no real explanation.
One time though, I was absolutely certain something was wrong. Without getting into the minutiae, it had to do with how group policy was being applied. The way it was built assumed that the domain policy would trump the policies set a lower OUs, which is exactly the opposite of how it actually works. I wanted to make extra-sure I was right, so I built a quick demo in a lab and proved that the policy application wasn’t working as intended. I then asked in the least confrontational way I knew how if this was an oversight. I’ll never forget Ralph’s response: “You must have done it wrong.” I was so stunned that I thought he might actually be right. I went back and triple checked my work and hung around late into the night trying to figure out how I had screwed up. It wasn’t until I was driving home that I realized that he was just wrong. He was wrong and he was trying to bluff his way out of it.
So, our debate in the conference room was somewhat less dramatic than this, but this captures my heartrate during that discussion pretty well.
The following day was stressful in that I needed to go back to him and be more assertive; I was certain that the way he had it setup didn’t work as it was supposed to and was going to cause some problems down the road. I tried addressing it directly with Ralph one more time, but he didn’t take too kindly to that. When we had our next staff meeting, I decided to mention that I thought I had found an issue in that forum. Ultimately, I ended up prevailing and convinced everyone around the table that the proper implementation was actually the inverse of the way it was set up. I told them I could fix it in a few hours and after the clients refreshed policy, we’d be fine. Ralph, who was already a reasonably standoffish kind of person, effectively forgot I existed after that - which is no small feat considering we shared an office in an old mill building.
Barely a week later, I found another example like this, but it was related to how message routing was setup in Exchange. I ran a few tests in my lab, documented the solution, and brought it to Ralph. Ralph once again insisted I was wrong. This time, I didn’t bother triple checking my lab, and brought it up in staff meeting again. This time the team manager quickly gave me the go-ahead to implement my changes in spite of Ralph’s protest and quickly moved on, ending the debate. After the meeting, I went to implement the changes, and quickly realized that my lab and the production environment had a somewhat different flow setup because the lab didn’t have a third-party spam filtering device integrated. I was completely and totally wrong.
I quickly found the manager and told him I had screwed up and that Ralph was right. I found Ralph, told him he was right, and I was sorry about calling him out like that. He gruffly accepted the apology, but I don’t think he ever really forgave me. His contract ended just a few weeks later and I’ve not heard from him since in the nearly 16 years since this happened. At the next staff meeting I also let everyone know that I had messed up and the original design was still in place and functioning properly.
A decade and a half after this happened, I still think of it from time to time, and I use it as an example of why humility is a huge asset as a professional technologist. In fact, when dealing with any technical or specialized skill, being a know-it-all is ultimately going to be a downfall for you. If you don’t believe that right off the bat, let me give you a few reasons why I think it’s the case.
First: if you act like you always have the answer and are just the best at a particular skill, you’re running the risk of explosive deflation. The very first time you’re proven wrong and that image of infallible perfection is burst you will lose a ton of credibility that can be really hard to get back. Look at what happened in the example above: the consultant that was hired to build a project at my employer argued that he was right until it was proven beyond a shadow of a doubt that he was wrong. A bit must have flipped in my manager’s mind as a result of that because the next time a conflict came up even though Ralph was right, he was immediately shut down and overruled. His persona as an infallible engineer was crushed and immediately replaced with the persona of someone who couldn’t admit anyone else saw something he did not. Consequently, his influence plummeted dramatically.
In contrast, I ended up being wrong almost immediately after but called it out myself. It would have been pretty easy to just pretend I reconfigured flow and everything was working just fine after my brilliance, but I admitted I had it wrong and tried to give credit where it was due. I certainly don’t think I’m some sort of paragon of virtue when it comes to admitting mistakes, but in this case I was able to show that I am willing to admit when I’m wrong and grow. Therefore, I gained some reputational credit for being open, honest, and direct. The net effect was that people trusted me more to do the right thing for the team and the organization. I demonstrated that I put the group’s needs ahead of my own.
Look at this arrogant jerk. Someone needs to tell him to study up, because he’s not nearly as smart as he thinks he is.
Today, now that I have responsibility for hiring administrators and engineers, I think humility is a key component of what makes an excellent IT pro. You have to be willing to learn to be good at IT as a whole, otherwise you end up as the best Windows NT administrator in the unemployment line in 2020 – because no one needs that skill anymore. Perhaps more than any other industry in the history of humanity, IT is one defined by change, and in order to be able to change and grow you have to accept that there are things you do not know.
Along the same lines, some of the very best technologists I’ve ever met have their stories about times they screwed up royally and caused damage. In fact, most of them have more than one. This is a key piece of having and exhibiting humility professionally – recognizing and coming clean when you screw up. People appreciate a story more about professionals who learn from their mistakes than they do one who has a preternatural ability to always be right. Robots are always right, but people make mistakes - Great people learn from them.
If you only take away one thing from this post, I want it to be this: being humble and admitting you don’t know something or that you screwed up doesn’t erode your reputation. In fact, it almost universally improves it. If you believe me, then my first recommendation to you is to realize that you either already have screwed up or will soon. When you do, come clean about it and use it as an opportunity to find out how to get better. My second recommendation is to acknowledge that you have colleagues that know things that you do not and that your skillset is not infallible. You have things you need to learn.
Ultimately, humility is exceptionally powerful because it removes barriers to you getting better – and removes barriers for people seeing you get better. And when people see you getting better, they’ll want to get better too, so it’s kind of the gift the keeps on giving.
Questions for Reflection:
Have you ever worked with a know-it-all? Were you around long enough to see them mess up?
Can you think of a time you screwed up visibly? How did you handle it? Would you do something different now?
What’s the next thing for you to learn to keep you technically proficient? When will you start?
