Recently, I read a post from Edward O'Brien where he was writing about his personality profile, and how it has influenced his career. I commented on his post, but want to expand here a little bit more on my own experiences.

The “Colors” theory is not a gang sort of thing, but a great way to get a concrete description of your personality, understand how your behavior effects others and improve your communication and cooperation skills. Of course there are also other assessments, and they all have their strengths and weaknesses, but this is the one that, at least for me, was easy to understand and also to explain to others. I got a recommendation to do it about 12 years ago, after a not-so-positive leadership review I received. That feedback, and this assessment, sent me down a long reflection road that at the end led to biggest breakthroughs in my personal development.

Where is your team?

As a young professional, I joined Mercedes-Benz AG in 2009, and was tasked with building up test management and preparing a test strategy for a car system that would have to comply with ISO 26262 when it becomes a certification precondition. I tackled the task very intensively, as I had already two years of test engineer experience and was eager to reach the next step in my career. After about two years of hard work, I had an internally assessed test strategy that was aligned with ISO 26262, and a working test management on the system level. This success brought me a good performance review from my management, and as it usually goes, I got tasked with something even harder, although I didn't recognize this at the time. The next task was to extend the test strategy to also include component-level analysis and then align it with all the component responsible and their suppliers. In order to give me the attention I needed, I actually got a slot in the management meeting every second Friday, where I could present my progress. So everything was setup, to deliver great results and get, the ever so needed, visibility for my work.

I did then what I always did. I dug into the topic, worked out a very good technical solution, and invited component-responsible people for regular connects to present them the solution and then push them until completion. I presented, pushed, explained, escalated in those management syncs when there was no progress... and after a year or so of fighting, we reached our first successful SOP. Now I was really looking forward to my next performance review. And the review started very well, as I was commended for reaching the goals and given a good raise. But then I asked about my leadership performance ... and got a feedback that was very short and to the point: “You have reached the goals, but at the finishing line, you were the only one there. Where is your team?”

At first, I didn't understand the feedback because results had been delivered; therefore, I had proven my worth, right? The team performed and delivered, so what's the problem then? The issue was that the project team would not do me. They had delivered but reported to their line management that they felt uninvolved, pressured, and burned. This hit me hard, as I actually thought that everything I did took them with me. But it seems, it came out the wrong way, and I was stunned by what went wrong.

Paper Mind Model, an addition to the Colors

It was clear that I needed to take people with me, and as I wrote, I was convinced that I was sending out that message all the time in our meetings. But why did the receivers get something completely different? And on which level did I not engage with the people who had different levels of technical expertise?

Finding out through the assessment that I am mostly Red and Blue offered an explanation for why I lost colleagues with Yellow and Green shades. The fact that my German was colored with a strong Eastern European accent seemed to be enough to push others away, as I was perceived as someone very strict and military-like.

But still there was the problem of engaging people on the right technical and abstraction level, in order to help them understand the goals and thus enable their active contribution without feeling overruled or uninvolved. I figured out that my pace was too fast. For some time I thought I lost people because they were not technically skilled enough. But that wasn't the reason. We all need different levels of abstraction to grasp ideas, and have different processing speeds to understand them. Having a higher processing speed doesn't mean you will deliver better results; it only means you can deliver first results faster, which says little about the quality of those same results. In my experience, processing speed can get higher as we gather technical and life experience, but this change is not so drastic. So I stopped making an assumption that if I am in a room with people who have a lot of technical experience, then very high levels of abstraction are sufficient. And vice versa, that juniors need detailed instruction lists to deliver results. Instead, I developed a mind model for myself that I like to call 'Paper Mind Model'.

In this mind model, I imagine a sheet of empty paper and ask myself how many lines of text on that sheet will the person in front of me need to understand what I am talking about and get involved in the idea, task, project etc.

Following are three levels that I have seen in real life:

• A headline is enough.

  • This is a type of person where writing just one headline or title on paper is sufficient to get them started. As an example, for me, the headline “We need a Test Strategy that is aligned with ISO 26262” was enough to get me going.
  • The benefit of this type of people is that they can generate concepts, solutions, and ideas almost out of thin air. However, there is a risk that they might miss the target because you can misinterpret a lot from just one headline or title.
  • As a leader, it's important to invest time in refining their ideas with them. They will need boundaries, but these can be provided later; let them generate freely first.

• Explain me your idea.

  • This is the most common type of people. It takes about half a page of text for them to get started and dig into the details.
  • The benefit here is that they help define the task better by either asking questions or being hesitant with the idea, which forces you to think harder and explain your purpose more clearly.
  • These individuals are valuable assets in the team as they often do not generate new ideas independently but can make your team work more efficiently by providing steady flow of improvements.

• I need clear instructions.

  • For this type of people, it's essential to invest time breaking down the idea or task into sub-items and explain what needs to get done in a level of detail that might sometimes be tiring for fast-paced people among us. It could require a full page of text or more, but if done properly, it is good investment.
  • Some people argue that these types need to be more independent and build more experience, because we need more of the other two types mentioned earlier. However, I disagree. Some of them, mostly fresh graduates, will move upwards in abstraction level over time, but some remain at this level for a long period. This is good as they can deliver a foundation for bigger projects and work with you through daily grind when high potentials are already moving on.

Noteworthy is also a category of people who need no text or headlines to produce results. These individuals listen carefully what's happening around them, what was discussed in meetings, and then start generating improvements and ideas without being explicitly triggered. I do this sort of brain-dumping often and like to call it 'fishing'. Sometimes I catch a fish, and sometimes the idea is just not worth it.

Conclusion

So that's it; the combination of Color Theory and Paper Mind Model helped me a lot in reaching people and leading them to success. As with the colors, you need a good mixture of these types in a successful team. And as a leader, you have to figure out who is who in your team in order to lead them efficiently. But when strong colors get mixed with demanding paper types, this is where leadership gets very interesting.

Reflection is the key ingredient for self-growth, this is a known fact. However, I figured out I need to be careful and consider several factors.

There are different types of reflection. I noticed, until now, these two types:

1. The type that stimulates self-growth.
2. The self-destructive type.

My mind jumps often from one type to another. Often I catch myself in the self-destructive type, as I have a very strong achiever mentality and a very loud, perfection focused inner critic. It is sometimes a challenge, to calm down my spiraling mind, but I am getting better at it. This needs constant practice.

However, I also have to take care of not investing too much time in reflection, as this is actually using the present to think about the past, which can diminish the time I invest in planing and steering my future.

Because “... each tiny “I don't care” iteration to tech products is a small step closer to Star Trek's promised land of holodecks, abundance, and hot aliens ...“, and I want that future!

Note to leaders.

Have a look at what your team is working on, are you producing real future proof value for the company or just chasing another tech trend trying to show that you are „on the bleeding edge“?

Producing real value doesn’t just help your company keep the business in long term, it gives your team purpose and enables them to optimize their contribution.

A couple of days ago I was going to the office. It was Friday, I had some meetings scheduled and some light office tasks to do. All in all, it should be an easy day as it was the first working week of the year.

As I was walking from the car park to the office, I noticed a guy walking in front of me. He was strolling along, with a coffee in his hand and looking kind of dreamy. Unintentionally I set off to overtake him and hurry along my way. Then it hit me: “Why am I in a hurry?”. As I wrote above, there is no urgent meeting that I needed to attend or a task I had to do. Where did this urge to overtake him and look busy come from?

The modern life being promoted around us, teaches us not to loose time and to always be busy. If we are not, then we will not be successful, reach our goals or we will simply be brand-marked as slackers.

But this time I intentionally chose to stop my overtaking and match the speed of a dreamy looking guy. Our lives are marathons, not sprints. Preserve your energy for the moments where you really need them.

This year the company did their bi-annual Employee Survey powered by Gallup. As we did this 2 years ago, my team's results were among the lowest ranking. But this time the 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 comparable teams. So what led to this improvement?

I took the low results very seriously. In the first workshop I had with the team they stated that most of the ratings are low due to volatile project goals, instabilities in the software we are testing, too short timelines, etc. So a lot of stuff you could put in the drawer „That’s life, not under my control.“ and forget about it. But I didn’t. I invested a lot of time in 1:1 talks, smaller workshops and did a lot of incremental changes to the processes, meeting culture, external marketing of the team’s successes.

As the new results came in and we improved across the board, I was very proud and happy about it. I couldn’t stop talking about it for weeks 🤣. I think at some point everyone was getting bored by me, but I didn’t care 😬.

After reflecting on the new results and talking to my team, I think the reasons boil down to these two important cultural pillars:

• Take responsibility and give your team focus by making decisions when they need it. 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. 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“.

• 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 off 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 employee has a sick child, wife has family issues etc. Treat your team with respect and speak to them openly about the good things and the improvement points. Integrity is the magic word.

Looking back over four years

This post closes a series of reflections written at different points during my first tenure as a team lead — after roughly six weeks, 12 weeks, 18 months, 30 months, and now 48 months. Each text captures a moment in time, written without knowing what would come next.

I’m intentionally leaving the earlier posts unchanged. Not because they are complete, but because they reflect the questions, uncertainties, and partial clarity that tend to accompany leadership in real life. Read together, they don’t form a guide — they form a trajectory.

If you’re new to leadership or approaching it for the first time, consider this series less as advice and more as field notes from different distances to the same starting point.

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.

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!

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.

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.

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.

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 to the Defect Manager, that she 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 create 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 field 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! When it crashes, somebody else will pick up the slack and take care of your mess.”. Not really a good idea, if you want to have Built-In Quality in your product.