One Year (and a few months) of Leadership

On last year’s November 1st, I earned a very special achievement: 1 full year in a leadership position leading a group of 3 smart & experienced QA Engineers. This is quite a biggie of a milestone for my professional and personal career and I’m incredibly thankful for my team and my boss for putting so much trust in me. It is still early 2021, thus it is time to use the cold wintery days to reflect on what I have learned and why I chose this career path in the first place.

Why did I pick up the leadership path?

I’m a natural supporter; the more I can help others to be successful, the happier I am. But as an individual contributor, you are responsible for your own stuff. You have to do your tasks and focus on your work. Of course doing your own tasks helps your team mates, your lead and the company in general, but that’s an indirect effect. If you want to help people directly to succeed, you need to shift your daily work’s focus towards that. This grants you time and space to listen to your peer’s needs, to abstract away the company politics and to make sure that your peers can work in a clean and focused environment. Applying these principles, I noticed strong growth in collaboration and an increase in speaking-up on a high technical QA level.

This is where I want to draw my own professional satisfaction from.

Now thing with people is that they want to get recognized for their own personal achievements. I’m no different here, hence changing my priorities was a tough lesson to learn. But that’s OK. It’s part of the challenge, and in the long run it is the right way for me.

What is leadership NOT about?

Hot take: Picking up a leadership role is not a promotion, but a completely different career path. Even if you lead the same way as I do doing day-to-day tasks after management, you have too many tasks that are different from your handson-stuffs to do, and thus require a different skill set. Let me give you a personal example.

My job then…

For me as a testing professional, the IT business world is red or green. Something is implemented according to the specs or it is not. A test is either green or red (i.e. not yellow). Either the test or the app failed. You get the image. Much more important: Things can be proven right or wrong. We have specs, acceptance criteria and various different models for that.

… vs. now

This is history. Now I take on decisions, with their outcome being at least most of the time uncertain in the short term. It can take weeks or even months until I know, if my decision was correct. And if so: to what degree? Even correct decisions are not a 1 on the logical output wire. Rather, the truth lies somewhere in between; an aspect you have to constantly deal with. That’s OK, but it’s a significant difference we must be aware of. The next point is that it comes with a change in your skillset: You must stay confident in times of uncertainty.

Consequently, you cannot tell other people that your decision X is correct. You have to point out advantages, tradeoffs and set the decision into context to actually convince people that your decision is the best for the job at hand. Sure, as individual contributors we have freedom within a certain frame depending on our respective leads, but your audience will be different and it is certainly going to be larger. Therefore, we have again a shift in our skillset.

These are my 2 most prominent examples on the take why I think that being an IC and being a lead are two completely different jobs. What do you think about it? Agree or disagree? Let me know in the comments below.

How do I want to lead?

They say „Sometimes a picture says more than 1000 words“, and when you type „leader vs boss“ into Google, you eventually stumble upon this masterpiece of a motivational sort-of-a-meme-thingy:

Peers pulling the boss and the business forward vs. the leader that pulls the business together with his peers, the latter being my leadership style orientation.
Boss vs. Leader. Shoutouts to whoever made this gem.
If you know the artist, please drop a link the comments. 🙂

The bottom part sums up my aspired style of leadership so well that I had to post it here.
To implement the depicted style, I apply six key principles:

Write up a lean agile process

I try keeping our testing process as lean and clutter-free as possible by forming few key principles and write them down in our project – Confluence as a manifesto. These principles have to be lived by day by day, but nothing more and nothing less.

Write it up together with your peers

The key principles of our testing process are living documents that are formed by the team (including myself). We discuss things we want to do regularly and reliably together, put them into Confluence, observe them and adapt them if necessary. This also forces us to keep the principles few and short to prevent us from overengineering the process. A valuable feedback loop.

Give your peers as much freedom as possible

Once the key principles are in place, I give the team as much freedom in their day to day work as possible. Basically, I set priorities to the tasks and recommend (!) assignments. Anything else is up to the team. The task assignments can change freely between the team members, as the team sees fit.

Trust, trust & again trust

Trust is the mortar of a working human relationship, and organizational relationships are no exception. As such, they require mutual trust like any other relationship. Trust is an important part of respect we owe the peers we hired to get the job done. If you don’t trust them, they will notice, and they – justified – won’t be happy about that. So please make sure that you pay your peers as much trust as possible. You as a lead want to be trusted, too, right?

As a great side effect, trusting your peers will give the whole team a huge amount of freedom. That means lots of freedom for you, too! Valuable free time to focus on all the outside requests that drop into your mail box every day.

Be part of your team

By now, I talked a lot about the team members. When I do that, I include myself. I am a part of my team. I work at their side and implement a „we“-perspective into our day-to-day work. This keeps up the motivation and changes the way people inside and outside your team will see your team’s efforts.

Work together

Setting up the process chores once and only doing minor modifications from time to time, you should have some time left. I use this time to grab tasks. I am careful what to pick though, because I did a huge mistake in the past: By misunderstanding the block-removing part of the leadership job, I tended to pick the biggest and nastiest fundamental tasks available. As a result, it took me aaaages to finish them, because I just don’t have fulltime hours to work on them. I have meetings, have to answer questions, mails etc. That’s the major part of the job now. To fix that, I decided to give these tasks to the team, trust them and only do support on demand. In the meantime, I pick simple non-blocking tasks, e.g. automating single not-too-critical tests. Even these simple tasks increase your team’s free time and are highly appreciated inside and outside.


So long, these were my learnings of one full year of the adventure that is called leadership. And what an adventure it is. I absolutely recommend it to you in any case: Try it out, get a grip on leadership and experience firsthand, how much you grow as a person and as a professional. If you like it, that’s awesome. If not, thats Ok, too. Feel invited to read up here about why it is a good thing to be in technical QA nowadays instead. You should definitely give it a try.

Also, if you are especially curious about how my first entrepreneurial challenge turned out, check out my most recent blog post, where I write about my experience publishing an app to the Google Playstore. Stay curious, everybody!

Home » Testmanagement
Share it with:

A Quick PSA about My Testing Life

Hey testing world, this is a short update about what’s going on in Floh’s testing life. You might have noticed that it was quite silent in here for a few weeks. This is because I had to learn. A lot. But thankfully it paid off: I passed the exam for the ISTQB© Certified Tester Advanced Level – Test Manager.

Actually I wanted to wait for the Acclaim Badge to be issued, but it seems it takes a while. Therefore, here’s the announcement. Once I get the badge, you can find it on my business profiles page.

What did i get out of it?

Ok, enough about myself. The much more important question is: What will I bring back to the company? Within the lessons, I identified two big points to improve on:

Measure a lot more

Before the learning kicked in, my measurement revolved mainly around basic requirements coverage to see, when we are „done“. Since back then I always had the feeling, that it’s not enough. There is much much more to our apps, the quality and the project team than the mere requirements coverage or the backlog burndown charts. Now I am sure that I urgently have to improve on my measures and thus transparency.

Getting involved in risk analysis

I joined the party project quite late, and therefore missed out a lot of the fun that happened at the beginning. Furthermore, since risk management is supposed to be done continuously, I’d like to perform internal risk analysis sessions with my project team. Here I want to give the team a platform, where we can address possible problems in a structured way. The result will be an insight-rich document, that we testers can feed upon in order to see, in which direction we should proceed. E.g. should we go more in-depth for bullet point A, or is there a point B, that is not handled at all?


Although I’m happy about having passed the exam, I am super thankful for the lessons learned, too. I discovered important improvement points, gained a big load of new knowledge and valuable insights. This means a lot to me and I’m sure, that it will help me becoming a better professional in the short and in the long run.

Home » Testmanagement
Share it with: