13 Leadership Mistakes and How to Avoid Them
Post from July 8, 2019 (↻ May 29, 2021), filed under Everything Else (feed).
Like many of us, over the years I’ve managed and I’ve been managed. In different roles I’ve seen a few approaches to team management and leadership that worked, and some that didn’t. Here’s a brief and scrappy list of the mistakes I’ve witnessed (or myself committed), together with thoughts on how not to make them. The list isn’t exhaustive—leave your thoughts and observations.
The “you” in the following targets not you but the hypothetical manager who makes all those mistakes. Definitely not you, then.
Not communicating, or communicating one-way only. There are secluded managers and managers who talk 90% of the time. And yes, there’s a time to be quiet and a time to talk—but these times are not all the time. Communicate, and leave others room to communicate, too.
Not responding. There are managers who don’t respond. At all. Granted, they might be busy, super-busy. And they may be at a level of the company that they’re dealing with problems at quite another scale, too. But assuming levels and scales to be in reach, not responding is a bad habit. If you don’t have the time, respond with that, and delegate if possible. Don’t slow down the company by turning into an unresponsive (and increasingly irrelevant) bottleneck.
Not keeping in touch. Another mistake is not to stay in touch with reports. No communication in writing, no communication in speaking, no status updates, no 1:1s, nothing. While one can manage leaving team members on quite a long leash, this management style is called negligence.
Not showing active interest. Probably all interrelated, not showing interest in their teams and reports is likewise a managerial mistake for it begs the question why (even how) the manager was a manager in the first place. A “good” manager is interested in his team (and other people in general) and doesn’t govern by disinterest, distance, and ignorance.
Not maintaining an open door policy. At Google we have emphasized the policy of managers being available and having an ear for their reports. (Other companies, of course, have similar policies.) Staying removed from teams is a mistake for several reasons, ranging from severing the personal connection to hindering professional information flow.
Not delegating. Usually the less experienced managers almost appear to cling to tasks, not realizing (or fearing) that they can give work and responsibility to someone on their team. This is a mistake not just because it adds to the manager’s workload but also because it fails to trust and therefore doesn’t make good use of the team. (It gets worse when a manager also procrastinates the work they miss to delegate.)
Micro-managing. An overt interest in and interference with operative work is popular with people who like to control or like being “boss.” It’s a terrible habit that may not originate in mistrust but that spreads it, and one that is all the more poor managing and leadership, for the micro-managing manager makes neither good use of their nor their team’s time.
Not knowing one’s limits and boundaries. Some managers feel like they know about everything or need to know about everything. Context can only tell whether such sentiments are justified, but in many cases both means that respective leaders overstep their bounds. Grave side-effects once more include deterioration of trust, and then also a misuse of resources. Trust and use the specialists, for specialization is the value they bring.
Not knowing when to step aside. I suppose the Peter Principle (or the Dunning–Kruger effect?) to rear its head here, for some leaders just don’t know when they’re not good at leading, in order to step aside, or down. Many of us have probably been at companies where superiors performed worse than their teams yet failed to recognize that, even in the light of data; and they would cling to their posts and even suggest those actually running the show to leave. I’ve seen such things to turn into rather heart-breaking dramas, where everything but competence remained on a team.
Not acknowledging or rewarding good work. Some managers are pretty good at not acknowledging, let alone rewarding, good performance. I’m not here to speculate on the reasons but just to point out that that’s a mistake: If your reports do good work, tell them so, tell the team, tell the organization, and think about how to reward exceptional performance. Being oblivious to good work is not saving but wasting the enterprise.
Not offering career options. You may know Nielsen’s usability adage that “users spent most time on other websites.” These days, the same holds for employees and our teams as they also spend most of their time elsewhere. From my perspective a good manager has an eye on the career paths of their reports and tries to help and improve them. Yes, you could just say “what do I care,” but that just means you’re probably not that great of a manager. I don’t want to turn this into a petitio principii but merely recommend to make your team’s current and future success your very mission.
Not working with goals. When I came back to Germany and talked to or interviewed with companies I noticed that many wouldn’t work with goals, let alone OKR. In combination with yearly performance reviews that smelled like disaster to me—how would anyone in such a yearly review know what got accomplished, and how anyone performed? There’s a lot of gray area here as it’s not the point to discuss the varying degrees of how one can work with OKR, however set goals, have goals, work with goals. For the good of yourself and your team.
Not hiring people who are better. At Google it was one express aim to hire people who are better than us. That does sound a bit strange, and it took me a while to get it, but this is a really important mindset to adopt for recruiting. If you only hire people who perform as good (or worse) than you you may cement your position, but the company is not going to grow and mature—it’s going to hell. Hire—and cherish—people who are better than you.
❧ Among the issues that I believe should be watched out for the most are lack of communication as well as micro-management. They’re a thing, and they’re problematic. Yet even though it takes more than just a quick sketch like this, we can all become better managers and leaders. If we choose to.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
On July 8, 2019, 23:25 CEST, J.Wan said:
“Career options” is a good point. I believe that one is often neglected. I could think of twenty more things but this is good.
On July 9, 2019, 20:57 CEST, Lucas Mijnhof said:
@Wan, feel free to share those other things 😊
@Jens thanks for sharing this. The biggest problem I see is the Peter principle…you would not guess how often I had it that someone just blocked the way for brighter team members to advance.
On July 17, 2019, 19:16 CEST, Leo said:
I think this is a difficult subject. I’ve had some pretty shitty managers but frankly their situations were often shitty too. Sometimes there is no good way of managing a team especially if the team doesn’t want to be managed. This is a good list in that it includes some pretty bad communication problems though.
Maybe this is interesting to you, too:
- Next: When to use “img,” “img@srcset,” and “picture” and “source”
- Previous: Image Compression: How to Super-Easily Set Up Automated Base Optimization
- More under Everything Else, or from 2019
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.