The Leap to Leadership: An honest experience from an anxious SDET

Hello again! A lot has happened since my last blog post, both in my personal life and my work life at Dunelm. I’ve become twice as tired following the birth of my second child and twice as busy at work after taking on a maternity cover position as a Quality Engineering Manager. I’ve been in the role for nearly 9 months now and gained so much experience and faced so many new challenges. By sharing these experiences, I hope to give an honest account of going into management to help people at this ‘career crossroad’.

It feels like most people in technology roles eventually face a decision if they want to move up in their career: do they double down on technical work through specialisation or do they pivot into a management role? It’s no secret that the latter means building up an entirely new skillset, which is really daunting, but it was part of the reason why I decided to give it a go. In my experience, you only really grow when you place yourself outside your comfort zone; giving up coding to focus on people is exactly that for me and I thought it would be a fantastic way of getting professionally uncomfortable (in a good way!) quickly. I also had the ‘safety net’ of knowing the person I would be covering for would come back, so it made that decision a little bit easier!

One of the first things that struck me as I moved into the role was just how much freedom you have to organise your own time. This, of course, is a double-edged sword as you have to carefully plan ahead so you don’t overwhelm yourself. I was used to following a strict, Agile ceremony-filled week with set points and meetings, so the fact I had a clear diary to fill with 1–2–1 meetings was really daunting. Naturally, I initially messed it up by booking too much in at once and giving myself no time to breathe between calls. It’s so important to make sure you get at least 5 minutes between meetings to get up and stretch your legs, otherwise the day feels like one long meeting. Due to the amount of people I manage, all of whom work in different parts of the tech arm of the business, it also became apparent very quickly that I could no longer get involved in the day-to-day technical issues as much. Going into the role I was quite na?ve, I thought that there would be enough time to manage everyone and help out with an automation test here and there. Not having the time to muck in with technical outcomes has probably been the most difficult part of the job for me, as it’s quite frustrating knowing you could help if you had more time, but with so many line reports it’s just impossible.

One of the many benefits of working for Dunelm is that you are trusted with a lot of freedom to be able to take ownership of how you do your role. The counterpart to the people management in the manager role is chapter development. As almost all of my reports work on different teams and generally QA are alone or in smaller numbers on their squads, I founded the ‘Quality Clinic’ — a weekly meeting where people in the chapter can come and discuss their technical or ‘ways of working’ issues. So far this has largely been productive and has become something I wish to build on in the future. As a manager it is within your power to contribute to how people perceive their workplace and I have learned it is vitally important to create forums of discussion to ensure people feel heard. I think that the key difference between being an individual contributor and managing others is allowing other people’s expertise to shine and creating opportunities for this to happen, rather than focusing inwardly on your own ability. Influence is much more powerful than authority; you cannot simply dictate best practices and expect people to follow them. It is really important that as a manager you make it your mission to understand team dynamics, tailor how you communicate based on the situation and find ways to encourage, rather than enforce positive change.

When going into a managerial role, you also gain a new perspective on quality in a more general sense. To me now, quality isn’t just about catching bugs or improving test coverage; it’s about fostering a culture where quality is everyone’s responsibility. It’s about creating an environment where engineers, SDETs, QEs and everyone adjacent all understand their role in delivering high-quality software. This means ensuring communication is clear, processes are efficient, and teams feel empowered to own quality rather than seeing it as something ‘QA handles’. The wider view you get of how everyone is working is a stark difference to being an SDET within a squad, which feeds into this mindset shift.

Having the chance to talk with more people (rather than typing away in an IDE) has affirmed to me that good quality is often invisible. When things are running smoothly — when releases are seamless, and users aren’t reporting issues — it’s easy for the work of a quality-focused team to go unnoticed. A strong quality culture is about preventing problems before they arise rather than constantly firefighting them. This has made me appreciate the importance of proactive leadership, influencing without authority, and creating feedback loops to continuously improve how teams approach quality. You also need to learn how to draw attention to your report’s achievements and help amplify all the good stuff they do which often flies under the radar.

Lastly, I was surprised by just how emotional leadership can be. People management isn’t just about performance reviews and setting goals — it’s about supporting people through challenges, understanding their motivations, and sometimes helping them navigate personal struggles that impact their work. Learning how to balance empathy with accountability has been a huge growth area for me and something I reflect on almost daily.

Watching people build up their skills and push themselves is really rewarding and even after the comparatively short time I’ve been in the role I can understand why people continue down this career path. It isn’t easy, by any stretch of the imagination, as it is a completely different skillset needed to being an SDET. Having the technical background will allow you to talk about details with your reports, but you will also see yourself moving away from being on the ‘cutting edge’ of what is hot in tech, which has often caused me to question if it is the right path for me. Honestly, one blog post definitely isn’t enough to capture every nuance of the role and whether it’s the right decision for you; if you do take the leap into management, be prepared for a lot of learning, a lot of meetings/talking and (hopefully) a lot of satisfaction in watching your team grow.