Two common misconceptions surround retention. First, that retaining staff is something organic that that simply happens based on how a business generally treats its employees. Second, that businesses should always want to retain staff as long as possible.
Neither is strictly true.
Whilst companies with no vision, resources or positive culture will find it harder to retain employees, there are many businesses that have all these things but still suffer attrition rates over 50%.
Real retention involves making strategic decisions at the point a position is designed, taking into account the typical career paths within a given employment market.
Positions, like careers, evolve – especially in technology, where the speed at which companies must acquire new skills and knowledge is so high that long-term retention in any given role seems idealistic by default. The response to perpetually evolving business needs is career growth, yet, in many cases, this may not be practical or even desirable for positions designed to fill short-term knowledge gaps.
Therefore, the true retention goal lies in making informed decisions surrounding how you can get the most value out of each employee before their immediate learning curve expires and they seek out a new challenge.
How role design works
Including every skill that you think your new hire will need in your job adverts and role specs is tempting and it can serve as a beacon to ambitious jobseekers, however, it will also severely limit your hiring options. There is an inverse relationship between required skills and the amount of available talent: the more capabilities you ask of your applicants from the outset, the fewer qualified professionals you will find – and the more compensation they will require.
Consideration must also be given to the career path the role will lead your future employee down. The role needs to both fulfil your organisation’s current and future needs and address the short- and long-term career aspirations of the professional that will fill it.
To illustrate this, here’s an example of how deeply retention can affect role creation.
Consider an eCommerce business where constant experimentation with new features, layouts and design is critical to driving sales.
To improve the customer experience, this business is hiring for a Quality Assurance (QA) position.
Similar to other QAs, this professional would be tasked with ensuring the functionality of the company’s customer-facing platform – in this case, their website. Ideally, the applicant would have experience in testing websites using both manual and automated methods, anticipating user behaviour, and creating test packs that can be reused continuously. The role would hinge on testing the success of a large number of simple features or interface options.
- The utility of a search bar
- Best drop-down menu format
- The boost potential of TripAdvisor ratings on results
- The impact of offering a reviews section on a product page
- The ideal number of default search results
- What advanced search filters to offer
Due to the volume of options to be tested, a QA for this company would primarily be occupied with testing usability and performance by replicating user behaviour and uncovering hidden bugs or inefficiencies. But eCommerce platforms are complex; anytime a new feature is added, everything would need to be retested to ensure the new element has no unforeseen knock-on effects.
Simply mimicking customer behaviour is therefore not enough – the scope is too vast and repetitive.
Automated tests must be created and run using tools like Selenium that can cover the entire codebase before any code is committed. This means that any time a new feature is introduced, a corresponding test must be designed and implemented to ensure ongoing usability, and the applicant would need to understand how to use automation tools.
However, only 5% of new features are usually incorporated into the website permanently. This means the QA would only infrequently need to write code for regression tests. But if the business were to add regression testing to their list of criteria for the new QA hire, they can expect 3 things:
To understand why this is the case, we need to look at QA career paths. In 99% of cases, QAs come from a functional background where they don’t write code, instead manually testing the functionality of it for developers.
As high-availability, web-based software has become the norm, QAs are increasingly being asked to automate testing using Selenium or similar tools. However, this need to code is a huge learning curve for many testers; those that do manage to pick it up tend to prioritise positions that allow them to code often.
This means that QAs who can code are few in number, high in demand, and motivated to seek out code-heavy positions.
So, what can you do in this situation?
Should you prioritise QAs that are capable of coding the occasional automated test, understanding that the applicant would need higher compensation and may get bored quickly with few tests to code?
Or choose instead to hire a less expensive, more junior applicant that would be able to learn how to code tests on the job?
How to design the most effective and motivating QA roles
First, your business must decide its hiring priorities and what sort of applicant would provide the most value to the company based upon the applicant’s current talents, future potential, and likely career interests.
Maximise retention and long-term value: drop the need for coding experience.
By foregoing the need for coding experience, the talent pool widens to include high-potential Test Analysts with superb business communication skills who are already actively pursuing a learning journey into code. Initially, they would be focused on the 5% of their role that requires them to use Selenium to run tests using code. As they become more proficient at this over time, your company may then hire a manual tester to do the manual testing, opening up an opportunity for the first employee to progress into either a management role or take on more technical back-end API testing.
By defining responsibilities from the beginning and designing a clear career path, your company should be able to ensure retention of at least two years, incorporate a learning culture, and maximise the value of the employee.
If coding experience is a must, hire a developer to write code for the Manual QA or find a QA that has some coding experience, but not so much that they see manual testing as a limitation.
If there is nobody else in the business who can impart automated testing knowledge, then your company has no choice but to necessitate programming experience in the role. The best solution, in this case, would be to hire a developer to write code to execute tests designed by the manual QA. But if that isn’t an option, your company will have no choice but to trade-off retention in favour of a technologist who can do the specific job immediately.
This is where the balancing act comes in. The role requires someone to create automated tests only 20% of the time – if you do hire someone who is accustomed to creating automated tests 100% of the time, their retention will be remarkably short: probably not much longer than probation, as they will find themselves stagnating in the role.
What your business needs is to find someone who has performed some automation and is adept at it, but who has not completed so much that their learning curve is spent. To hire this way, you must ensure the description and screening criteria for the role clearly reflect this career progression and showcase the challenge on offer.
This option is likely to be the most expensive but may also be the most efficient, delivering the highest quality of output in a shorter period of engagement.
Find a QA who already has some coding experience and offset the manual testing portion of the role by designing a career path that offers rapid progression towards a role in management.
The final option would be to find a QA with coding experience that would be interested in pursuing a career path that leads into management. Before you offer this, however, you must ensure that the growth of your QA team will be sufficient to support the need for a Lead QA.
If so, offering a path into a team leader role is a fantastic way to build retention into the role while nurturing both the short-term needs of your company and its future growth.
To find the ideal person for the role, you must screen every applicant to ensure they possess the potential and desire to manage and see a path into management as an attractive growth path.
With this option, your business will gain the automation experience it needs immediately and will encourage retention by grooming the applicant for a leadership role. The only risk to retention in this scenario would crop up if growth slows and new staff hiring slows – which could lead to your QA coder to explore the options of a fresh environment in which they can further develop as a leader.
From the above, you can see that shaping even one role to include retention is a strategic decision that requires you to consider existing resources, specific career paths, detailed skills knowledge, available budget, business goals, and future growth.
It is not a simple process, which is why hiring lead times in the technology space are typically high and retention rates typically low.
To effectively create roles that both fill the gaps in your workplace and appeal to technology professionals, you must take the talent market into account.