Recruiting talent, defining career paths and maintaining “balanced” teams
Note: this is part III of a 5 part series. You can find the 1st here, and 2nd here.
I choose talent as my third big challenge.
There are obvious difficulties in hiring the non-abundant technical talent: high salary demands, high “benefits” demands, having interesting and challenging technologies/products… and I can go on for ages…
Besides the external competitive conditions that we can blame all they long, there are internal conditions that are on our hands to control but are quite challenging to define and use correctly.
Recruiting process
The internal process for recruiting has many difficulties that are not easy to overcome. I will list a few of them that I consider critical:
- Keep the “upper funnel” healthy: even when you do particular actions to recruit talent that bring many candidates to your door, it’s quite hard to set up a process that keeps that inflow of candidates high and constant.
- Efficient technical filters: the best scenario would be to have some automated test that provides feedback on whether a candidate fits your technical requirements or not. For software developers, there are more tools that let you create automated tests, but it is hard to keep it up to date and change it frequently to avoid “cheating”. For Product Managers, UX and designers it is harder since there are no standardized ways to test technical knowledge (there isn’t even agreed upon job descriptions!). In my case we create technical tests that we evaluate case by case, limiting our ability to tests many candidates at once.
- Interviewers time: when you are hiring and the team is expanding, you probably have your scarce resources working at max capacity (that’s why you are hiring!). On the other hand, in order to hire you usually need to spend the time of your most talented team members on interviews. Balancing this dedication is quite challenging.
- A standard way to test seniority: another challenging aspect is having a clearly defined line to separate each seniority level and being able to objectively testing it. Having multiple interviewers is a way to go about it (but discussions will arise), and it even worsens the interviewers time challenge.
Growth & Career path
Creating good job descriptions is hard enough. But in a context of multiple disciplines (Dev, UX, Product Management, Data Analysts, etc) and heavily changing work scopes and tools, it’s even harder. Furthermore, each “product” may require different skill sets (for instance an API product is quite different from a final user product, or a B2B versus consumer product).
On top of that, you need to add seniority levels, evaluation mechanisms, training.
And you also need to consider growth: everyone wants to have higher challenges. But in product development, many times individual contributors do not want that growth into people management positions (which is great). Many want higher responsibilities in terms of the impact they can make participating in more critical products and you need to design the appropriate path for that.
Balancing conditions
I will split balance in 2:
- Compensation related
- Team seniority related
On one hand, for reasons similar to the Growth and Career challenge, keeping “egalitarian” conditions is also difficult. Let’s see a quick exaggerated example:
You are using a particular technology stack and find out that you need to change it. New developers may have “higher” conditions. You need to satisfy those conditions in order to hire. You generate an internal difference with team members already working for the company. In order to match the conditions you first need to put them up to speed in the new technology.
This scenario happens with many different variants due to the changing conditions of product development, making it quite difficult to keep it balanced. And of course, it depends on your company size and probably geographies.
A second balancing challenge is keeping teams balanced in terms of seniority according to their needs. Teams with too many juniors may have a hard time growing since there isn’t much opportunity for senior coaching. But also when you balance seniority you need to make sure that coaching is happening since not always senior team members are good mentors.
On the other hand, you need to map the difficulty of the challenge to the team seniority. For example, products with lots of uncertainty may need senior researchers while products with high technical problems may need more senior engineers. Of course, this is even harder because how hard those problems are is difficult to define before having a team to actually look into it, and many times the “challenge” changes from time to time making your planning useless anyway.