Lessons Learned from Ineffective Leaders — part 2:
Now, what is there to learn from bad leaders? — a lot, actually.
Just as observing and analyzing how great leaders behave, inspire and make us want to follow them, observing and analyzing weak leadership teaches us what to avoid doing.
I am genuinely thankful to all leaders and managers who offered teachable moments. Without weak leaders/managers and those moments, I could have easily made the same mistakes or, conversely, it would have taken me that much more time to learn what works and what doesn’t.
Let’s jump to it:
Software developers (I’d extend this to all functions) don’t do well without a team (aka as singletons) — they work better in a team and they are happier on teams.
It’s common knowledge that companies group software developers into teams. Even when I was trained to be a software engineer in the Israeli army, on the second part of a 6 month programming course they started grouping us for our multi-day simulation tests. First, into groups of 3 and later into groups of 7. This was designed to demonstrate that teamwork and collaboration are skills that are key to developing during your professional training. I always took the construct of a team for granted and could easily come up with reasons for that.
Back then I wasn’t part of the company’s R&D but I owned the development of a small product/module for our customers. At first it was great, I learned a new technology and delivered some preliminary versions. A few months into this endeavor, I came across some roadblocks. The code felt a bit convoluted and I found myself alone without anyone to brainstorm problem solving with or to help me improve my code by reviewing it. It dawned on me that as a singleton, I’m limited in my ability to improve the product and myself. I only knew what I knew, I can always search and learn more but when you collaborate with decent peers they almost always push you and your work to be better.
I’m sure I would have learned this lesson later in my career or in a different set up. If I’m being honest, 7 years ago I found myself making this mistake again (letting a single developer work alone on a codebase). But the power of experiencing this first hand, gave me a really good understanding of what it feels like and the issues that come with it, for the engineer and for the company.
Don’t let software engineers own a code base on their own. Even if they want to — they very often do not understand the implications of that desire. It sounds magical, no one to coordinate with, no slow downs. Just me and my code — the sweet life! I’ve seen this fail each and every time, with myself first and then with my team.
- Professionally speaking: those developers can’t grow nor learn (as much as they do on a team), they won’t get challenged as much and of course if god forbid they leave or go on vacation you have no knowledgeable backup.
- Emotionally speaking: they will get lonely, unhappy, bitter, or worse, experience god complex (without anyone to challenge and ground them).
Since the early days humans grouped up, we learned that interactions with other humans are good for us 🙂
Not all developers can be good managers. It’s often said that employees are a company’s most important resource, and people managers are on the first line of communication with them: ensure they are worthy of that role and competent.
If you read the previous 3 lessons in this story, you hopefully understand what can go wrong when you choose the wrong person to manage your employees. Companies often choose the first person in a site or team to take the lead when the site/team grows. It’s a very common pitfall for startup companies: you need a technical person, you hire someone who can code really well, and then the company does well and grows and now you make that person the manager. And they, sadly they often willingly accept the role, either due to the attached prestige that comes with it, or because they want to try something new. Whatever the reason is, the skill set and aspirations of a great coder do not match those of a great manager. I won’t get into the making of great managers here, there are whole books about the topic, I’ll just remind you that these are 2 distinct roles, and not everyone can do them both well.
Do due diligence when choosing a people manager. Later in my career, when someone on my team (or a friend) came to me and asked to be a people manager, my first instinct was “beat that crap out of them, if they still want it, that’s ok then”. In practice I would ask them a lot of questions, mostly about what drives them to be a manager, what a great day as a people manager looks like, and where they find fulfillment. Red flags were: “I want people to listen to me”, “I don’t like coding”, “I want more money”. Green flags were: “I love helping people grow”, “I enjoy helping a team achieve more than one person can”, “I already spend most of my time driving knowledge sharing”. Managers should opt in to the job, and for the right reasons, if they are unsure — don’t push them, you don’t want a sour manager bringing the whole team down.
As you can see, we can learn as much (if not more) from bad leaders as we can from good leaders. Their mistakes, poor judgment and bad behaviors serve as valuable lessons for us. Remember that no one is perfect, not leaders, nor are we. We all have shortcomings and strengths. So the next time you encounter a bad leader, don’t just shrug it off. Take a moment to reflect on what you can learn from the situation and channel it towards personal growth to improve your own leadership skills.
I wish I could tell you this is the last lesson I can offer. I can’t say that. But wait, there’s more! In hindsight, the last four lessons focused mainly on weak management skills. The next few lessons will focus more on the leadership aspect of the job, and how weak leadership negatively impacts people and organizations.
What did you learn from a great leader? Did you experience an ineffective manager/leader? Do tell!