A rant on bad leadership

Posted by Tim Zöller on April 07, 2021 · 13 mins read

Why am I angry?

Earlier this month I ended my time away from Twitter with every intention to be more positive and promote good things, instead of being negative about bad things. But this morning I read a Tweet that made me furious (not about Oli, of course, it’s about the content):

A rough translation: In Aachen, a german city, an error in a software caused delays in a vaccination center, slowing down the vaccination campaign to stop COVID-19. In an interview, the chairman of the entity responsible for writing that software claimed, the developer responsible for the bug was identified, and that she cried when it happened. But, not to be worried, other people on the team were now tasked with fixing it.

This rant is not about software in the public sector being sub-standard far too often (and QA processes being non-existant, in this case), this is about the poor treatment of that developer and the general understanding of leadership roles, which makes me livid.

What experience do I have with leadership?

At my previous job I was the lead of a team of ~10-12 people from 2015 to 2020. I was promoted in 2015 because I was a good developer / consultant, nothing in my behavior or my background qualified me for a leadership position. That’s right, being a good developer does not qualify you for leading a team. I had some months to prepare for the role, and luckily I found my way to two excellent german podcasts on the topic: “Leben Führen” by Olaf Kapinski and “Führung auf den Punkt gebracht” by Bernd Geropp. Both also host english podcasts now, at https://liveitleadit.com and https://www.berndgeropp.com. While I was driving from and to work, I devoured most of the podcast episodes that were already online, and both Bernd and Olaf pointed out one thing pretty clearly: Leading a team was a completely different skillset than being a skilled worker in your profession. Luckily, they provide their listeners with both tools (e.g., one-on-ones, feedback…) and a better mindset. I also enrolled for two years in Olafs “Leadership Stars” program, which taught me a lot more and also connected me to great people in similar situations than I was. I won’t go into much detail what I learned there, but point out that I was concerned with finding out what good leadership is for the last 5 years and still am. From the feedback I received, I believe I managed to do a good job as a team lead.

In the past I was hesitant to write about this topic. The reason for that is, that my experience in leading and managing a team is limited to the role I had at my previous job, while my technical experience could be applied at a far bigger field of situations. My impression was, that while I learned a lot and got better at applying my knowledge on that topic, I was not in a position to publicly speak or write about it. The example above, however, and many more examples I have experienced first person and second hand shows, that, at least in tech, being a better-than-average boss is such an unbelievable low bar, that you can pass it while crawling, so here is a rant in 5 parts.

1. Being somebodys boss doesn’t make you a better coder

I believe it was Olaf Kapinski who told me “If you are the most skilled worker in the team you are leading, you screwed up”. Do you think you are a better software developer than anybody on your team? If so, will you code all day, instead of doing your real job? Will you be the one making technical decisions all day long, doing architecture? Yeah? Then you are doing it wrong. Your team does not need you to do this. In fact, if you are in meetings all day (because, well, that’s part of your job now), they don’t want the hot shot wandering into their office between two meetings, telling them how they should do their job and to undo that thing they did. Your coding days are mostly over, accept it. Your team consists of skilled people who think about hard problems all day, can you really do that better? Thought so.

2. You are in a support role!

Your team does not work for you, you are working for your team. Your responsibility is to provide a climate in which good results can be achieved. You are responsible for these results. Yes, even if your company is doing some kind of agile development. Yes, even when you are on vacation. Do you know what a good indicator of that responsibility is? Your paycheck. I am not sure who I got this quote from, probably also Olaf, but “Leadership means to accept being fired”. Your paycheck is higher because of that risk. From this fact, we can derive your actual job description: Make sure that your team will deliver the best work possible. We are talking about professional and personal growth, here. We are talking about motivation, we are talking about a good and healthy work climate, we are talking about communicating visions and agreeing on goals. These things cannot be achieved with applying pressure, and also not with throwing money at them. If you don’t know where to start with supporting your team, try talking to them for once.

3. You cannot shift blame to individuals

This might also be obvious to sane people, but aparrently there is a lack of those in some companies. If something bad happened, either by accident or because your neglegience of your team, you can not ever, possibly, in any way, single a person out from your team and blame them. If you do this, drop everything, leave your job, your company, the industry, look for a job that does not require you to work with humans at all. Maybe try digging for gold on your own. To underline this, here comes another quote, that I have to attribute to Olaf, again: “After some period, every executive has the employees they deserve”. If your team is making mistakes all the time, if they are delivering “bad performance” (whatever that is), then it is because you either failed to support them in their personal and professional growth or because the climate at work, which you helped create, is bad. There are really(!) some managers walking around saying “My team is full of idiots”. Well, is it because you hired “idiots”, or did you start with good people and turned them into “idiots”? Also, if you ever call people on your team idiots, try above career advice about gold digging, too. So, what will you do, if there are mistakes made in your team? You grow a spine and take the blame for it, when reporting to your boss, your stakeholders, your investors or the deity of your choice.

4. Your most important skill is empathy

If you call your team members “resources”, stop that. No, not saying “You are my resources” to their faces is not enough, you should not say it to your peers, your boss, your wife or your Dachshund. If you need a new word, try “people” or “humans”. Then maybe it will get into your head, that humans will have human problems. When their kids get sick, their dog died, their parent with dementia had a bad day or they got a bad medical diagnosis, they won’t give a shit about deadlines. Well, they might pretend to, but their mind will be somewhere else, yours would be, too. Your job is to understand that. You have to be able to put yourself in your employees shoes! If an employee asks for two days off in a critical phase of a project, there might be a good reason for it - ask them. If the “performance” of a person is dropping suddenly, there will be a good reason for it. Ask them if everything is alright. If a person who is usually quiet starts getting more and more angry, talk to them. Everybody will react differently to stress, grieve and worries. Telling them to “work better again” won’t change a thing.

5. It’s about trust, stupid!

This is the paragraph pulling together the previous ones. If you really want to do a good job, you need to have your teams trust. You are relying on your team members telling you when there are problems, when something is not going well, when there is an issue with the work-climate or even if they are going through a rough time, personally. It is often said, that trust needs to be earned, but my experience is, that people in general want to trust you in the beginning. Your job is as simple as not screwing that up with your actions. You won’t know that your current software release is unstable, if people are afraid of telling you this. You won’t know, that there are systemic problems in your company, if people think it has no use talking to you, you won’t change anything, anyway. You won’t know about tensions in the team, if people think that you are less empathic than the chair you are sitting on. And you won’t know, that you cannot rely on your brilliant lead-dev being their usual brilliant self in the next months, if they won’t tell you that their parent is in the hospital. And they won’t admit doing a mistake early on, if you have a history of throwing people under the bus, if they do so. And the bad news don’t stop: In order to being trusted, you have to be vulnerable. Tell people about your situation, too. Admit mistakes. Communicate if you are not feeling well. Apologize for things worth apologizing. Talk about your hobbies, from time to time. And if you are now reading this and wrinkle your nose about this feelgod-hippie-empathy-bullshit, then try and see it from a capitalist point of view: You don’t know about issues in your software if you don’t have logging and monitoring in place. You don’t know if it crashes on your users, you don’t know if it becomes unstable, you don’t know how to fix it if it breaks down. The people in your team are not software components you can monitor, they are humans. If they tell you about problems is their decision, not yours, you cannot order them to. But if everything breaks down, and you have run out of people to blame, then accept to get fired.

Disclaimer: If you follow advice in this rant it might help you to become a better leader and achieve better results together with your team. It will definitely interfere with your next promotion at Accenture, McKinsey, BCG or similar companies.