Dumb Leadership Mistakes I’ve Made
You will need to make these mistakes for yourself.
I’m sharing here to give you some language around these mistakes, in hopes that it helps you recognise when you make them, and you can accelerate your own learning.
Dismissing intuition. Intuition has a bad reputation of being emotional and subjective. In reality, it’s a summary of millions of interactions and experiences — data points — that you’ve accumulated in your career. Then you are doing some crazy hind-brain computations on all of those data points and coming up with a judgement. There’s a reason that you think that way, so don’t dismiss it. I used to downright ignore intuition in a lot of circumstances because it wasn’t “logical” enough, or even because it felt unfair at times. I’ve worked on strengthening some skills around my intuition that help me harness it more effectively. It comes down to this: show your work. Intuition often relies on cues from body language, pattern matching from past experiences, details in presentation, etc. Get clear on what you observe and how it influences your confidence. Then nail down a clear answer on this critical question: how will I know if I am right?
Data-driven theater. Many times I’ve ignored intuition because being “a data-driven decision maker” was part of my identity. But it was a load of crap. Even if I had access to good data (which I rarely did), I was not in a position to actually use it to make decisions, because that was not part of the muscle of my particular org at that time. As an executive coach, I see this pattern in many leadership teams I work with. Two things can be true: you can want to be a data-driven or data-informed org, but not have access or opportunity to do so. Instead of lying about it (to yourself and others), be honest that you’re making decisions based on mission or vision, but not on data. The biggest mistake here isn’t making decisions without data (though I would encourage you to do otherwise), the mistake is believing you’re data-driven when you really aren’t. It’s hard to become data-driven when you falsely think you already are.
Trying to be smart instead of making other people smart. For a long time, I thought credibility made a person trustworthy. Deep down I knew this couldn’t be true; I’d worked with enough “brilliant assholes” to know that credibility couldn’t be everything. Still, earlier in my leadership career, I relied on expertise as the main way to gain people’s trust. This meant that I operated in solving mode more often than I should have. All of those things I solved could have been (sometimes better) solved by my team, and I took the opportunity away from them to protect my own ego and desire to “stay technical.” This mistake doesn’t just apply to situations with your direct reports. When explaining technical subjects to your peers on the leadership team, your goal for is for them to first understand what you are saying, and then second to gain independence with the topic so they can build on the foundations you are helping them build. The point of those conversations is not for them to walk away thinking “wow, they are so smart — they used a bunch of words I didn’t understand!” Even if you don’t use precise terminology, focus on explaining the concepts. This won’t be your last conversation about it, so you don’t need to cover every detail. It’s your job to figure out how to explain it so that it make sense, not theirs to try to decrypt a bunch of jargon.
Not utilizing experts soon enough. I believe in hiring people who also have with the “most everything is figure-out-able” gene. A lot of startups prefer to hire this kind of person too. But brute forcing your way through a problem costs a lot of time, and time can be even more scarce than money. Look to an expert to answer specific questions for you, or to provide support in an area where you haven’t built up muscle yet. You do not need to hire a full-time employee to do this — that’s another mistake. There are tons of experts out there who work on a project basis. These are one-off costs that save you time.
Not realizing that I’m not an engineering leader. I’m a business leader. Yes, expertise in engineering is important and it’s critical to do my job well. But I had to stop just thinking about how my decisions would impact engineering, and think about how they impact the product and the business. This is a skill that is underdeveloped in a lot of engineering leaders, simply because it hasn’t been expected of us in the past. Our reality is different now though. Engineering leaders are being asked to show their work and provide data and metrics to show both the impact of their decisions and the performance and contributions of their organizations. Beyond reporting up to your execs and board, being able to articulate the business impact of what you’re doing makes you a better partner to your peer leaders in other parts of the org.
