How to change teams without leaving the company. Culture of horizontal mobility in Kontur
My name is Nastya Mironova, I am a development manager at Kontur and for about two years I have been leading a team of rangers – these are developers without their own product, such mobile engineers. The team appeared at the end of 2020, and during this time we have been constantly researching how we can help the company’s projects, how to do it even better, and how to raise or find guys who are always ready for challenges.
We don’t think alone – the company has developed mechanisms and practices for horizontal mobility that help in transitions between products, teams and even roles.
I’ll tell you about this in an article with examples from colleagues.
Why horizontal mobility is needed
This is a way for the company to find the best team for everyone. One where it will bring maximum benefit. This helps retain great specialists and develop them. Our developers can go to another team to learn a new technology, and then return to their previous product and implement it there. This is the ability to see the right person at the right time and in the right place.
For employees, mobility is the opportunity to not be tied to one product. And in different formats, be useful in other teams and products of the company, change the context and expand competencies, mastering new technologies. In Kontur, transition processes are structured in such a way that if an employee decides to change teams within the company, his colleagues and manager will not be offended. The employee will be able to calmly transfer all matters, finish tasks and go look for new challenges in other products.
The level of immersion in new products and the duration of work in a new team depends on the format of the transitions. In one case, you can completely move to another team, in another, you can go on internships in 3-4 different products at once, and in a third, you can constantly change teams and get involved in specific tasks. All this is optional.
Changing a team is like changing a job
Sometimes an employee may simply want to change stack or role. For this, we have internal training and a mentoring system, so changing the context is not so difficult. For example, a tester can learn React and move to the frontend. And the front-end can master high loads and move to the back-end.
My colleague from the Bureau (I’ll tell you about him later), Vladimir Parshuta, changed his role from tester to development manager, but returned to his previous role. What he says about his experience:
“Since joining Kontur, I have worked as a tester in the Crypto infrastructure team for three years. I also managed a cluster of testers of 10 people, participated in their assessment, development, recruited and organized meetups. I always liked participating in activities and interacting with people, and my colleagues noticed this too. At some point, the managers offered to try themselves as a development manager. Then I also thought about it, and I saw a great challenge for myself in changing my role. I had an interview with the head of the development managers function zone and officially changed my role. The composition of the new team was unusual: 4 backenders and a development manager, that is, me. At first it was difficult to understand my tasks, but I had a mentor who helped me cope with difficulties. Also, before starting in a new role, I took an internal course from Kontur – a quick start for a development manager. He helped me gain a basic understanding of my area of responsibility. There were also difficulties in the new role – at first I didn’t understand how to motivate my colleagues. There was also a lot of communication – constant meetings with integrators, synchronous meetings – as a result, more than half of the working time began to be spent on negotiations. Because of this, after a year in a new role, I decided to return to testing, because I really missed working with my hands. Plus, I realized that as a tester I can also influence the development of the product and cover my needs for increasing my area of responsibility.” |
Bootcamp – an ecosystem for internal internships in other teams
Bootcamp is an adaptation for backenders, frontenders, testers and system analysts. Usually the term bootcamp is used only to describe onboarding, but we look at it a little more broadly: we also have it for experienced employees.
For newcomers, this is a cool way to immerse themselves in the context: when an engineer gets a job at Kontur, he ends up in a bootcamp. And for several weeks or months (depending on the role) he trains and trains in one or 2-3 teams before choosing one for permanent work.
But the bootcamp also works for those who have been in Kontur for a long time. It gives them two opportunities: find a new team within the company and go on an internship in another product for 1–2 months for the sake of experience and expanding the engineering context. For example, if you want to acquire expertise in Apache Cassandra, go to Diadoc, an electronic document management service with RPS. There, at work, he will be able to learn how his colleagues prepare it, and then bring the expertise to his team.
What are the benefits of a bootcamp for experienced employees:
It’s easier to find new tasks with challenges if you’re bored in your current project. Bootcamp helps make the search for such problems much smoother and safer. There is a manager inside the bootcamp who will help you find a team and discuss potential tasks in advance.
It is possible to upgrade soft skills. In During internships at the bootcamp, you can meet colleagues who have expertise in specific technologies. And then you can just chat over coffee about solving work problems using these technologies and discover something new.
You can choose the most suitable team. Kontur has 11 thousand employees, approximately 30% of them are in development. Some teams prefer to work from one office, while other teams prefer to be distributed. If something goes wrong, both the employee and the team have the right to end the internship early. The team will continue to search for the right person, and the employee will have the opportunity to go on to another internship.
Ranger Team – for those who want to constantly switch between projects
There is a team of engineers in Kontur who are ready to come and solve an urgent problem for which there are currently no resources in the project. These are the rangers. The guys do not constantly work on one product, but solve problems of creating MVPs for startups, conduct audits, start test automation, and solve infrastructure problems. And not only.
The rangers are a concentration of Kontorovites with a wide variety of competencies. Due to the fact that the guys are constantly working on different projects, they have a great eye for design patterns and the use of technology in the company.
I came to Rangers from the product team and I’m interested in building processes for guys who don’t have a permanent product. For example, I organized transparent planning of resources and backlog, I help find and adapt new people to the team.
There are several nuances to Ranger workflows that are not always easy to work with. First, there is often a high level of uncertainty. Secondly, each time you have to adapt to the processes in a new team and establish communication with colleagues.
Dmitry Zverev has been working at Kontur for 17 years, during which time he managed to change about 5 teams. And recently I realized that I was tired of working in a constant food context and decided to try something new – so I moved to the ranger team: “Joining the Rangers was a challenge for me. At the time of the transition, I understood that I did not want to join a product team with a fixed subject area. On the other hand, becoming a ranger was scary, since I doubted that I could cope with the rapid change of task contexts. But there was also an understanding that rangers are a way to quickly improve both in technology and soft skills As a ranger, he gradually began to use different products and master new technologies. For example, in the first project we were faced with the need to quickly implement an admin panel for managers. We decided to use Blazor, which had just been released at that time. It was a completely new experience for me, and it was motivating. Everything worked out quickly, and we didn’t have to involve a front-end developer for this task. Now I have grown to become a team leader of C# rangers. Here, team leadership is different from what it is in product teams. In a classic team, the team lead keeps in mind only the context for his product, but in the Rangers, the team lead has his own task, plus the context for the tasks of his subteam. The “Rangers” team lead onboards newcomers, trains engineers: helps with assessment and development, selects tasks with the manager, and also participates in building processes in the team.” |
When engineers can develop an eye for technology and be mobile within the company, that’s great. And the opportunity to intern on other products or move into the Ranger team altogether helps retain strong employees, strengthens connections between teams, and gives engineers more flexibility.
Late last year, the Rangers, along with other roles, merged into the Development Bureau.
Development Bureau – to strengthen and boost teams
Bureaus are specialists from the Contour development department who join the team to solve a task or problem for a certain period of time. These are not necessarily developers. There are currently 6 teams in the Bureau:
Rangers
Design Bureau
UX laboratory
Technical Writers
Testing Bureau
Group of analysts
We select tasks by priority: a large Contour product or startups that we launch and try to carry out immediately through the Bureau may come for reinforcement. But either one engineer from the Bureau or a team can go there and there.
It's not easy at the Bureau, but it's interesting. We understand that not everyone will be able to work in this format of constant switching between teams and projects. Therefore, first of all, the Development Bureau is a team. We have our own events, activities, and internal technical processes. And each employee can go and see how processes are built in different teams and at the same time bring something of their own.
When you work on one product, it can get boring. At some point you will want to try new technologies or take on other tasks in general. Mobility practices help a person change their work and company experience for the better. At the same time, it is not necessary to enter the market, but to change your activities already in a well-established company and a context that you know. They will accommodate you and even help you change your role, which is generally quite difficult and scary when you are not a very competent beginner in something.
There is something about love for people and your business in this approach. But at the same time, mobility is not a panacea for meeting the company’s needs, professional growth of employees and their well-being. Moreover, to build and maintain such a system requires a lot of resources. Therefore, before investing in it, it is worth assessing the scale of the work and thoroughly validating the goals.
