6 leadership mistakes that made me a better leader

As a community, we know that we have resources available to teach you skills and approaches. But nothing can really teach you how to be a tester or manager at a unique organisation, working with unique people. 

Each organisation is different with respect to management hierarchy, culture, teams, budgets, processes, and so forth. Training will get you only so far. You must experience it to learn what works and what doesn’t.

Over 20 years ago, I was thrilled when I was promoted to my first-ever management position on a software development team. I didn’t consider myself to be a great developer, but I was good at relating to people and coordinating tasks. I took a bespoke management training course based on Stephen Covey’s The 7 Habits of Highly Effective People, and I learnt a great deal.

Since then, I’ve had several different management roles across a few organisations, learning from each mistake I made to become a better leader. Some mistakes were big enough to make me not want to be a leader anymore, and some were far more subtle. I was learning about the kind of leader I wanted to be, how to change my approach, and the kind of person I wanted to be. Through that process I learnt to move on when an organisation no longer supported continuous improvement.

Below I share my biggest mistakes in leadership and the knowledge I gained along the way. It was painful at the time to experience the failure, but it is also liberating to look back on the journey and how it taught me to be a better leader.

My mistakes and how I learnt from them

Mistake 1: Defending the team instead of supporting them

I once was a manager in an organisation where conflict was actively encouraged. In one team briefing, the CEO explained to us all that “there has to be conflict.” To enable this questionable strategy, the leaders' seating area was physically separated from the seating areas for the teams. And we would often hear loud arguments coming from the area where the leaders sat. 

I figured I would try to fit in as best I could. So, I often put myself in the position of defending any perceived attacks on my team about things like last-minute requests, reassigning people to different projects on a whim, input of poor quality, work outside our remit, and so forth. 

In the short term, I got a lot of support from the team. They saw me as their defender and so they were right behind me. However, there were a few negative effects:

• The team felt that every decision had to go through me
• The team didn’t feel responsible for their own decisions or initiative
• The relationship between teams deteriorated
• I felt that I was completely responsible for everything that went well and everything that went badly. Unsurprisingly, this fed a decline in my mental health from always being under pressure

Lesson learnt: There is a big difference between proactively supporting your team and reactively defending your team. If you support your team, you help them make decisions, collaborate with others, and take responsibility. You are seen as a source of support inside and outside the team, and you are helping people grow. And you will have to defend your team far less frequently than I did. 

Mistake 2: Focusing on impressing my manager

It’s a natural instinct, right? You get promoted and you want to impress the person who promoted you. So, once my management career started, I set out with the ambition to prove to my boss that they made the right decision.

For a couple of years, everything went well. Then came a little organisational turmoil, and suddenly I had a new boss. This person had a good reputation for facilitating organisational transformation, so I was looking forward to working with them. 

It turned out that they were unpredictable. They would say what they needed from you, and I’d work on it and give them my results. Then, they either were no longer interested or they would suddenly come up with a new perspective, sending me back to the drawing board. They were brilliant at finding flaws in my logic and often found those flaws late in the game, so I’d feel bad. But they always gave a good end-of-year appraisal despite my believing I hadn’t done well.

Slowly I was losing my identity as a leader. It was all about pleasing my boss and catering to their whims, and I was becoming less confident and effective. So, I felt it was time to get out and take a break from leadership. Perhaps leadership didn’t suit me after all, I thought.

Lesson learnt: You need to be clear on the kind of leader you want to be. One useful exercise is to imagine yourself on your last day in the organisation. In the exercise, imagine how your boss, a colleague on your team, and a colleague on another team might describe you as a leader. What would you want them to say? The answers you imagine reflect the kind of leader you want to be to your teams and your peers. If your identity as a leader is compromised in your organisation, then maybe it's not the right environment for you to grow.

Mistake 3: Making up my own key performance indicators (KPIs)

I was told in my early days as a leader that “If you can’t measure it, you can’t manage it.” I found out only recently that the quote had lost something in translation by the time it got to me (or maybe I misheard it)! The original quote was, “It is wrong to suppose that if you can't measure it, you can't manage it.” I must admit it's a little annoying to find out that I’ve been banging out a misquote for years!

In one of my management jobs, all of us managers were put into a room to come up with our own metrics. And then we were supposed to live by those metrics as a team. Curiously, the engineers were not involved at all in creating the metrics. And so they didn’t buy into or feel accountable to what we managers had come up with. However, for my part, I bought into the principle that objective measures are important to drive forward improvements.

In my most recent management role, I suggested that we needed some KPIs and offered to make that happen. But I didn't want to repeat what had happened at my earlier job, where engineers were not involved in creating KPIs. So I put some KPIs together and presented them to the engineering team to get some initial feedback. I got no feedback whatsoever. Even so, I started monitoring them and modifying them over time. I was happy with them because they provided a lot of useful insight. However, they become known as “Gary’s stats”. The engineers still didn’t buy into or feel accountable to them. They saw them as something I did on my own.

Lesson learnt: If you want to create and use metrics, build them with the team. Work with the team to find out what potential successes were missed, what failures could have been avoided, and where they feel there is a need to improve. What do THEY feel is important to their individual and team's success?  And, just as important: review the metrics with the team on a regular basis. Add, change, or remove metrics as necessary based on those reviews. This ensures that the metrics remain relevant. If your metrics don’t matter to the team, they don’t matter, full stop.

Mistake 4: believing you can help everyone

I’ve managed around 100 people over the years. I always felt I had a good moral compass when it came to looking after people and that everyone could see I wanted the best for them. Most of the people I managed were a pleasure to work with and I feel we had beneficial relationships. 

However, a handful of people were very difficult to connect with. I always thought I could change their perception, though. I remember one engineer I used to manage. I had received great feedback about them from a project manager, and was looking forward to sitting with them. The engineer had been working on one product their whole time in the company and had a unique way of working. 

I knew my first task was to get them to work with the rest of the team so I could widen their perspective in testing. But they were obstructing the team, trying to get them to work THEIR way. I invested so much time in trying to help them integrate that it was distracting me from managing the rest of the team. Other managers suggested that I put the person on a performance improvement plan. I still felt it was my job to help them because I was convinced I could turn them around. However, the more I tried, the more obstructive and aggressive they became.

In the end the stress of focusing so much time and energy on one person was one of the reasons I left the company. I was burnt out. I’d lost my confidence again, so I felt I simply needed to restart my career somewhere else.

Lesson learnt: As a leader, you must accept you can’t help everyone. Get advice from your leaders and HR teams on the best way to protect your culture if you feel you have exhausted your mentoring options. If you must go down an exit strategy with a report, remember that organisational culture is bigger than you or your individual team. Don't shy away from doing the seemingly “difficult“ thing.

The team as a collective and its culture are the most important ingredients to successful leadership. The mission is to evolve that culture, so you have an interdependent autonomous team whose members enjoy working and learning together. Fortunately, those who don't buy into the culture, or could damage it, are relatively rare.  

Mistake 5: Recruiting people based on skills first

In all my years of leadership, I was never taught how to recruit people. As a result, my decisions were often led by recruitment agents, candidate testing tools, and other managers. Over time, I could see that I was making the same mistakes year on year, and I didn't feel good about that.

As I mentioned earlier, the culture of the team is vital to its success. But recruitment processes seemed to focus on technical skills, not the ability to work on a team. I had to write job specs based on technical skills, and of course I’d get CVs in response that showed the candidates had those precise skills. And then recruitment agents would question candidates only about their tech skills. For lack of a better process, I went with it.

In a couple of cases, I had to fill positions where the skills needed were niche and candidates were in short supply. Pressure soon built to get someone in place fast. And so I hired people who had those skills. Don’t get me wrong, I thought those I eventually hired would fit. 

Sometimes I got lucky, but most of the time they were expensive mistakes. The candidates I hired had the skills, but couldn’t adapt their way of working, couldn’t gel with the team, and usually left the organisation in short order.

Lesson learnt: Since then, I have focused interviews on learning about the people behind the CVs. I need to see something about the person in the CV, asking them about their opinions, achievements, and perspectives. A long list of skills and past job duties tells me nothing about you. I want the CV to indicate to me that talking to you about quality is going to be interesting.

My interview process now looks like this:

• The first interview is a simple chat about testing and quality challenges. This lets me know how enthusiastic they are and how they like to work. And I introduce them to our culture. At the first interview, I do not ask a single question about skills. If you are applying for a quality engineer role, I should respect you as a professional to know that. 
• If I feel enthusiasm from the candidate and am excited to see what they can do, then I give them a fun open testing exercise that I leave with them to do on your own time. No right or wrong answers. 
• And after I get their response to the exercise and it looks promising, I invite the candidate back so they can talk through their approach. And then they meet the rest of the team.  

Mistake 6: Change organisations solely on the suggestion of old friends

When you’re not enjoying your current job and feel unappreciated, you can become vulnerable to making uninformed decisions. 

A while back, a former work colleague of mine approached me about a test management role. I wasn’t happy where I was: quality issues weren’t being prioritised, and I was tired of being the only person of authority trying to do something about it. So, to have a former colleague whom I respected approach me was very flattering and uplifting to me. Even better, another work colleague of mine was at the same organisation in support leadership. So it was looking like a good team to collaborate with. They were great friends outside of work, too.

I took the role. Obviously, you start off on a honeymoon period: meeting the team, understanding people, finding out what is working and what isn’t. 

The organisation had two overriding quality problems: 

1. There wasn’t a clear strategy on what software to buy, develop in house or contract out. So their tech stack was all over the place. The testers were testing products that were and weren’t under our change control.
2. Their main system was an “inexpensive“ CRM. Unfortunately, the costs of testing and fixing the problems caused by the CRM negated any savings the initial price had promised.

My goal was to influence changes with regard to both of those issues. The first seemed to require a longer-term strategy that I could influence but not drive on my own. So I focused on the CRM system.

After successfully raising the visibility of both these issues, we agreed to get a replacement CRM system. We chose a supplier, and we started to plan a migration project. The first question was from our senior manager: “Who wants to be involved in the project?“ Strange question, I thought. But one by one, each leader stepped back until it came to me and the dev lead. We looked at each other and said, “it's our job, isn’t it?” Upper management recruited an entire contract team to take on the project, leaving me and the dev lead to work with them.

I realised that the source of all the quality problems was a culture of complacency. And the former colleagues who had recruited me were complicit in it. The moment responsibility was required, they stepped back. I was so disappointed.

Fortunately, I had a good enough relationship with those colleagues to be able to speak to them privately of my disappointment and remind them of how much I respected them.

Lesson learnt: As a leader, before you take any new position, do your due diligence on the organisation. Don’t take the soundness of the position or the organisation solely on the word of former colleagues, and don’t let the prospect of working with them or your current situation cloud your judgement. Understand why they need the role, the quality problems they see, and how the culture works in times of success and stress. Understand the engineering strategy, their products, when they outsource and when they don’t.

To wrap up

Lessons I learnt:

• Support your team's growth as professionals and as people proactively so that you won't have to defend them reactively
• Be clear on the principles underlying the kind of leader you want to be and play that role
• Don’t impose metrics on teams. Instead, understand what success and failure look like to them
• Protect your culture. When one of your reports is damaging it and mentoring fails, you may need to make tough decisions to protect the culture
• Give recruitment candidates an enjoyable interview experience. Recruit for your culture and diverse team dynamics first, skills second
• Be a leader when it comes to decisions about your career. Never be led by your emotions or your current situation

For more information

• From tester to decision-maker: Carving your path in quality leadership, Alessandra Moreira
• The Quality Coach: Testing & Quality Leadership In Today's World, Stu Day
• Adaptive or authentic leadership?, Jeanine Mechelinck