Hello, my name is Vitaly Fedorkovich. In the industry, I started as a C ++ developer, had the experience of a Team/Tech Lead. In WePlay Esports, which is part of the TECHIIA holding, I held the position of Technical Product Manager, and now I am Head of Engineering. I am engaged in the assembling of technical teams, the growth of engineers in the company, and the technology stack.
Money is quite essential for any business, especially for IT. No technical article will gather as many views and comments as yet another salary survey, the story of a sweater that went from UAH 3,000 to $3,000, or tips on how to get a higher rating in a company. Because, as John Stuart Mill said, ‘People do not want to be rich. People want to be richer than others.’
This article will be particularly useful for Team Leads, CTOs, and those who (sub) consciously build a vertical career. And developers will see what their manager can pay attention to when reviewing the salary.
Just a couple of words before we begin
I will talk mainly about the product companies’ approaches, in particular those that we have been using for several years in WePlay Esports and other IT teams of TECHIIA holding. With certain limitations, these methods can be used in outsourcing/service companies.
I will not talk about toxic companies. If you have experience working with such, then you know that they work according to completely opposite approaches.
So, I will try to cover the basic questions from managers and engineers when it comes to salaries:
- How often do I review the rating?
- How do you find out about the salary expectations of the developer?
- What and how does affect the salary review?
- What is the salary policy based on?
- And what is more important - tangible or intangible motivation?
The Core of the Rating
With no strings attached, there is one reason to increase the salary, that is the moment when the developer begins to bring more value to the company.
The manager’s craft is to track this moment in time and adapt the employee's rating to his/her new level.
"What about the market?" you ask. In fact, the value and demand of the market are connected. I’ll tell you more about this later on.
People need to understand that the rating increases not only because time has passed and bread in stores has become more expensive. Thus, indexation from inflation and other macroeconomic phenomena is inevitable. However, the basic component is value for value. It is important to remember it not only at the review but also during boarding, training, daily work.
A Culture of Transparency
For developers not just to close the task, as Zarathustra product said, but reveal their talents and offer a solution, basic things that should be in the company are transparency and clarity.
Let me give you an example. One of our products is a platform for organizing and participating in esports tournaments. Its features come to engineers in the form of tasks: to create matchmaking, automatic flow for users, registration, etc. It can be done as in the factory: “Guys, here’s the task, here’s the backlog, have fun. If it is done effectively - well done, inefficiently - not well done. And what is the whole purpose of this is not your business."
Instead, we are now gradually introducing the OKR framework - Objectives & Key Results. The owners or the top management set Objectives - that is, where exactly the product is moving. Then Objectives are broken down into specific Key Results that go to line managers, who finally break them down into user pages and features.
The overall result is not only measured by the money the product brings. This can be a specific strategic goal, a benefit for users, and/or the market. As for the tournament platform, our goal is to provide an ecosystem for esports games. We want people to be able to take part in various competitions and grow to the top. There is a whole set of leagues on the platform, where, starting with matchmaking, a person from the beginner level can "play his/her way to" a professional tournament with several-million-dollar prize pools.
The Individual Approach
According to the classics, the review of skills and ratings is done after the trial period, and then on the periodic Performance Review. On average, in IT companies, they are held every six months. The manager(s) and the developer, together with the HR, review the results of the past months, make salary decisions and make plans for the next period.
The system is transparent and clear. Pros - everyone gets used to such a course of things. Cons - exactly the same. The developers are looking forward to the review in a timely manner, so they tie their efforts to it, as to sessions at the university. Managers, in turn, can forget about constant monitoring of the team, and the review will make superficial generalized assessments and set blurred goals.
At one time, we reviewed the rankings every six months and had a clear counterproductive example. One of our engineers really started moving only a month before the review. The external effect was enough to raise the salary for the review. Immediately after that, the engineer relaxed again until the next time.
With this approach, motivation comes down to purely financial sooner or later. That is why we split the review into two coextensive parts.
The first one is the Personal Review. Every four months we set a meeting for the employee, his/her line and functional managers, and HR. The developer shares his impressions of the past period, receives two-way feedback on results and values.
Next, we discuss the goals for the next period. Usually, people know where they want to grow, sometimes you just need to give a little hint about the direction.
It is important that the goals are clear and understandable. Don't just "get yourself together" or study React, but do something that will bring more value to the company. Let's say we know that a new product/project/technology will appear over time, and there are currently no experts on the subject. We had this story, for example, when we shifted the infrastructure to Kubernetes. We set a goal for the engineer to comprehend the technology in advance.
Goals can also be related to soft skills. For example, there are technical managers who perform well but have some communication problems. As a result, there is a misunderstanding in the team, the overall efficiency goes down. The goal may be to improve specific interaction skills.
At Personal Review, we set checkpoints, take feedback from the developer, and then we synchronize.
The second part is, in fact, the Salary Review. As before, we hold it every six months, sometimes earlier. At the meeting, we analyze how a person has grown in their goals and values for the company, and decide how to increase the salary.
This approach has helped us to separate monetary motivation from professional motivation and to distribute work effort more evenly. It needs more attention from managers but takes into account the individual plans and contributions of employees.
Constant Contact With Needs
The productivity of an engineer directly depends on his/her interest in work. So in between reviews, you need to be aware of the employee’s wishes. To do this, once every two or three weeks, the company holds one-to-one meetings, semi-official personal meetings of each employee with his manager.
One-to-one helps to understand the general and specific moods within the team. It is quite normal to talk about life, movies, plans, etc. on them. Surprisingly, working issues and problems are better revealed at such meetings. How satisfied is the person with the tasks and approaches of the company? What factors help him/her to work and what hinders that person? How satisfied is the management?
At one-to-one, we occasionally speak about expectations for professional and salary growth. Not "how much do you want?", But "where do you want to go and what do you want to have for it?" - a kind of local Personal Review. For example, the developer answers: in the next year or two I would like to work with a certain technology and I will be okay if I grow by 15% per year. So managers note such wishes and compare them with opportunities.
Based on these meetings, you can constantly adjust the sequence of actions. We had cases when an engineer, who had been engaged in the front-end all his life, found it interesting in switching to the back-end. Some may want to move to another team, another product, hold the management position.
The manager must give the developer such tasks that would take into account both his interests and the needs of the company. If a person fulfills them, the company will gain value. If a company gets the value it should encourage its employees.
What Affects Salary Review
I roughly divided the factors influencing the change of rating into several standard categories. Just to make things clear, there are no evident formulas between skills and money volume. And even if the company introduces certain sheets and formulas, they need to be reviewed regularly for each case.
We currently use a framework that takes into account five common factors: Mastery, Communication, Impact, Influence, Leadership, and their breakdown in several levels. This should make it easier for managers to review salaries, but it is too early to talk about the results.
The main point remains the same, that the salary is an individual indicator that depends on the specific configuration "developer - manager - team - company - tasks". However, further, I will list some points of reference for managers and give tips for developers.
Hard Skills
The first way for a developer to increase his/her salary is to grow technically and perform better. Let me clarify, just in case: "to perform better" does not mean lines of code per unit time, but the speed and quality of problem-solving.
The growth rate strongly depends on the level of the developer.
For example, for the junior specialist, the salary will increase rapidly. It is normal for such a person to double in the first year in the rankings because he/she starts from the bottom. For the most part, beginners grow hard skills that are easier to assess. First of all, the manager looks at the efficiency of solving problems. The second factor is independence, which is how much less time and attention the mentor needs to provide to an engineer.
Quite a different situation with experienced engineers with years of coding behind them. They already know a lot and have a high rating. It is not so easy to grow in hard skills, and even so that the value for the company increases 2-3 times. So few people will go abruptly from $4,000 to $7,000-9,000.
A good option to grow in the rankings at this level is to take on new responsibilities. This can be a transition to management or architecture, or a new role in the same position, for example, ownership or initiation of a technical project.
Soft Skills
Soft skills seem like a virtual category to many newbies. However, over time, they determine the professional growth of the engineer. How well does he/she interact with colleagues? Does he/she have a lot of unconstructive disputes with colleagues? Does he/she takes responsibility for his/her piece of work and helps colleagues or blames others for everything?
When a developer becomes a manager, his/her achievements are the achievements of the whole team. That’s when soft skills are especially important. The result is affected by how the manager:
- forms a team;
- establishes interaction and resolves conflicts;
- is able to use the strengths of the team and knows the weaknesses;
- works with failures.
We can either talk a lot about soft skills or we can say about them in brief. They cannot be broken down into any micro-units and assigned a percentage of each. Each person is unique in their set of qualities and life experiences, and each encouragement will be unique.
Additional Impact on Revision: The Market
The level of salaries in the market is monitored by everyone, from HRs and managers to engineers themselves. Ideally, the developer should be paid as much as if would receive from other companies on the market. There is an inverse link: each particular skill is considered valuable when it is in demand in the company and in the market.
With heated demand in IT, certain differences in the ratings are inevitable. But if the difference with the market is 50-100%, even in the case of super-motivation and super-interesting tasks, the engineer will leave you. These are additional costs for attracting and adapting a new specialist. Together with HR, we calculated the cost of hiring a new person with a replacement, usually, it is 7-9 monthly salaries.
However, in isolation from the real skills and results of the specialist, the market is just numbers.
For example, a developer who recently came as a junior specialist now considers himself a strong middle and says, "Give me a XXXX salary, because that's how much my level is paid in the market." The difference with the current rate can be huge.
We have only a few such stories because we constantly monitor the quality of the team's technical skills. If someone has already come with a similar claim, then the manager has missed something. In any case, we analyze the level of the specialist here and now.
It is better to check such statements in practice. At a joint meeting with the developer, we choose a short checkpoint in a month or two. We give some tasks of the declared level on which the person will be able to show the expertise. Important: he/she must have a good understanding of the background of the tasks and accept the conditions.
After that there are two options:
1. The person coped with the task. So, the person has really improved and brought more benefits to the company. This is a great reason to increase the rating and give more difficult tasks. The manager further monitors the development of the engineer more closely.
2. Tasks performed partially or not performed at all. So, the developer overestimated his/her capabilities. However, this might reveal his/her growth ambitions. In this case, we set up the meeting with the manager, HR, and created a plan of professional growth and action for the next period to achieve what the person wants. A partial incentive increase is also possible if the engineer has shown some success.
Of course, at any stage, a person can refuse and try his/her luck with another company in the market with a higher salary. Especially if he/she already has an offer from another company and wants to bargain. But in this case, you are unlikely to change the opinion of the engineer about him/her leaving, even if you offer the same money as the other company.
Additional Impact on Revision: Values
The salary policy cannot be discussed apart from other company processes. There is one thing in the foundation, the internal culture.
Every company has its own culture, even if it is not formalized. It was originally created by the founders and owners. They have their own vision of the business, teamwork, and other rules of life. For comfortable work, they will select people with a similar mindset. So these values are shared by the founders, managers, and employees.
A good practice is to formalize values. There should be no more than five of them to avoid a mess. In WePlay Esports, for example, there are four of such:
- esports evangelism;
- teamwork;
- initiative;
- responsibility.
At first sight, these are some general words. In fact, values are a clear tool for hiring and bonding a team. Before compiling this list, managers carefully checked which areas of work sag and why. We've outlined what to look for in interviews and what might be important when reviewing the salary.
For example, to find a (non) match, we conduct an additional stage of the interview - the bar-raising. This is a meeting in any form with the company's manager, who will not work directly with the candidate. We not only check the soft skills but also look through the eyes of an uninvolved person to see if there are any critical differences in values. Even one of them can cause failure, despite the steep hard skills.
So we save time for ourselves and people. For example, a developer who is not very interested in esports is applying for our vacancy (moreover, he/she does not like and does not want to understand it). Most likely, it will be uncomfortable with us for such a person, and vise versa. The lack of interest in this industry at best will lead to the fact that the specialist will work only for money and will leave at any moment.
Such an "esports check" is more about entering the company. But responsibility, initiative, teamwork are completely comprehensive values for work and growth. If a person sees a problem that others do not notice, and does not wait for something to happen, but comes to the manager and offers a solution, it is encouraged to increase both the position and the rate.
Intangible Motivation
No matter how much you want to simplify, it is difficult to keep people with money only. Sooner or later, someone appears on the market who urgently needs a specialist in a certain field, and offers a higher rate. This is a common problem of outsourcing companies. Often people go just because the company next door offered + $500.
In such situations, free lunches, yoga, or beer from the company on Friday do not help. In the end, it's the same money, just used differently. Intangible motivation has a key impact. This is what an engineer cannot buy:
- interest in the industry or specific product;
- growth tasks;
- coordinated team;
- strong manager.
For example, it is very important for product companies that a person was into the industry. Then he/she dives deep into the nuances, offers own ideas not forced by the product manager. Of course, any HR will say that people of interest are needed everywhere. However, for product companies they are crucial.
Personally, we try to hire people for whom money is not the only goal. But this does not mean that we will motivate only with bonuses, interesting projects, and we will not increase the salary. Quite the opposite.
Three years ago, we hired an engineer to cover one of the niches. I remember that during the interview I even had doubts about the technical skills of that specialist. However, he showed his interest in esports, our products, our approaches.
This engineer never approached me with a promotion request. But the interesting thing is that currently, this person has the most rapid salary increase in the company.
He started as a regular developer and grew up to be an architect. All the transitions were logical, he saw some problems in the direction and offered solutions. Colleagues were asking for advice on technology. He was driven by the industry and the product itself, and from there came the initiative. Due to this, the engineer worked ahead of time, he began to perform tasks in his place that corresponded to the new position.
This is often the case with the growth of positions and salaries in our country. For us, the main thing is that a person was interested in working for their growth and growing the industry. So we support and encourage, with money also.
It should be said here that not everyone wants to grow continuously. And they shouldn't. If a person performs great on the same level, receives a market salary, and is satisfied with his/her work, that person should not be forced to jump above his/her head. The manager monitors the mood and gives opportunities, but does not force.
Conclusions
An engineering manager is needed to subtly understand his/her own team. What to provide an employee with, in order for him/her to be interested and motivated, what are his/her professional and salary expectations, and how it correlates with the work of the company. It is impossible to simply take and steadily expand the six-month increase in all salaries by 10%. This should be in sync with the value that a person brings to the company.
Maybe this long story has some tone of ‘perfectness’ for you. Like, the employer will not increase the salary if the employee does not come and ask for it. This is business inefficient!
In fact, businesses are always looking for ways to optimize costs. However, a timely and appropriate increase of rates is part of such optimization. My belief is simple: professional relationships should be mutually beneficial, whether with clients or employees. Otherwise, everything ends up quickly and nasty. To follow the win-win relationship is the task of the manager.
Original article on
