I get lots of enquiries from founders of start-ups who reach a certain growth point where they really need to start taking control of the quality of the work being produced. Their companies seem to reach a size and market growth where the focus on quality becomes a priority.
This is usually about the time when I get a call or an email and get posed the typical next two questions:
“How do I go about starting a new test function?”
“Where do I find a good Test Manager?”
This is a common mistake many companies make – they create many different functional departments with associated management structures (Dev and Test and Release Test and UAT etc etc) when the reality is the work doesn’t (or shouldn’t) flow like that.
My advice is always to “follow the work”, not what the traditional industry titles and literature may advise.
If you’re in the great position of building your team from the start then study your process and the work before designing the functional teams and the management that sits across that.
In my experience, after studying the work at a high level, people identify that it does indeed move between “traditional” functions such as Product > Dev > Test > Ops > Support etc.
It’s therefore easy to assume that functional departments, with functional management, should be created to service these handovers and processes. But this is a mistake.
Further studying will likely reveal that it’s at these boundaries in many organisations that the likely “quality” gaps are found and time is wasted.
Whenever there is a handover there is likely mis-communication, the breaking down and rebuilding of work and hand-offs between people. This takes time and is likely fraught with mistakes and missing information.
Sometimes it’s possible to make these hand-offs painless – sometimes it’s not.
It’s why so many companies work hard to break down these boundaries (Agile, DevOps, ServiceOps, Cross Functional Teams).
It’s why, refreshingly, a growing number of companies in our industry are creating environments where functional hand-offs are few and far between.
For many people though it’s scary to not have these boundaries and functional silos – certainly between Dev and Test.
It’s why so many people ask me how to create these functions in the first place (I always advise them not to).
It’s scary for people because many people, in traditional roles, often wonder what would happen to them in these new functions. That’s totally understandable. It’s scary to wonder what will become of roles likes Test Managers, Head of QA etc when these functions start to become part of a main Dev team.
- Will they still have a role?
- How will they personally need to change?
- Who manages testing now that Dev do some it?
So resistance appears.
At a test event a while back a Test Manager told me that he would “resist and fight agile to the death”. To the death! (I think he was speaking figuratively)
Why? Because he couldn’t see himself working in an agile team. So he resisted. And by all accounts he did a remarkably good job at this resistance. But it’s not what his business needs.
So why create these boundaries in the first place?
Some companies will never break down these silos which is good news for some Test Managers, like the one who will fight agile to the death.
The sad reality is though that many of these companies desperately need to break down these silos to survive and remain competitive. They are unlikely to do that with people who fight this change.
I did a talk about agile at a large financial services company a while back and I’d say about 70% of the room were shocked at what agile and DevOps looks like.
I got questions about the future of certain roles. I got statements about how chaotic it sounded and how it would “never work here”. Sadly, they were right. It would never work there….with that group of people.
For epic change to happen you need people to believe it will, and that it will be good. I told the execs that it was entirely possible to move to agile within their IT organisation – but not with the majority of their current team. Sometimes we have to face the reality that the people we’re working with are not the people who will bring about change. And that is often a harsh reality too far for many managers.
Other companies are breaking down these barriers. Good news for Test Managers who can adapt, not good news for Test Managers who cannot.
And some companies have the ability to never create these barriers in the first place…….and that’s a great place to be. And that’s why I always advise my startup friends to create as few boundaries as possible, to follow the work and never to go searching for a “Test” Manager.
What are your thoughts on the future of Test Management?
How are we creating the next generation of Test Managers – or as I put it – Managers who care about doing good testing?
Are the certification schemes helping or hindering our evolution to a new way of managing?
Image from Unsplash – by Joshua Earle
Edited and mashed together in Canva.