Hi, guys! My name is Vladimir, I am manager of the client applications (apps) engineering team at Utkonos. It includes front-end and back-end development of mobile apps, microservices, courier apps, and lots of other external integrations.
In this article, I will tell how to motivate your engineers not only with high salaries, but with systematic growth & development that we use at Utkonos. One day some of my developers brought me an offer with a figure that significantly exceeded his current level. And to keep him at the job, I needed to:
- outbid that offer,
- convince the HR department to make promotions out of the existing framework,
- and make that developer lay his bare heart out and come down to earth from his thoughts about the new job.
And I wondered: what if not one person, but several, or a whole team did the same thing? Hence, it became clear - I must provide employee development inside Utkonos, so that this value won't be outbid by other companies.
Offers from the market are being brought not only because of higher salaries, but also the desire to grow in certain competencies, and you, as an engineering manager, are constantly facing a permanent shortage of resources and often think about the development of Junior talents rather than hunting the strongest ones on the market.
- How does a manager know that an offer from another company isn't too much and the developer is worth the money?
- How can a developer build a career path at Utkonos?
- How to organize a negotiation process on different salaries in a company that are equal to the market level?
- How to avoid planting a "salary inequality bomb" under your own department, where people with the same level of skills have different salaries?
So, a developer brings to you a market offer, knowing that she carries a bus-factor of over-9000.
We shouldn't see it as a blackmail from a developer, but we should believe in his market value. Moreover, it was our fault to miss the moment, when the developer started to "hold everything together".
And then the shuttle diplomacy starts: we go to HR, try to circumvent the rules for raising salaries, and look for the pitfalls of such promotion. How would your developers react if their colleague became a Senior and they didn't? What are the developers' real motivation? What are the levels of tasks/salaries of the whole team?
In order to solve these issues we needed a systemic tool - a standard. Using it, we could evaluate the developer's work, and results of evaluation would be as transparent as possible.
To find an answer to these questions, we turned to Vectorly.
The service offers a system of digitized assessment of developers that shows the level of their correspondence with the occupied or expected positions in a company, and also shows growth areas of each developer.
Creating a skills matrix
Skill matrix contains skills and the levels for each skill.
To begin with, it was necessary to build a skills map with levels that can directly indicate a developer's level, whether she is Junior, Middle, Senior specialist. The matrix should include both skills specific to your written code (frameworks, libraries, patterns) and general ones.
- The process itself is pretty time-consuming, by doing it alone you can easily burn a 2-week sprint.
- You can make a map that will suit your team straight off.
Each team leader took on the related competency maps: for Angular, Go, Android developers, and wrote down the necessary skills. The Vectorly team provided us with ready-made skills map templates beforehand, we adapted some of them to our specifics, which significantly reduced the time of work.
Career vectors and positions
Inside of each map, you can set up career vectors and positions with the necessary skills that help to determine the developer's level. Whether she is a Junior, Middle or Senior specialist.
A position is a set of selected skills. Within each position we set required skills and levels for each skill in order to fully match the position.
It is important to align skills with levels so that they fit market requirements.
Finally, we got to the skills review process. It is divided into 3 essential steps.
- Self review
- Review by engineering manager
- Review by team members
Self review is a starting point of the whole process. It allows you to set expectations for yourself and share it with the manager and other reviewers.
The next step is the manager review. This step is very important, because it allows you to see and understand the difference between developers' and managers' points of view on skill levels. It might be a great idea to have a forehanded discussion on this topic, so both of them won't create false expectations and, as a result, won't make irrelevant decisions about developers' growth and career development.
The final step is team review, which allows you to get a more representative assessment of a developer, based on the opinion of team members. The manager can’t see all the work that the developer does. And team review helps to highlight all strengths & weaknesses, and calibrate the results. The final decision of the overall review should be based on the results of this assessment.
Great, we reviewed developers' skills, results are in the system - now it's time to draw some conclusions.
Firstly, we see the level of compliance with the position in percent. It allows us to notice in time how much the person corresponds to the position that she holds or expects to hold.
Secondly, we see the developer's growth areas, which are necessary to upskill, and can easily add these skills to the growth plan.
Thirdly, we made the whole process open to the team, which means the developers' skills level is known to everyone. This comes in handy when developers decide to reveal their salaries to each other, then they will find out earnings are calibrated and based on the results of the review. Thus, we eliminate the issue of "salary inequality".
Integrating results to HR process
In order for the tool to "take off" successfully and become an argument for HR department, we needed to:
- Approve the matrices with the HR department. They wanted to make sure that skill levels had clear definitions.
- Have position mapping on what would be written in the job description.
- Have position mapping on salary differences.
- Maintain objective evaluation within the team.
1 and 2 points are fairly routine, 3 and 4 ones have some important aspects.
It is recommended to transmit the responsibility of updating salary differences to the HR department. Better update them twice a year to the market level, and bring developers' salaries up to the market level through the regular reviews.
The assessment can be biased, because communication in a team is limited and goes between the same people. In order to keep your assessments unbiased, it is useful to have an external expert to conduct the review. In our case, we invite experts from other companies with whom the team members are familiar.
We have just started to implement this system, but we already see the first results.
Our HR department shuddered, when they heard the word "grades", saying it was a monumental job. Thanks to Vectorly, we assembled skills matrices and grades for each position, and passed it on to HR. Now each position has 3 grades, bringing the total of 9 grades for developers, and each grade has corresponding expectations in terms of the developer's skills.
This gave our company an opportunity to structure the positions, explain salary differences for each grade and keep an eye on salary inequality. And avoid the situation, when developers, which were hired a long time ago, are paid according to numbers of the time when they were hired, and newcomers get the money of the new market that has already grown.
Vectorly allowed tech leads to structure expectations in terms of developers' skills. They get a tool in their hands that can help to develop strengths of the engineering team, and give a clear growth plan for each developer. Also a truncated form of the matrix can be used in interviews, depending on the position the candidate is applying for.
Developers gain an understanding of how they can grow in the company and what it takes to do so. Our skill matrices will soo contain not only the required knowledge level, but also links to where to get it.
15 Factors That Influence Developer Productivity - A Complete List
Measuring developer productivity, a manager should use a complex approach and not rely on a single metric. We prepared the ultimate list of all the factors that influence developer productivity and recommendations on how an engineering manager can boost dev team performance.
Red Flags That Indicate Your Team Needs Software Engineer Performance Review - Checklist
If you’ve noticed that your team’s performance is slipping, deadlines are being missed and the end result of your software development efforts is sub-par - a software developer review is overdue! Read the article to find out other signs you should implement this practice RN.
Vectorly Case: How PINKMAN Reviews and Develops Skills Designers
At Pinkman we wanted to scale and transform our design team from 25 to 50 people. But due to high costs of ready-made employees and small amount of them on the market, we couldn't hire them. That's why we decided to hire junior people with different backgrounds, and grow their skills.