This year the company I work in did their bi-annual Employee Survey powered by Gallup. The company wide numbers came out same or worse then 2 years ago, but my team‘s Employees Engagement Index went up significantly. I was rated very good by the people I lead concerning my leadership skills and they showed way higher engagement values than the rest of the teams in our department.

After reflecting on it and talking to them, I think the reasons boil down to these two:

• Take responsibility and give your team focus by making decisions when they need it. We live in chaotic and volatile business times. People need clear direction and managers should be the people giving them what they need. Sometimes you can just say what has to be done in this week, so do that and be open about the „low visibility“. When the visibility gets better, then aim for longer time periods and loosen the „micromanagement“. The worst thing you can do, is to get afraid and try to sit it out. If you do that, the whole team will grind to a halt.

• Be authentic and treat your people the way you would want to be treated. I do not believe in the nonsense of „separate your personal and work behaviors“, because I think you would need to be a psychopath to be able to pull that out convincingly. E.g. when you are sick, do you want your boss asking you to join meetings or call you during your sick days? No, you probably want some words of assurance that everything will be taken care of, that you should go offline and have some (chicken) soup. The same applies if you find out that your employe has a sick child, wife has family issues etc. Treat them with respect and speak to them openly about the good things and the improvement points, they will come back to give you 150%.

Have any thoughts or comments?

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:

• I have hired 15 people to work for me directly and on-boarded 4 offshore engineering teams (6-8 people SCRUM teams) in order to be able to reach the project goals.
• Under my supervision the teams have defined testing processes and methods that successfully passed the ASPICE assessment.
• We also build a testing infrastructure including some 50 HiL benches, integrated some off-the-shelf testing solutions and developed additional tools, pipelines etc., needed to “run the show”.
• Last but not least, we delivered the results needed from us and helped the project reach it's first carline SOP.

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:

• Your employees will need on-boarding, guidance, understanding, help ... with their technical tasks. It's not possible to delegate all of these things to other technically more skilled people in your team. Of course you should get seniors to onboard and mentor your juniors, but if you exaggerate, then your seniors will at some point complain that they can not do their own tasks.

• Your employees will need help in setting priorities and making decisions. This is almost impossible, if you do not have enough technical experience to do this properly. Let's take for example that your team is responsible for testing some software:

  • If everything is 100% passed (which I would highly question 😆) , decision making is trivial.
  • If a test report shows 80% – 20% rate, they will probably come to you to make a decision. How will you do this, if you do not have either the experience to make the judgment yourself or know someone, who can help making the judgment?

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:

• Who is the person contacting you? If not on your priority list, ignore them in a friendly way 😝.
• Listen or read carefully, but do not respond directly no matter how many URGENT, ASAP, CRITICAL keywords are contained in the communication.
• Take a minute to think about the content and ask yourself “I am the first responsible for solving this?“.
  • If your answer is a definite YES, then add it to your TODO list.
  • If your answer is a NO or UNSURE, just don't do anything and wait it out. If it really is your responsibility, it will come back again either with more details or more push by people payed better then yourself.

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:

• You show the team that their opinions matter, dictators never last long.
• You show that you are human and make errors, which signals your people that it's OK to try something and fail, which is a path to continuous improvement and innovations.

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:

• Build yourself some sort of productivity system like GTD or Second Brain. I used the Brainiac. You will have more tasks, projects, notes, E-Mails, messages ... than you can process in your head. Make sure they do not get lost and you can surface them when needed.

• Treat peoples private life with respect and understanding. Any sort of stress or problems in personal area will directly influence the employees performance. Give them space and time to deal with it and signal that you are fine if they temporary cut down on their tasks in order to sort out their personal life. They will (mostly) come back stronger and more motivated to push things forward.

• Panic and stress are infectious. Of course your employees will see that you are under stress, as we are all humans. But try to control yourself and openly communicate, e.g. like this “It's hard currently, too many things going around. My TODO list is bursting. I need some time to go thru all of this, maybe I will not be as reachable as usual but bear with me, we'll get it done.”, to keep the panic from spreading.

• Keep a keen eye on the small changes in peoples behavior and communication, they will give you valuable pointers on what is happening in your teams. People will mostly not talk openly in a team meeting, if something dodgy is happening on the personal level in the team. But there will be some side looks, strange comments etc., that will give you valuable pointers for your next 1:1 sessions.

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.

Have any thoughts or comments?

My interests include #health, #parenting, #productivity, #leadership, #privacy, #selfhosting, #goodmusic with guitars, #fishing, #jogging ... and I hack on my #emacs configuration pretty regularly.

As a manager one of my tasks is to do yearly performance evaluations of the employees in my team.
I take this very seriously, as although I speak regularly with my people about tasks and behaviors, this yearly review gives me time to pause and reflect deeper about the stuff I (and the company) find important and how does the employee measure against that.
During the year I keep notes of all 1:1 meetings we have and also of stuff that happens between them that catch my eye, positive as well as possible improvement points. During the yearly review preparations, I sit down and go thru all the notes in order to consolidate the feedback I want to give to the employee.

In the company I work, we have multiple systems where I need to fill out parts of the performance review:

• There is a system where I need to document some high level work and behavior goals for the year. I can also do some basic commenting there, but the system feels like it's from 1985 😀.
• Then we have a system where employees can document their concrete contributions during the year. This really feels modern and limited in functionality 🤣.
• Additionally to that there are 2 different systems where we manage their monthly salary and performance bonuses. Don't ask me why 🤨.
• Then we have some special new contracts where everything is kind of free flying, as the software systems are not yet up and running 😁.

In order to be able to structure my thoughts as well as the feedback, I decided to create a custom template. This way I have one document that I can use to structure my preparation, guide the employee thru the feedback meeting and share with him/her afterwards. The document also includes the links to all the system above and provides more context to the information documented there.

Where did I create it? In #emacs #orgmode of course 😁. You can find the source here ... and … yes, I work in a German company.

Use it, adapt it and make your employees happy!

Have any thoughts or comments?

So it's about 30 months now since I took over building and leading an engineering team.
Building is the right word, as on the first day I started there was no team. There were just 2-3 engineers in India, that started doing some testing in the last sprint and had absolutely no clue what they are doing. (Somebody told them they are the test team and that the software to test is in Artifactory …)

Fast forward to now:

• I hired more then 10 people to work directly for me onsite.
• In India 2 teams of over 15 people do testing in different areas under my “command”.
• An offshore contractor in Egypt runs one full team of 6-8 people, that are, at least it theory, fully responsible for their sprint/release goals.

So I didn't build one team, I built a whole testing organization (incl. processes and infrastructure) and run it day-to-day.

Every day I learn something new about leading people and some of it isn't nice.
People have (emotional) baggage, people react differently to same words, people are not generally cooperative and tolerant … but it's my job to get them moving in the same direction.

In the beginning I thought the key is to be nice, keep people happy and give them a common goal. But … nice people get more work. Nice people get other peoples problems, complaints and rants dropped on them. Nice team leads keep the pressure away and do not blame, because they should be a “firewall”. Trust me … being nice will only bring you so far.

Over the course of my tenure I started to learn how to tune down my “nice guy” side and also choose carefully who gets to enjoy my “helper mentality”.
It's more about setting yourself realistic goals. Accept that there will always be someone in your team who will be unsatisfied OR not happy OR badly motivated OR downright acting stupid. It's impossible to make them satisfied AND happy AND motivated AND tolerant AND cooperative AND (you put here what is important to you). Even if people miss some of the things from the previous sentence, they can still be productive and do good work. Most of the times this is enough to get your job done and earn your paycheck.

Keep good care of yourself, nobody else will.

Have any thoughts or comments?

Biggest struggles

Something over 18 months ago a big change happened in my work life. After years of trying, learning, searching for ways forward, changing jobs on the same level … I was appointed team leader in my company and tasked with building up a team completely from scratch. I already wrote on the topic several times, this is a follow up.

It wasn't easy, that was to be expected, but some of the struggles I didn't anticipate:

• Hiring is hard work.
  Due to the fact that I had no team members when I started, I had to do a lot of hiring. Thru my career I was invited by my previous bosses to join interviews and give my feedback, but this was totally different. This time I could invite other people to interview with me, but at the end I had to make a decision to hire or not. This isn't always black and white.

• “Agile” is dead, it was killed by people who have no idea what it means.
  Every topic that got placed on my plate, every meeting I attended, every talk I had with employees/peers/boss … produced more questions, work and stress. Most of the topics were fuzzy to say the least, meetings were chaotic and drifted constantly off topic, there was no planing, no processes or structures defined. So what do we do? Let's call it “agile” and celebrate ourselves for trying this shinny new way of doing work.

• Everybody has expectations on you. I mean absolutely everybody … and mostly it comes all at the same time.
  Your future employee is complaining about HR being too slow, your peer complains about your not existing team not being there yet (“You started a week ago and still no people already hired?“) and your boss simply says “I want X until tomorrow and Y was due yesterday. Sorry, didn't I tell that already?”. Of course you should also have other things in life than work, but who cares ...

What did I learn?

Hire only when you are really sure, but accept that mistakes will happen.

Some candidates that were very good on the interviews, proved to be a challenge during on-boarding. Others where I was struggling with the decision should I hire them or not, proved to be true jewels that on-boarded fast and took the load of my back.
My takeaways:

• Look at the way the candidate is behaving during the interviews and listen to your gut feeling. If the candidate reacts “strange” on some questions or in the assessment situation, then he/she may be not the best fit.
• Look for motivation, commitment, fighting spirit … everything else can be learned.

I can't do multitasking.

I started pushing on multiple tasks, trying to define processes, building up structures, everything at the same time … But then I learned that I can not “save the world” alone and that it's not even expected of me. I have to limit my scope and choose my fights. There is always going to be a fire to fight, but I have to limit the fire fighting to one at a time … I can not do multitasking or help everybody at the same time, someone will always be unsatisfied no matter how much I try.

Not every expectation can be met, some of them are not even meant to be met.

It took me some time to see the pattern in this. My boss comes to a meeting with me and my peers. Then we start discussing different topics and at some point in time he states that something needs to get done, e.g. briefing needs to be prepared, workshop needs to get organized etc. All of us have topics we are responsible for, so you know when you are actually accountable to do something. But there is a lot of gray areas, like topics that fall in the cross-section of responsibilities or are even a new scope for all of us. Do not jump on these topics, your boss is just fishing … If you take it, most of the times you will invest effort and not get anything out of it. If you do not take it, mostly nothing happens … if he really needs you, your boss will tell you this in your 1:1 :).

Changed rules and workflow

My working day was a chaos:

• From 08:00 meetings start. I can not work on my backlog of tasks, because I am constantly being called to meetings.
• Meetings go the whole day. If they are not a waste of time, then they produce more tasks.
• During meetings I check my mails, I do not concentrate on the meetings and get even more tasks from the mails I read.
• At 18:00 the meetings end … so should my work day, but remember those tasks that didn't get done? You get the picture.

So after a lot of pain, I setup some ground rules and this made my life a lot easier:

• Put all the work and private tasks, notes, ideas, 1:1 … in one place to make searching and controlling easier. You guessed it, it's Org.
• Block time in calendar every day to tackle tasks. Refuse all meetings that come in this time, unless they are absolute priority.
  
  • If you accept a priority meeting, than cancel another meeting that day to get the time for tasks back.
• Read Emails once a day. If an Email needs more study, make a task out of it and remove from Inbox.
  
  • I am trying to get myself into a habit of writing Emails offline in Emacs, to prevent myself looking at the Inbox during drafting of Emails in the Webmail.
• Do a weekly review of your meetings and tasks for the next week:
  
  • Cancel all meetings that are just “be present” meetings or are parallel to more important meetings.
  • Only schedule tasks that have a deadline or have to be done regularly, e.g. preparation for 1:1.
  • Do not schedule tasks, that have no deadline. Put them on your Backlog and choose 5-6 tasks (depends on size) a week to be NEXT, e.g. on the top of the backlog.
• Build a split agenda view that supports focusing on a single day in the week. When the tasks of the day are done, finish working that day …
  
  • The sections in my agenda are mostly self-explanatory, day agenda are the scheduled tasks and NEXT are tackled after the scheduled tasks are done.
  • Refile is a special file, where all tasks and notes get captured. When I get time in the day, I refile accordingly.
  • I track deadlines that come in the next week, but I try not to pull them ahead. The WAIT are mostly waiting for responses to Emails or follow up from my employees.

Focus Agenda

I learn by my own mistakes

As I wrote at the beginning of this post, this change in my life didn't happen suddenly. I was preparing for this for a couple of years. But preparing and actually doing the work is not the same. All the preparation didn't stop me doing the mistakes almost every new team lead does, if you believe the books. But hey, I learned from my own mistakes.
There is still a lot to be learned and I am sure I will repeat some of the mistakes I already made, but hey that's life.

Have any thoughts or comments?

Had a strange discussion the other day in the project. We had a Release Meeting and my team was showing the current state of testing, defects and so on. During the presentation I intentionally said my Def-M, he should highlight in the Dashboard how long bugs are open in our product (we have a couple of them dragging on for more then 6 months). Of course this caught my managers eye.

In the discussion after the meeting we were talking how can we improve the situation. I was pushing for a time slot in the sprint planing for debugging and bug fixing, basically we have to see feature and bugs (at least) on the same level in order to have a good planing and tackle the bugs early in the development cycle.

Other idea was very strange to me. It was proposed, that we “open up a new bug fixing team”. In the beginning I thought we were talking about some sort of triage or debugging team, who would try to reproduce and create logs of the bugs. Then the feature teams, who have a bug in their code, can pick it up and find the exact root cause before fixing it. But no, the proposition was that this “Bug fixing team” also fixes bugs in other peoples code! So although this could be a good idea, when your product is already in the market and you have only limited resources to take care of the feedback, I think it's a majorly bad idea for a product in active development.

Why? Because people making the bugs should also fix them. With this special “Bug fixing team” you are basically saying to the developers: “Hey, just write code! Somebody else will pick up the slack, when it crashes and take care of your mess.”. Not really a good idea, if you want to have Built-In Quality in your product.

Have any thoughts or comments?

I am progressing!

Now it has been a bit over 12 weeks since I took up new responsibilities, so time to give you an update what went on since the last post on this topic.
What I can already reveal is that it became easier to master a day at work and also some stuff started to fall in place :)!

Make a 90 days plan and present it to your boss and peers

I got this from a book from Scott Cromar. In the beginning I thought: “Yeah, right. Make a plan, of course I have a plan!”. But there was one more sentence that got me thinking “Write your plan down and present it to your boss.”.
After pondering a bit about it I came to the conclusion, that the plan is in my head and not written down anywhere. Because it was not written down anywhere it kept on changing in my head. New stuff came in, my mind started rattling and sooner or later I started panicking inside: “Too much stuff, too much input … I will never make it!”.

So what did I do? I wrote the plan down! After I started writing what the tasks of my team are, which roles my Devs will have, how do I do the hiring and what the current state/plan of the hiring is … team strategy started to emerge. My thoughts got ordered and structured, which was just what I needed. Of course new information kept on coming in, but after re-checking with the written down strategy, I figured out that most of it was already covered somehow.

But I didn't stop at that, now that I had a plan, some low hanging fruit's started to emerge. So I kicked in and picked that fruit, e.g. got some test benches set up by a couple of Devs and then let them present it to my boss. After that I took the plan and showed it to my boss, also showing the first successes I got with the team. He liked that a lot and that got me some ground to stand on and also some confidence that I didn't built a completely dumb team strategy :)!

You have a plan, now focus on one day at a time

One additional thing that I have to learn to accept, is that my tasks list is always going to be full. So the work day is basically never over, unless I make it end! I know this all sounds familiar and it is nothing new, but I still had to recognize that I am not letting my work days to end. Meaning my head was always spinning …

My old Orgmode agenda was built so that I can see the scheduled tasks for the next 3-4 days and at the bottom every other task in the backlog, e.g. not scheduled or deadlined, was shown.
Although this worked for the last 1-1,5 years, now it started to make me nervous. From one side I started to work on the tasks for today and then if I saw a “quick” task scheduled for tomorrow and jumped on it and lost focus. On the other hand, the backlog just grew and grew. So every time I hit C-c a k (binding for my custom agenda) I faced an entire screen full of tasks. It is psychological with me, I can not stand to see something like this. It makes me itch.
So accepting that this task list is never going to be empty, I decided to build my custom agenda a little bit different. This new one just shows the tasks scheduled for today and gets the backlog there where it belongs, that is out of sight.

Agenda

With this new agenda my workflow changed a lot. I concentrate on doing the tasks scheduled for today! Tasks for tomorrow, will be done when the time comes. When I finished the scheduled tasks, I can then check the status and work on tasks that need more time (think of them like small projects).

I also changed the workflow so that I capture new tasks in the common inbox. When I have breaks in-between tasks and meetings, I refile the captured tasks in this way

• Needs to be done right now? Assign “Priority A”.
• Needs to be done on a specific day or until a date? Set “Schedule” or “Deadline” time.
• Everything else gets a “Priority B” or “Priority C” and estimated effort. Then it is pushed to backlog.

With this change after I have done my daily tasks and my projects do not need work on them, I can pick stuff from the top of my backlog, which is now sorted according to priority and effort.

Backlog

Conclusion

So it close to end of this year now and looking back at my first 3 months in the new job, I am confident that the next year will be good.
It's going to be a lot to deal with, but only these two things I've done in the last weeks, have given me the tools and focus I needed.
So stay tuned, let's see what is going to happen in the coming months.

Happy Hacking!!

Have any thoughts or comments?

Starting my transition

6 weeks ago I took over my first job in management as a team lead in a big OEM car manufacturing company.
I worked for the last 14 years in different positions in testing, development and project management within the same company and did some 2 more years before that as an external HiL and In-Car tester for a different OEM. So I think it's safe to say, that I was a techie and now I became a boss.
I decided to write a blog post about my first 6 weeks into the transition, because I hope this will help me reflect on my experiences and sort the stuff in my head … and there is a lot :).

The Good

I really like that this new department and the team are really diving into software development.
In my last 3 years I mostly did project management and led a Taskforce (the next stage, when a project fails to deliver), so I kind of drifted away from engineering and technology. I mostly solved organizational problems, tried to find ways to cut corners in the release processes and made sure we push the product out the door. So it feels great tackle some engineering problems again or, better said, help the team tackle them :)!

The team in the department is really multicultural and motivated to work together.
We have people from all around the world, so now the main language is English. Before that it was German. But I do not care that much, because I am proficient in both and none is my mother tongue. But what I find important is that different cultures, mindset and perspectives are coming together and a lot of lets-get-this-done mentality is present.
This is really refreshing. My previous taskforce project had a lot of “Silo”-thinking and as I stepped in, the teamwork was at it's low point with a “blame-game” at it's finest. It was clear that most of the people were trying to save their behinds, but this doesn't bring us any closer to a solution. So it's really nice to see, that these people as trying to get the project up and running and are open to accepting new people and integrating them.

The “In-Between”

When I was a project lead it took some time until the people in the project started trusting me and confiding in me, like whats the stuff behind the scenes and asking for help in sorting the problems. I had time to figure out, what is going on and how to give feedback to my project members. Not like that as team lead at all …
I already had to deal with other team leads who “spread their wings” and try to push bullshit assignments to me and my team, try to relieve a team member who is near to a burn out, get called by team member stating “this is not an escalation call” in her first sentence, performing 20 interviews and giving 18 negative reviews … No time to think really, just go with your gut feeling and hope you didn't break too much porcelain along the way.

Not sure how the team work will evolve under stress to come.
With the experience stated above I know pretty good where the project is supposed to be at this point in the timeline and make a good guess if we are going to hit the deadline. We are not going to hit the deadline, because the stuff is still not sorted enough and some crucial questions are still to be answered. So yes, sad to say we are heads-first on are way to becoming yet another Taskforce. This is not bad and to be expected, because it's the first time we are doing a project of this kind. But right now I can not judge do we have the right people on board to come out on the other end and how people are going to react to stress that it coming. Could get rough so get your vitamins and minerals in order.

The Bad

From my first day I felt like I have been put into a ejection seat!
It was like everybody (department lead, other team leads, devs, POs … you name it) had requests what me and my (still to be hired) team need to do ASAP and we are already behind the schedule.

So what did I do? I invested hours after hours, trying to figure out what is going on (organizational and technical stuff). I created an almost not ending Org-mode TODO list, did triage on my family obligations, stopped jogging, (almost) stopped thinking about everything else except my new job … this needs to stop and I need to find a balance because this is not a sprint but a marathon (the project has SOP in 2024).

Conclusion

I was not completely unprepared for what is currently going on, but now I think that there is no training that can prepare you for the magnitude of changes and tasks coming your way in the first weeks of the transition. As with people without children always having the “best” advice for the young parents, you need to be in the shoes yourself to know whats going on.
It kind of helped writing this stuff down. Stay tuned, maybe I'll give you a peek after the next 6 weeks.

Happy Hacking (of people of tasks) !!

Have any thoughts or comments?