From Techie to Boss (48 months)

#leadership #reflection

This is it. Final post of the series, as I think the transition is now over. In this post I will try to recapitulate what I achieved, learned and messed up in the last 48 months.

Achievements

Of course one of the perspectives on being a successful team lead are the things you contributed to the company:

The fairy tale of managers not needing technical experience

There is this misconception that in order to be a manager, you just need to be able to create some sort of a plan for your team and then push them to reach that plan. In order to do this, you have to set up KPI's and track them daily. You do not need to understand what they are doing in detail, as your KPI's will give you insight if something is going wrong and then you correct it. You should empower your team to do their technical work and make decisions, which will keep them motivated and performing.

In my experience it doesn't work like that. If you are working in R&D and are leading technical teams, you need to understand at least 70-80% of the technical work and ideally you have done that, or similar work, yourself before. This is why:

Manage expectations

Before I started this job, one of my mentors told me to get prepared to be a complain box. This is a sentence I repeated a lot of times in my head in these 4 years and to other people, when they asked me about my key learning's.

Basically a lot of people (your employees, your boss, your colleagues, employees from other teams, people from the company you didn't know existed ...) will try to dump their complaints, problems, requests, tasks etc., on you. They'll call you up, invite you to meetings, come to your desk, send you E-Mails, message you ... put your communication channel here ..., and try to somehow engage you in stuff that's bothering them, that needs solving or demands your support.

This simple strategy should help you not overload yourself and actually focus on delivering what you are responsible for:

You can not solve all the problems that your team members, projects or company have. This is what the over-excited and over-motivated me from 4 years ago had to painfully accept, when I moved into stress levels that could have led to a burnout. You have only 24 hours in a day and 8 of those you should sleep. The rest needs to be divided between work tasks, private obligations, quality time with your loved ones and time for yourself. If you do not take time for yourself, you will burn out.

Accept errors

During my tenure so far not everything that I wanted to do or implement in the team worked. Sometimes I did something and it worked, e.g. team accepted it and it started bringing positive impacts. But a lot of times I also had to give up on something that looked good to me, but the people just didn't want to accept it. Of course you could try to push it thru with all the might, as you sometimes really have to do, but you should really be careful what battles you want to fight this way. At the end, you should not become a dictator ...

Accepting that something didn't work and openly saying “Hey, I wanted us to try this but it didn't work because ...” has two positive effects:

Also important ...

There is a ton of other stuff that is important and you probably read it somewhere else as well, so I'll just list it and not go into details:

What lays ahead?

There is a lot of tasks, projects, problems, errors ... laying in front of me in the future. But I am not over-excited, over-motivated, scared, overwhelmed, inexperienced ... anymore.

During my tenure as a team lead, as well as in my previous roles as project lead and developer, I gathered experience and confidence needed to tackle those things.

Will I get it all done correctly? Definitely no, but this is also part of the journey and a possibility to learn something new.