The meeting was held as part of the “Engineer walks into a bar” series, where engineers from different IT companies talk about professional non-engineering topics. A series of events was organized by engineers from the Miro company , with the support of the Dolgushev and Storozhilov DevRel-bureau .
The second meetup of the series will take place on August 20. The topic is toxicity in teams, companies and the industry. Speakers - engineers and technical leads from Miro, SEMrush, Parma TG, Xsolla. Registration is already open .
Table of contents:
- The specifics of the company and the current system of professional development of engineers
- Challenges in current development systems
- How to implement a development culture at the start of a new team
- Hot question about money
- How do you argue for a business that employees need a percentage of their time for education and development?
- Professional development tools survey
The specifics of the company and the current system of professional development of engineers
Artyom Susekov, Head of Product Software Engineering, Miro. We create a product for online collaboration of teams, an online collaborative whiteboard platform. The company employs 400 people, slightly less than half are engineers. Product development offices - in Perm and Amsterdam. The teams are cross-functional: engineers, product managers, designers and, if necessary, marketers. They use scrum, some use kanban. For planning - OKRs at the campaign level and at the individual team level.
We have grades, expectations from each are formulated in the form of specific examples of behavior (behavior patterns). This is done in order not to dwell only on formal expectations ("to do so many tasks, get such and such a certificate"). It is more important that the knowledge gained is applied in daily work, this is precisely what is shown in the specific examples that are described for each of the grades.
Standard grades: Junior, Middle, Senior, there are several steps within each grade. There are opportunities after Senior to grow into a technical specialist or become a team lead and then a direction manager.
There is a Performance Review, which we conduct twice a year. During it, you get feedback from your teammates, team leaders receive feedback from those who are direct reports for them. In addition, the employee writes self review, that is, he independently evaluates his work.
The results are summed up, after which Career Conversation is carried out: what turned out well, what turned out well, what should be emphasized in the future, what should be worked with. Then the manager helps to formulate a development plan for the next six months or a quarter.
Career onversation ( , , ), : , , .Alexander Borisov, Head of the Innopolis Technology Competence Center, X5 Retail Group. Probably, most of everyone is familiar with X5. We own the Perekrestok, Pyaterochka and Karusel chains. If three years ago we were a company that sells tomatoes, and now we are striving to become an IT company that sells tomatoes.
Most of the profit comes from our IT services. How Pyaterochka works and what prices it gives, perhaps due to the well-built logistics and management system for this large process. We have more than two thousand IT specialists in the company, there are almost 150 people in Innopolis alone.
Over the past year, all of this has begun to transform from a department format to a product team format. We've broken down services and products into microservices and sub-products, for which one team can be responsible. We now have Product Owners for each product, cross-functional teams, each of which has developers, testers, analysts and part of the functions in which people can overlap each other.
Naturally, we have one-to-one meetings, OKRs, 360 feedback. Of interest is the resource pool owner function. These are the people who are responsible for the Java, JS, Python, testing, analytics, etc. pool. Each engineer in the company has a business manager (Product Owner) who understands how much a person invests in a product and how much profit his work brings, and there is a person who is responsible for technical development in his specific competence.
We abandoned the formalization of the transition between grades like “to move from Junior plus to Middle minus, you need to do this and that”. We fear that if we give clear criteria for the transition, then people will start to approach this too formally. But the formality is harmful here, because in each team everything can be very individual: one and the same person can take on more responsibility and due to this develop, or be pumped in a narrow segment of technologies that are specific to us, and due to this become more valuable to the business.
For Senior positions, knowledge diffusion is an important prerequisite for growth. You are not a Senior in a vacuum, you share your experience with the team and pull the rest with you.
Sergey Averyanov, CTO, Funbox. We have been developing software for the Big Three operators for over 10 years. At the moment, we have about two hundred developers of various profiles and a fairly large number of technical specialists in technical support.
On the one hand, we do not have a single product that the whole team is engaged in, and on the other hand, there is no large flow of projects and tasks as in outsourcing. This is where our specific professional development of engineers grows. We deliberately abandoned formal grading systems: perhaps this is what the management and the employees themselves would like, but this is an extremely inflexible system that tries to style everyone with the same brush, which is not always possible in practice. Instead, we use fairly standard things: periodic assessment of the employee's progress and one-on-one conversations. We have the opportunity to objectively assess the contribution of each by Task Tracker. All this taken together gives us an understanding of the level of each of the engineers.
On the other hand, one of our main goals is to make each person understand how and where he can develop. We try to take into account the fact that all people are different: someone is interested in working as technical experts, minimally communicating with people and not diving into administrative things; someone wants to communicate, work with people, participate in the development of colleagues. All this is normal, all development options are possible.
We are trying to build a system that allows us to raise the level of engineers and give them clear guidance on what the business wants from them and where they can go next. We also pay great attention to internal growth. I and the whole team believe that the best specialist is the specialist we raised within the team. Therefore, we are actively investing in internal development, in meetups, internal and external conferences. This is also one of the main goals - the full and high-quality development of all our engineers.
An abstract development department should not be involved in employee development. This is one of the responsibilities of the line manager.
This approach gives a plus to us and the employees themselves. On the one hand, we have a constant organic growth among the staff. On the other hand, we can make senior juniors and team leaders out of former juniors, and the employee himself sees that his immediate supervisor is the one who was a junior on this project four years ago, which means that before cooperation now the same opportunities and understandable steps for growth.
Mikhail Mazein, Engineering Lead, ManyChat.We are developing a SaaS marketing platform that allows you to arrange communications between businesses and their customers. The company is actively growing: three years ago there were 15 people in the team, now there are more than 120 of us. In the first stages, we worked with classic functional teams: backend, frontend, testing, design teams. Each team had a team leader who was responsible for sprint planning and task decomposition.
In the process of growing, we realized that this was preventing us from moving at the desired speed and reformatted the work into cross-functional teams. Now we have nine such cross-functional teams, there are no team leads, as the teams turned out to be self-organized and can be responsible for the way they work.
To synchronize functional things, we develop common approaches so that development does not turn into anarchy. This is necessary, for example, when backend developers are distributed across different teams, but work with one project, with one codebase, and commit code there. We organize functional communities to address these issues. Over time, informal leaders appear in communities who drive processes and communications. The result is a flat structure that does not limit the developer's role to the role of an engineer who only writes code, but allows you to do various things that are useful to the company and at the same time interesting to the person himself.
Since we abandoned the role of team lead, we needed a process that allows us to clearly and transparently build growth tracks for engineers. For this, we use a mentoring system: each employee has a mentor who is responsible for his growth and development within the company.
You can't just walk up to a random person and say, "Come on, be a mentor." First, several factors must be gathered: the desire of the person himself; high level of trust in the team to the person; trust from the company itself and from the management. One of the tasks of a mentor is to raise new mentors. It turns out such budding, from mentor to mentor.
We distinguish three main vectors of development:
- The first big track is a deeper work in the product team for product development, with a deeper understanding of business values, metrics.
- – , , .
- – , .
We also tried to make a grading system: we cannot yet formally describe all grades, so the system is built at the level of a person's contribution, the level of the team, the level of the entire company. We have described expectations at each level, what area of responsibility or area of influence we expect from a person, with understandable examples. The mentor, on the other hand, can tell a person what skills need to be pumped in order to come to the desired point.
Anton Grishin, Head of Development, MadRobots. At first glance, our company is an e-commerce that deals with gadgets, but in general we are engaged in distribution in Russia and the development of brands of cool things.
Our team has gathered relatively recently, so we still don't have the headache associated with the development of engineers within the company. Before Madrobots, I worked in outsourcing for 6 years, three of which were directly in charge of production at the agency, and I would like to tell you more about this experience.
In outsourcing, our pain was a large flow of projects and staff turnover, in outsourcing this is always the case. We decided that we needed to somehow overcome this and began to invest in the development of employees.
Yes, we had a grading system, once every six months a person received feedback from a technical manager, building his own path with him for the next six months.
, . , . , , , .
Subsequently, we had another pain. In the stream of projects, of which there were often quite a few, people lost focus on personal development. This happened not because they did not have enough time, but because they were tired of the number of tasks that they had to jump on. We introduced the practice of one-to-one meetings, once a month, which were aimed at talking with a person and reminding them that you have a development plan and it really should be adhered to. If you need some time for this, and you should be freed from the routine or constant off-site, let's discuss it, because your checkpoint is approaching and you need to do something about it. That helped. As a rule, this was done by the PMs of the teams, because who, if not them, knew better in planning resources for the future.
Challenges in current development systems
Artem Susekov, Miro. It's difficult to get the grading system balanced right away, so we move in iterations. For example, the first version of the team lead's track turned out to be overloaded: too high expectations, a universal super soldier, which is hardly possible in life.
We are currently trying to simplify the threshold for entering the team lead role so that it is easier for people to switch from a purely engineering branch to a manager branch. I don’t want to overestimate the bar, we need an opportunity to move smoothly into this new field of activity.
Another difficulty is the overly formal approach to the process. For example, "I did 8 out of 10 points in the plan, which means I meet expectations and can move to the next level." We don't want to turn all this into a checklist that you just need to close to move to the next level, like in a game.
I would like people to be able to think about the prospects on the basis of the plan, to think on their own about areas of interest to them, that is, so that they work with this as a strategy, and not as a list of formal tasks.
Alexander Borisov, X5 Retail Group. People often do not understand exactly how to grow in a company, because there are no clear algorithms. At the same time, people who can really already be promoted find things in which they can and should grow, those things that can be taken upon themselves and made better. But it so happens that there is a need to “just grow”. But it’s probably impossible to grow in the company just like that, because you want to grow.
You grow only when you take on more responsibility, take on new projects.
Sergey Averyanov, Funbox . Since we have been working for many years, we have had many problems and challenges. One of the first is to understand who we want to work with, whom we want to develop. As a result, we came to the conclusion that we want to work with people who know how to do something well, and it doesn't really matter on what. We willingly take specialists from any stack who are ready to use what we use. This turned out to be a fairly successful practice: it is always pleasant and convenient to develop people who already have competence in a related subject area. The knowledge gap they have is not a fatal flaw, but a new motivation for a person, the study of a new field of activity.
The second challenge is to understand how engineers in the company can grow. For development, you need to create comfortable working conditions: a normal office, understandable, simple, but strict procedures and work regulations, compliance with the Labor Code, a dislike for overwork. All this gives a person confidence that he can increase his level without hassle, without rushwork. They will show him, tell him, help him.
You can shout at the potatoes as much as you like: “Potatoes, grow! Tomatoes, come on! ”- but they won't grow from this. They need good soil and watering.
The final challenge is that not all people want to grow where we want them to grow. It happens that a strong specialist under no circumstances wants to deal with the administrative burden and work with younger colleagues. Here the question is not in formal things, not in salary, but simply in what a person has an interest and inclination for. That is why in all engineers we value passionarity, the ability to take a complex task and carry it through a multi-step process from start to finish. As a rule, any engineer who is capable of this is interesting and pleasant to us. But, as I said, at the same time we always leave the opportunity for a person to become a technical expert without plunging into administrative and management functions.
Mikhail Mazein, ManyChat... It is hard enough to formalize the requirements for grades, and we also did not try to formalize them rigidly, focused on examples of expectations of what we would like to see from an engineer at different stages of development. All this was wrapped up in a specific impact that people bring to processes at the team or company level.
This creates difficulties. On the one hand, we do not limit people in growth, a blank canvas appears in front of them, on which they can draw their development track. But drawing a new picture on a blank sheet of paper is much more difficult than moving along the beaten path. We solve this problem by mentoring. Mentors help to build tracks based on the desires of people and synchronizing it with the needs of the company. We are also trying to develop the problem search mindset so that engineers catch problems in processes and try to initiate their solution themselves. In this, again, mentors help.
Anton Grishin, MadRobots.There are people for whom growth is their own need, and there are people who grow because it is so established around and for this the conditions have been created. But they all periodically have a question - what for? Personal motivation for learning new things, for development is lost, because this may not be applicable in current realities or with current colleagues.
As one of the solutions, we held internal meetups, but not as a hobby group, but as an internal conference, with a real preparation of a new topic. A positive story emerged from this, the guys began to understand among themselves that if, for example, frontends can do something new, then we, designers and designers, can rethink our approaches and try new tools. It turns out that each other's natural motivation is to try to do something new together.
Pain always causes the personal approach of each individual person to their own development.
How to implement a development culture at the start of a new team
Sergey Averyanov, FunBox: The very fact of the company's growth helped us. When there are not many engineers, they all cook together, they all know each other and do about the same type of task. And as soon as different types of projects and roles in them begin to line up, then all people become endowed with different powers. Someone does tasks, someone is engaged in deployments, clusters, someone is involved in product design.
It is important for us that each team member understands what he needs to upgrade in order to go from a developer to a higher-level developer or team lead.
, 125 , , , , .
Internal meetups are very useful. When a company has many teams and several products, people each cook in their own sauce, and at meetups they talk, tell what cool things they do, exchange knowledge. This does not generate competition between teams, but the pursuit of excellence.
Artem Susekov, Miro: At one stage of the team's growth, various guilds that are formed around technologies help well: backend, frontend, QA. In guilds, knowledge is exchanged between different teams.
Internal events also help: meetups, public Sprint Reviews, where teams share a common context, talk about results. It is important here to help engineers prepare for such performances.
Alexander Borisov, X5 Retail Group:You cannot hope that you will say that meetups are needed, and people begin to organize themselves. They also need to be dealt with. In the case of our scale, it makes sense to single out responsible people who organize it. Teams often have cool things inside, but they cook inside themselves, they just don't have enough time to organize a meetup and share their best practices. It seems that we would have taken half an hour, gathered in a meeting room, and spent, but no. There are some nuances.
Mikhail Mazein, ManyChat: A well-structured onboarding process for new people allows us to convey to them the general principles and approaches, to correctly form a picture of the team and the project. So the culture with the arrival of new people will accumulate and be passed on.
Hot question about money
A question from a viewer: “You are not touching on the financial soundness of the organization. How is the share of the company's expenses determined for the employee to read books during working hours? The second is an example, let the solution of a problem take 80 hours for a developer who has already solved such a problem, and 150 hours will take the solution of the same problem for a developer unfamiliar with the context, but at the same time he will grow up and pump. The question is who will pay the difference of 70 hours spent on development. "
Alexander Borisov, X5 Retail Group:In our case, there is no customer. We began to actively build up an internal team instead of continuing to outsource some things, because we understand that competence is very expensive for us and results in final costs, in increasing the marginality of the business, of a particular Pyaterochka near your home. It is an investment for the future.
But if a person, instead of doing a task for three hours for 150 hours, went into reading a book, then the question will arise just from the owner of the product or from the owner of the resource pool. If this is an understandable investment in the fact that a person has grown, then, again, at the level of these two people, this is easily solved. For example, a plan for a sprint, respectively, inside it we laid down something that will need to be read, and we fit into it, this is a normal story.
Artem Susekov, Miro:There is an agreement at the company level that we help engineers develop through courses and workshops, which are held within working hours. That is, the company pays for it, it is an investment in each team member, because we believe that this kind of investment will help the whole team move faster in the future.
The specific time reserved for the engineer for the sprint education is discussed at the specific team level. It is important here that there are no distortions in the other direction, that we only study all the time during the sprint and do nothing else.
Sergey Averyanov, FunBox:I think that the question about 80 and 150 hours is more acute for outsourcing, when you can ask - why should an inexperienced developer do 150 hours for me, as a customer, if an experienced developer did the same for me over 80? How outsourcing solves this, I cannot say, because we are not outsourcing. Within the framework of a product company, this is solved by the fact that the budget is consolidated, and labor costs for development are expressed in profit due to the fact that a team member raises his level, starts to work better, faster.
About reading books during working hours. We have a practice that the need to learn something is a completely natural step in working on a problem. We do not throw the developer into a maelstrom, setting tasks like: "Read a book" or "study a technology that has no ultimate goal." It should not be such that a person sits and thinks - have I already studied the technology or do I need to study more? A task out of context, out of a goal leads to procrastination, to the fact that a person loses self-confidence and does not know when to do something.
Researching and reading literature, studying anything should be part of the task, but there should be an end tangible goal for which this study can be applied.
Anton Grishin, MadRobots: I am from the world where every hour someone earned, and someone lost money. As a rule, the customer is honestly told: “We will not take any more money from you, but we will do the task longer. The company, his employer, pays anyway for the development of an engineer. The customer simply waits a little longer, but in the future he understands that now not one, but two developers are engaged in the development of his product, everything is solved faster, the scale of implementation is increasing.
In studios and agencies, where processes are normally built, the developer will never be put on a project that objectively does not pull him, because he will bring more losses to the company than he will earn on development.
Alexander Borisov, X5 Retail Group:Besides my work at X5, I have my own small outsourcing studio. I understand its economy very well. We set 80 paid hours, but we understood that it was 150, and the number of paid hours and the development time, they very often differed. We always took some kind of stock, and we simply paid for this stock out of our own money. If somewhere there is some kind of force majeure, it means that it is paid from their own money.
Mikhail Mazein, ManyChat: Product development, where we do not have an external customer, greatly unties our hands in this regard. In general, we do not track the performance of each individual person, we measure the performance of the team.
Each team has its own capacity and speed, they can vary greatly, but in general, we focus on the performance of the entire team as a whole. How much free time a particular engineer has in the current sprint is not very important for us, as a company, this time always remains for training, and from sprint to sprint it, in principle, differs for each engineer. Somewhere in the sprint, there will be more load on the frontend, in the next sprint there will be more load on the backend, and this whole story will level out in the long term.
If we talk about assessing the performance of each individual person, the team itself is responsible for this, it is like a self-regulating structure. There are situations when feedback comes, for example, from the mentor of this person, that something is wrong with the performance, or from his peers from the functional community.
, ?
, Miro: , , . , , … , .
Sergey Averyanov, FunBox: I think that there may be companies that are focused on fixed-level specialists, they always have the same job with the same qualifications, they don't want to raise anyone. This is solved by the fact that there is a large turnover, and employees who could grow up find new jobs. Either we invest in the development of employees and the expansion of the company, or we have a turnover.
Artem Susekov, Miro: This can already be calculated, if we are talking about turnover, we will stick to this metric, if about money, right? The cost of attracting each new person, how much time is spent on recruiters, how much we spend on onboarding and how much we then, when the person leaves, we close the vacancy again. All this can be counted in money.
Sergey Averyanov, FunBox:By the way, an interesting indicator that is even useful for oneself to look at is the median period of work in the company. It allows us to estimate turnover, that is, how many people work in our median. When you see that the median is large and on the edges of this distribution there are people who have worked for eight to ten years, have not burned out, they are doing well and everyone is happy with each other, it makes me happy.
Anton Grishin, MadRobots: It seems to me that now the business does not need to explain all this, it is obvious that the need for self-development is inherent in people who create intellectual products. Therefore, I cannot even think of examples where specialists of the same level are needed, because the very technologies that we use dictate to us that we need to develop.
Mishanya Storozhilov, DevRel Bureau:It seems to me that this is not only about people with fixed performance and fixed technologies. I think this story is also about big refactoring, big technical debt. We work with companies that understand the need to develop engineers, but the question of justifying the cost of education and development always comes up.
Sergey Averyanov, FunBox:Here the word "refactoring" sounded, and the attitude to it can be interesting. Many people mistakenly think, especially non-technical specialists, that these are some strange gestures of dudes in sweaters who do nothing and spend money. The problem here is precisely in communication, that is, the manager must understand that the refactoring that did not happen today is the increased development time tomorrow. Today we will save some man-hours, and tomorrow we will spend them.
We have agreed internally that the team leader has the right to say that a necessary condition for completing the task is to carry out refactoring, without him we get such nonsense that it is impossible to work with.
Naturally, this is ultimately a matter of agreement, but we do not consider refactoring as a side activity and wasting resources, but as part of the workflow.
Artem Susekov, Miro: If we talk about product development, agreements are important. For example, the Product manager determines priorities based on scoring, and the team or the voice of the team, tech lead or team lead, determines exactly how to do it. Product says what's most important now, the engineer says how we're going to do it.
Refactoring is a natural process. Refactoring today will cost us much cheaper than refactoring in a quarter. It's like with a loan - if you don't pay, then next time you have to pay more.
Alexander Borisov, X5 Retail Group: There is a term "technical debt", and just at the stage of communication between the team and the product, we understand that if we are not doing this now, this is a technical debt. Accordingly, the technical debt through the sprint will be more, in six months it will be even more and you will have to pay with this percentage. In fact, as with a regular loan, in exactly the same way the team bargains with the product, if you want it either faster or humanly. If it's faster, then someday you will have to pay much more. As with a loan.
Mishanya Storozhilov, DevRel-bureau: Either this debt simply turns into a "technical mortgage".
We brought together five engineers, they talked for only an hour and a half and have already started talking about refactoring.
* * * The
second meetup of the series will take place on August 20 . The topic is toxicity in teams, companies and the industry. Speakers - engineers and technical leads from Miro, SEMrush, Parma TG, Xsolla.
Registration is open .