Date: 09 April 2019
I want to share something that I’ve picked up on over the past few months – though no doubt this problem has been quietly simmering for years. I don’t think there’s a quick fix for it either.
A multi-skilled tester job description is a good thing, right?
There was a time when it was easy to know your place in the testing world. You’d start as a bright and bushy-tailed grad in the role of a Junior Tester. You’d claw your way up the ranks – Tester, Test Analyst, Senior Test Analyst, Test Lead, Test Manager, Senior Test Manager… All very structured and stratified. And that’s mostly still the case today. People are still appointed in specific roles and their job descriptions still reflect the ‘ISTQB party line’.
The problem I see is that the modern way of working doesn’t actually support this stratification and qualification of jobs. Today, if you’re involved in software development in any way, it’s likely that your organisation focuses on Agile ways of working where individual team members are expected to be ‘generalising specialists’. In other words, a jack of more trades, if not quite all.
In theory at least, as part of an Agile team (scrum, tribe, squad), you’re expected to have multiple skills to support the ‘whole team’ concept – where the team as a whole is responsible for, and able to deliver the required outputs. This article, as an example, talks about the crossover of skills between Test Analysts and Business Analysts, as well as how more demand is placed on the software tester to have a technical aptitude to facilitate more technical and automation testing.
A blurring of lines
Due to peaks and troughs in workload, it might mean that team members need to step into delivering items that they’re not necessarily qualified for, but have developed the required skills through interest or out of necessity. So developers should be able to test, testers should be able to develop…
This is also true with the changing requirements placed on QA tester skills in the context of DevOps. With more of the testing focus moving towards automation and testing often now being the responsibility of the developer rather than the tester, it leaves the QA professional with questions around his place in the eco-system.
In Agile environments, there’s also less differentiation between the levels of responsibilities in a testing project. For example, the individual responsible for quality in an Agile team (if explicitly stated) might be responsible for all aspects of testing – from test analysis through to test execution, management and reporting. In other words, there’s a blurring of lines in the levels of responsibilities, not just in the types of skills required.
How can a ‘Jack of more trades’ climb the career beanstalk?
This approach has some implications to individuals, their careers and life aspirations. Let’s look at a few:
- There’s a disconnect between the actual work that happens in Agile teams (from a testing/QA perspective) and the role, job or level that someone has applied, and is appointed for. Someone could be appointed as a ‘Test Manager’ but might end up executing test cases and maintaining automation scripts (as an extreme example).
- This, in turn, has an impact on performance appraisals and KPI settings. If appointed at a Test Manager level, there are often accompanying performance levels or indicators that have to be met as part of measuring and tracking individual performance. If you operate in an Agile team and perform ‘other work’ as a part of that team, this might end up negatively impacting on formal performance appraisals that are focused on more traditional roles.
- Individuals tend to have the desire to progress, to get better at performing their roles. You could argue that becoming a better team member of an Agile team has its own reward. However, human nature means we look for more formal and explicit recognition of experience. The only way to gain that recognition traditionally was by progressing through some form of hierarchical ranking system offered by the opportunity to gain promotion from one level of work to the other. Because these various hierarchical levels still exist in organisations, the type of experience gained in Agile teams is often incompatible with what’s required to progress to these levels.
- The organisations still applying the historical legacy route of job descriptions, levels and hierarchies are rapidly becoming out of step with the reality of today’s way of working.
A complex set of interrelated issues
The new way of working – with its more egalitarian and ‘whole team’ approach and its requirement for individuals to be multi-skilled – may result in people ending up with vague formal job descriptions and job experience which reflects poorly on their CVs from a formal job search and job application perspective. This is due to the fact that formal job descriptions, organisational HR policies and hierarchical job levels are still alive and active in most sectors of the market.
The new way of working also impacts on individual aspirations to progress in some way due to promotion being possible through various seniority levels such as ‘Senior Test Analyst’, Test Manager’ and so on. There’s a disconnect between the old ways of recognising good performance (be a good Test Analyst and one day you can become a good Test Manager with the status and remuneration benefits that entails), and the behaviours that should be fostered to increase performance of an Agile team as a whole (gain more skills outside your formal career domain so you can become a more valuable member of the team and deliver more value to your stakeholders).
What’s the solution to the demands made on a tester’s skills?
If formal HR practices lag behind an organisation’s move into new ways of working, I think it’s hard to see an easy or quick solution. It’s HR itself, of course, that needs to adopt ‘new ways of recognition, reward and promotion’. Measures need to be put in place to align formal job descriptions and job levels with what’s actually valuable in the workplace. An individual with more skills across domains – and who’s prepared to work at any level and do work outside the formal job description – is more valuable than someone who just gains more and more experience in one specific skill domain to be promoted through the levels.
Achieving this shift might seem simple, but I think it’s more difficult in practice. The idea of various job levels is so entrenched, it might take years to change. Change also needs to negotiate other challenges; while new ways of working are very prevalent in IT and software development, they probably won’t be across the wider business. Can you really get rid of job description hierarchies in IT but retain them in other areas of the organisation?
Agile HR. A way forward?
The concept of ‘Agile HR’ is gaining traction as a way for organisations to address this problem in a formal and explicit fashion. It argues that the most obvious and straightforward way to change organisations as a whole – to become more Agile – is by adopting Agile HR practices.
This puts the HR department at the heart of transformation. It must align the way that job titles, descriptions, reward strategies and talent acquisition work with the new way of working.
Among other things, Agile HR means:
- Encouraging generic job descriptions which aren’t hierarchical
- Decoupling pay from hierarchical job structures and linking it to value
- Having more frequent performance reviews
- …And having those reviews done by peers instead of managers
Assurity is actively leading change in this area by developing specialised Agile courses for HR teams that recognise they have a critical role to play in transformation.
Be optimistic! A tester’s future should be brighter…
…But you might need to be patient. It’s inevitable that organisations will move towards valuing what’s really worth valuing – different skills, domain knowledge, attitude and aptitude, as opposed to more and more experience in the same domain. The organisations that don’t move fast risk losing talent to those that do move fast. And it’s that which will inevitably drive change in HR ways of working.
Ultimately, of course, there’ll be more opportunity, recognition and reward for the individual who wants to work outside the boundaries of traditional testing and master the T-skill concept. Eventually, testers can have their PI and eat it too!
