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.

Parts of what follows grew out of several older posts I wrote on different topics that, at first glance, did not seem to belong together. Looking back, I realized they were circling around the same question from different angles. To prevent repetition I pulled them from the blog. I thought about deleting them, but decided to try and rewrite them. I played around with the local AI support in Brainiac and synthesized the bigger picture from those posts. As it seems, it came out pretty nice. It follows the ideas from the original posts, but is partly also very “intellectual” 🙂.

In education, in technology, at work, and even in private life, systems tend to drift away from what builds long-term capability, resilience, and alignment. Instead, they optimize for what is easier to reward, easier to explain, or simply more attractive in the short term.

This rarely happens because someone planned it that way. It usually happens because incentives, habits, convenience, and social expectations quietly pull in that direction. Locally, the choices make sense. From a distance, they often look less convincing.

A while ago, I attended an information evening at my son’s school. Students could choose additional subjects based on their interests and possible future aspirations. The options included languages, natural sciences, engineering, and computer science.

What struck me was not the quality of the presentations, but where the attention went. The strongest interest seemed to go toward what felt culturally attractive, familiar, and easy to imagine, e.g. “If I learn Spanish, I'll be able to get better information from the locals when I travel around in South America.”. The more technical subjects, which demand more effort but also build deeper capabilities, generated less excitement.

This is not meant as criticism of individual choices. People react to the incentives and narratives around them. But it reminded me of something that shows up elsewhere too: systems often reward what looks good on the surface while undervaluing what is slower, harder, and more foundational. In engineering, this would be obvious. If you keep optimizing the visible layer and neglect the structure underneath, sooner or later the system suffers.

Typical example I noticed very often is that you celebrate a team if they are able to produce a fix for a found bug quick. Which is of course commendable, but it's the same people who made the mistake in the first place. On the other hand teams that dealt with their bugs quietly and did their job properly, usually do not get the same level of visibility or appreciation for that matter.

A similar thing happens inside us.

For a long time, I thought of happiness as some kind of ideal state — a place where work feels right, private life is balanced, and the overall direction makes sense. The problem with that idea is not that it is wrong, but that it can become a distorted benchmark. Normal life starts to feel insufficient.

Over time, I became more interested in a different word: contentment.

Not as resignation, and not as lowering standards. More as a kind of inner stability. The ability to live with an internal critic without letting it dominate everything. The ability to accept that meaningful work, relationships, and responsibilities usually happen under imperfect conditions.

That feels closer to reality, especially in engineering and leadership. Projects do not become easier because uncertainty disappears. Teams do not grow because everything is smooth all the time. Most of the time, progress comes from staying oriented, noticing smaller moments of alignment, and continuing without demanding perfection from every phase.

The same pattern becomes visible when looking at technology on a larger scale.

In Europe, there is a lot of discussion about digital sovereignty, and rightly so. In many areas, the technical tools needed for more independent and privacy-conscious digital infrastructure already exist. Open-source solutions are mature enough for many use cases in education and public administration.

And yet, dependencies remain strong. Children learn “computer literacy” inside ecosystems that lock them in early. Public institutions rely on structures that are convenient in the short term but make long-term independence harder. Industry often seeks speed through partnerships while slowly giving away capability.

The interesting question is not whether cooperation is good. Of course it is. The more interesting question is what a system is optimizing for when it repeatedly chooses dependency over capability, convenience over resilience, or speed over long-term autonomy.

From an engineering perspective, this is not surprising. If resilience is not made an explicit goal, most systems will optimize for short-term constraints.

A few years ago, after my family suffered a significant personal loss, the same pattern appeared much closer to home.

I started asking myself uncomfortable questions. How much time is left? Am I happy with my life? What am I actually trying to achieve? And whose goals am I pursuing?

I did not find neat answers to all of these questions. But one thought became much clearer than the others:

I want to live a long life and enjoy that time with the people I love.

Put next to many of the goals I had accumulated over the years — earning more, staying ahead of every new technology, optimizing myself endlessly, becoming more efficient, consuming more experiences — some of them started to look suspiciously external.

Not wrong, necessarily. But not fully mine either.

That was uncomfortable to admit. A lot of what I had accepted as “normal goals” had quietly been shaped by a system built around productivity, optimization, comparison, and consumption. Only when that frame was interrupted did I begin to ask whether the system I was living inside was actually aligned with what I valued.

Across these examples, the topics are different. Education. Emotional life. Digital infrastructure. Personal priorities.

But the pattern feels similar.

Systems optimize for what is visible, rewarded, and immediately legible. They do not automatically optimize for what is sustainable, meaningful, or capability-building over time. Unless those things are named explicitly and chosen repeatedly, they tend to get crowded out by easier metrics and more attractive narratives.

This is true for institutions, organizations, teams, and individuals.

• A team can optimize for activity instead of progress.
  
• A company can optimize for reporting instead of learning.
  
• A person can optimize for image instead of alignment.
  
• A society can optimize for convenience instead of resilience.

None of this happens because people are stupid or malicious. Usually it happens because systems are powerful, time is limited, and immediate rewards are persuasive.

That is why I find it useful, from time to time, to step back and ask a simple question:

What is this system optimizing for?

And then maybe the harder one:

Is that still what I want to optimize for myself?

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.