How "Flant" helps newcomers
In the previous article, we talked about hiring in our company, but this is still half the problem — indeed, it is equally important and competent to introduce a new employee in the course of what is happening! I will share our experience in this area in the new material.
If everything has grown together - the employee goes to work. We give him corporate equipment - DevOps engineers, for example, a working laptop and a headset that has been tested for quality and compatibility with the right hardware. All this is sent home using the delivery service.
The necessary software is installed on the laptop (including integration with internal services) and mandatory security measures are provided (for example, data encryption). All engineers have Ubuntu. Sources of integration with our services are open to employees.
We generally love open source software : the source code of all internal projects is available to any engineer. And on any of them you can see, for example, the following:
By clicking on the commit number, you go to it in the internal GitLab. Don't like something? Want to fix it? Read the code, edit, send merge request - we are engineers, after all!
Note : Our love for Open Source, however, extends even further. We opened a number of our developments to the community on GitHub , and before using it, from about 2009, we did it with the help of other resources. And we continue to open as much as possible (hint: we have another project on the way, the sources of which are already publicly available ... follow the announcements on our blog!). In addition, we contribute to projects close to us (like Helm and GitLab ) and sometimes indulge .
“Flant” works according to flexible methodologies, but instead of holivars about the correctness of the wording in the Agile manifest, we implement methodologies in code. Internal services for tracking tasks, time, projects and other things are well integrated with each other and deprive us of a huge amount of headaches. How?
For example, we have our own system of accounting "cards" and time per day, made using two web services: Nixon and Ford (by the names of American presidents).
Why not Trello? Because our Nixon and Ford, among other things, are able to:
Simply put - these services are maximally optimized for our specific requests, which change over time, as well as complemented by extensive feedback from direct users (engineers).
To handle the incidents, the engineers on duty have Polk (yes, there was such a president ) - he, too, is integrated with everything you can. Quick task creation (if the incident is not urgent and requires a lot of work), collecting incoming alerts from several types of monitoring, direct communication with clients via Slackbot and many other necessary functions ... We don’t imagine effective work otherwise.
Or, for example, project management. There is a Bush service that remembers everything about clients, their projects, employees and teams. Are you creating a project in the internal GitLab? Just beat the necessary information in Bush - he will create all the settings, provide all access and get a repository.
First of all, the newcomer takes the course of a young fighter in a specialized team engaged in the dissemination of knowledge. We teach him the necessary minimum, with which he can immediately go to his team, having an understanding of what is happening and understand the specifics of client projects. This takes the first 3-4 days, after which the engineer, under the sensitive attention of the team leader and engineers of the knowledge dissemination team, begins to sink into real combat missions.
In order for the novice to orient himself safely in the stream of new knowledge, we formulate for him a list of achievements - “achivok”. The first time is very scary and cool at the same time, and we make a lot of effort to “coolly” prevail.
Later, when the engineer passes the trial period (by default it is 3 months, but sometimes less depending on various criteria - see note below), the list of achievements per quarter will be formed individually, but at first we seize the initiative and give it key points like:
Note : By the way, one of the additional incentives for completing a trial period (during its length, employees receive a fix) are the very bonuses that come in our payment system immediately after it.
Key tasks we gradually wrap up in internal courses and guides in the knowledge base.
Such achievements help the team to choose the right performer for the tasks. There is always a temptation to throw tasks on those who will deal with them quickly, ignoring those who need to improve skills. We are successfully fighting this.
The key point to which the novice is keen to come is to go on duty in his team. Each team engineer in turn spends one of his working days on duty on team projects: promptly answering customer questions and responding to accidents. Of course, he does not remain alone: the simplest questions close the first and second support lines, the more complex ones go to the more experienced teams. And the team itself is always in the wings, the duty officer, if necessary, can call the right engineers for help.
This helps all team members to keep abreast of all projects, and also gives them a real picture of the problems that can be eliminated in the bud, and because of this start to get more money.
We strive to achieve results with the help of our brains, and not monstrous investments of effort and time. Therefore, the more projects a team takes without loss of efficiency, the more money employees receive. We have developed a rather clever and rare payment system, which is surprising to some. I'll try to explain.
We lived all our lives on the hourly basis, but rested on the fact that the people are gradually burning out and not solving the problems systematically. Over time, we switched to a new approach, which implies a sum of: a flat rate + some part depending on the hours spent, + bonuses for the effectiveness of the team. The transition demanded courage from engineers, but as a result everyone was satisfied, they began to receive a large salary and it was better to get enough sleep.
The team has received money that the team received in excess of the minimum required to cover salaries, based on agreements with its team. Most often, the hulled bear carcass is divided on the basis of hours spent and the level of wages.
To understand the general level: the salary of our engineer in the regions - from about 90 to 150 thousand rubles per month (on hand). Of course, this is “the average temperature in a hospital,” because it is always an area of personal agreement and a combination of many different factors.
From the first day, all the employees of our company work “in white”, officially, under an indefinite labor contract and in accordance with the Labor Code of the Russian Federation. A completely white salary (paid in two parts on fixed dates of the month) implies that taxes are paid on it and contributions made to all necessary funds. As a result, the entire income of our employees is displayed in the 2NDFL certificates and there are no problems when applying for loans.
In addition, "Flant", of course, pays the full amount of sick leave and leave. By the way, we have two types of vacations: annual (28 calendar days) and additional, three more paid days per year. Time off or days off without pay is also possible, but it is important to warn the team, coordinate the issue with the team leader and make sure that the absence of an employee does not lead to critical consequences. Understanding that there are cases of urgent need, we try to find ways to release an employee in such situations, despite the legal restrictions (the Labor Code requires warning of their leave and time off in advance).
Let this is not quite the topic of the article, I can not ignore the fact that growth in the company is not an empty marketing campaign for us. We really strive to provide all opportunities for long-term relationships with employees and participate in their development (in accordance with predispositions and preferences). Moreover, thanks to the existing scale of the company and the diversity of clients and related activities (including our internal processes), we really have something to offer.
Of course, there is a “default path” L1 → L2 → DevOps engineer (including performing L3 functions) → lead engineer, team leader, PM ... But more complex moves happen, which depend not only on human abilities, but also on actual ones company needs. So, for example, once we had the position of “director of service”, to which one of the on-duty (L1 / L2) engineers had grown, and it suffices to recall that we have special teams, such as R & D.
If readers have an interest (write in the comments!) - we will tell you about the stories of growth and development in the company that really happened with our employees and appear now.
Adaptation processes have become more relevant than ever as the company grows. In our case, a turning point - the stage at which we felt that a qualitative shift in working with new engineers was critical for business - occurred in the area of 50 employees. However, in many respects this is only the beginning of the path - our approach to adaptation is actively developing right now. We are building the processes of internal recruitment and exchange of experience, we are developing tools for everyday work and developing a knowledge base. However, this is a completely different story ...
I express my gratitude to my colleagues: HR-director Anna and shurup - for their help in preparing both parts of this article. We are happy to share our experience in other issues related to this “internal kitchen” of our company, according to your requests.
Read also in our blog:
Getting to work and the first ~ three months
If everything has grown together - the employee goes to work. We give him corporate equipment - DevOps engineers, for example, a working laptop and a headset that has been tested for quality and compatibility with the right hardware. All this is sent home using the delivery service.
The necessary software is installed on the laptop (including integration with internal services) and mandatory security measures are provided (for example, data encryption). All engineers have Ubuntu. Sources of integration with our services are open to employees.
We generally love open source software : the source code of all internal projects is available to any engineer. And on any of them you can see, for example, the following:
By clicking on the commit number, you go to it in the internal GitLab. Don't like something? Want to fix it? Read the code, edit, send merge request - we are engineers, after all!
Note : Our love for Open Source, however, extends even further. We opened a number of our developments to the community on GitHub , and before using it, from about 2009, we did it with the help of other resources. And we continue to open as much as possible (hint: we have another project on the way, the sources of which are already publicly available ... follow the announcements on our blog!). In addition, we contribute to projects close to us (like Helm and GitLab ) and sometimes indulge .
Flexible methodologies like code
“Flant” works according to flexible methodologies, but instead of holivars about the correctness of the wording in the Agile manifest, we implement methodologies in code. Internal services for tracking tasks, time, projects and other things are well integrated with each other and deprive us of a huge amount of headaches. How?
For example, we have our own system of accounting "cards" and time per day, made using two web services: Nixon and Ford (by the names of American presidents).
Why not Trello? Because our Nixon and Ford, among other things, are able to:
- understand that a person can solve problems in different teams during the day (and he needs to do it comfortably!);
- with one click, create tasks from a card in Redmine, as well as integrate with GitLab and GitHub;
- divide cards by priorities, postpone them for a date or backlog;
- organize simple workflow with confirmation;
- filter, search and provide a lot of relevant hotkey.
Simply put - these services are maximally optimized for our specific requests, which change over time, as well as complemented by extensive feedback from direct users (engineers).
To handle the incidents, the engineers on duty have Polk (yes, there was such a president ) - he, too, is integrated with everything you can. Quick task creation (if the incident is not urgent and requires a lot of work), collecting incoming alerts from several types of monitoring, direct communication with clients via Slackbot and many other necessary functions ... We don’t imagine effective work otherwise.
Or, for example, project management. There is a Bush service that remembers everything about clients, their projects, employees and teams. Are you creating a project in the internal GitLab? Just beat the necessary information in Bush - he will create all the settings, provide all access and get a repository.
Adaptation
First of all, the newcomer takes the course of a young fighter in a specialized team engaged in the dissemination of knowledge. We teach him the necessary minimum, with which he can immediately go to his team, having an understanding of what is happening and understand the specifics of client projects. This takes the first 3-4 days, after which the engineer, under the sensitive attention of the team leader and engineers of the knowledge dissemination team, begins to sink into real combat missions.
In order for the novice to orient himself safely in the stream of new knowledge, we formulate for him a list of achievements - “achivok”. The first time is very scary and cool at the same time, and we make a lot of effort to “coolly” prevail.
Later, when the engineer passes the trial period (by default it is 3 months, but sometimes less depending on various criteria - see note below), the list of achievements per quarter will be formed individually, but at first we seize the initiative and give it key points like:
- A do-it-yourself Kubernetes cluster. Possible occasional help from colleagues. Maximum - 2 working days.
- Fully self-deployed Ceph in Kubernetes.
- Accepted MR or created Issue in any draft documentation.
- Closed day, filled with correctly issued cards with correct timers.
- ...
Note : By the way, one of the additional incentives for completing a trial period (during its length, employees receive a fix) are the very bonuses that come in our payment system immediately after it.
Key tasks we gradually wrap up in internal courses and guides in the knowledge base.
Such achievements help the team to choose the right performer for the tasks. There is always a temptation to throw tasks on those who will deal with them quickly, ignoring those who need to improve skills. We are successfully fighting this.
The key point to which the novice is keen to come is to go on duty in his team. Each team engineer in turn spends one of his working days on duty on team projects: promptly answering customer questions and responding to accidents. Of course, he does not remain alone: the simplest questions close the first and second support lines, the more complex ones go to the more experienced teams. And the team itself is always in the wings, the duty officer, if necessary, can call the right engineers for help.
This helps all team members to keep abreast of all projects, and also gives them a real picture of the problems that can be eliminated in the bud, and because of this start to get more money.
Salary and bonuses
We strive to achieve results with the help of our brains, and not monstrous investments of effort and time. Therefore, the more projects a team takes without loss of efficiency, the more money employees receive. We have developed a rather clever and rare payment system, which is surprising to some. I'll try to explain.
We lived all our lives on the hourly basis, but rested on the fact that the people are gradually burning out and not solving the problems systematically. Over time, we switched to a new approach, which implies a sum of: a flat rate + some part depending on the hours spent, + bonuses for the effectiveness of the team. The transition demanded courage from engineers, but as a result everyone was satisfied, they began to receive a large salary and it was better to get enough sleep.
The team has received money that the team received in excess of the minimum required to cover salaries, based on agreements with its team. Most often, the hulled bear carcass is divided on the basis of hours spent and the level of wages.
To understand the general level: the salary of our engineer in the regions - from about 90 to 150 thousand rubles per month (on hand). Of course, this is “the average temperature in a hospital,” because it is always an area of personal agreement and a combination of many different factors.
From the first day, all the employees of our company work “in white”, officially, under an indefinite labor contract and in accordance with the Labor Code of the Russian Federation. A completely white salary (paid in two parts on fixed dates of the month) implies that taxes are paid on it and contributions made to all necessary funds. As a result, the entire income of our employees is displayed in the 2NDFL certificates and there are no problems when applying for loans.
In addition, "Flant", of course, pays the full amount of sick leave and leave. By the way, we have two types of vacations: annual (28 calendar days) and additional, three more paid days per year. Time off or days off without pay is also possible, but it is important to warn the team, coordinate the issue with the team leader and make sure that the absence of an employee does not lead to critical consequences. Understanding that there are cases of urgent need, we try to find ways to release an employee in such situations, despite the legal restrictions (the Labor Code requires warning of their leave and time off in advance).
Growth in the company
Let this is not quite the topic of the article, I can not ignore the fact that growth in the company is not an empty marketing campaign for us. We really strive to provide all opportunities for long-term relationships with employees and participate in their development (in accordance with predispositions and preferences). Moreover, thanks to the existing scale of the company and the diversity of clients and related activities (including our internal processes), we really have something to offer.
Of course, there is a “default path” L1 → L2 → DevOps engineer (including performing L3 functions) → lead engineer, team leader, PM ... But more complex moves happen, which depend not only on human abilities, but also on actual ones company needs. So, for example, once we had the position of “director of service”, to which one of the on-duty (L1 / L2) engineers had grown, and it suffices to recall that we have special teams, such as R & D.
If readers have an interest (write in the comments!) - we will tell you about the stories of growth and development in the company that really happened with our employees and appear now.
Instead of conclusion
Adaptation processes have become more relevant than ever as the company grows. In our case, a turning point - the stage at which we felt that a qualitative shift in working with new engineers was critical for business - occurred in the area of 50 employees. However, in many respects this is only the beginning of the path - our approach to adaptation is actively developing right now. We are building the processes of internal recruitment and exchange of experience, we are developing tools for everyday work and developing a knowledge base. However, this is a completely different story ...
PS
I express my gratitude to my colleagues: HR-director Anna and shurup - for their help in preparing both parts of this article. We are happy to share our experience in other issues related to this “internal kitchen” of our company, according to your requests.
Pps
Read also in our blog: