QA Managers Should Not Exist

QA Manager. It's what I wanted to be for ages. But take another look at the heading of this post...

Eh?

Having spent a good chunk of my career working towards my current position, and with it being the logical (and arguably only) route for progression, you'd be forgiven for thinking I've taken leave of my senses.

But having now spent a year or so doing the job, my feeling is that the role of a straight-up QA Manager is becoming obsolete. In a properly staffed modern software delivery team, there's no logical place for the traditional role, particularly with the advent of Continuous Delivery.

Scrum Masters and Tech / Dev Managers cover off a lot of the stuff a QA Manager would have, and with Testers being smarter than ever about digging deep into the system under test, and carrying out smart risk based testing, there's very little need for a QA Manager to direct traffic in that area.

So what have I done about it? That's easy. I've rewritten my job spec, redefined my role, and asked for my title to be changed.

I've known for a while how I wanted my role to change. To me, the modern test leadership role is about enabling testers, not managing them, and I'm doing a lot more work in the wider world of QA and software delivery - both internally and externally.

I'm still the one who provides first line support for all the day-to-day and architectural aspects of QA, acting as a central point of knowledge and escalation, as well as providing leadership, support, recruitment and onboarding, and guidance on appropriate training and career advice for those under my management. That part of the role will never change... but that only forms part of the modern role.

A big part of what I do now is working as a community leader. I'm publicising and organising educational and networking events within the company, letting those who are interested get together and share team and industry news, as well as their knowledge and expertise. This also offers a platform where folks can try their hand at presentation, and hone their craft with a 'soft' audience before going out and presenting to the wider world of Testing - if they want to.

That ties in to something else I'm doing - Showing the team that there’s a whole testing community beyond our company bubble. I publicise online webinars & talks, external testing events and meet ups, and I arrange for the company to sponsor places at relevant conferences whenever I can. I also regularly share blog posts and industry articles to get the team thinking more about what they do and how they do it, and encourage them to create and share their own thoughts on these channels.

I'm also planning to act as an external advocate for our company. At the moment, most of my written work is published here, but I've got wheels in motion to deliver content on a dedicated platform, and it won't just be blog posts. Let's just say you're going to learn what I sound like as well as how I write...

But it's not just me that I want my team to hear from. I'll be arranging for external speakers to visit our events from time to time, not just to help educate our QA team, but to also share our ideas and practices with the speaker. The idea is to provide them with an insight into what we’re doing, and offer a generally positive experience of speaking at our company, so they might publicise the work we’re doing and give us and our work some free (and importantly, relevant) press, and raise our profile in the wider tech community.

Importantly, it's not just the QA team that I'm influencing. I also see it as my role to campaign to the wider business for investment in testing, and to champion the value that we bring to the SDLC, and I'm educating the team on how to talk about testing and the value it brings in a similar way.

What's In A Name?

The hardest part of all this has been trying to decide what my new title should be, as I've been given a more-or-less green light to call myself whatever I feel fits the role. A lot of folks are adamant that technology titles don't really mean anything nowadays, and there's very little to distinguish between a manager, an architect, a guru, an overlord, or whatever other ridiculous indulgent titles people are giving themselves. But given the scope of what I'm going to do, it came down to two choices in my head:

QA Coach encompasses quite a bit of what I'm going to do, particularly the teaching / information sharing aspect. But it does make the role sound very prescriptive and preachy, like I'm going to be sat in an ivory tower dispensing nuggets of wisdom.

QA Evangelist shows what I'm going to be doing in the wider world of technology, as well as how I'm going to be a champion for the QA discipline within technology. But it does sound a bit like one of those ego-stroking / placating titles you see from time to time.

It's a funny old world where Evangelist sounds less preachy than Coach, isn't it? But of the two titles, I think it's the better one. It's certainly more descriptive of what I'm doing with the role, it gives the right message of enabling the team, bringing new tools and new ways of thinking to the table, sharing knowledge, being a champion for our discipline, and generally helping the team to win.

With this reinvention, I feel I'm bring a real change to the way we're doing QA as a team. By being aware of what our industry peers are doing, the steps they’re taking and the thought processes they’re using, we can crib ideas, improve our own processes and practices, and move forward at a faster rate than ever before. And by sharing and engaging, we also have the opportunity to give back to the community, to change the way we’re seen, and to really demonstrate the value we bring to software development, both internally and externally.

Sounds better than sitting around and occasionaly approving timesheets and expenses, right?