What do development leads do when they get together? About the experience of conducting meetings in the LeadHub format
Lack of common and understandable product logs. The company has many service teams that work with product logs in one way or another. But since the logs themselves and the points where they are taken are not standardized, working with them is a disorganized flow without the ability to reuse all the logs. There are other problems associated with this: for example, according to Russian law, we must store data on users and their interactions for at least 3 years, and storing such a huge array is expensive.
Pavel Arlanov, our head of information security, spoke about the gradual elimination of the problem.
Examples of solutions:
We agreed with the federal executive authorities on the specific composition of the data that we need to store and transfer if necessary.
We made a general conceptual diagram of the log.
We have established in teams an approach to working with logs and storage methods.
Problems with process releases. We decided to fix a number of negative factors: including the lack of versioning standards, release policy and stable environment. The leader of our mobile team Denis Sizy told us about the steps that have already been taken to achieve this.
Examples of solutions:
Implemented auxiliary tools. Set up the rollouts mechanism in ARGO, created instructions for creating a stable DEV, added a mechanism for inserting a tag into the release, which is visible in the ARGO revision.
We wrote out a release cycle plan: we detailed the tasks for each of the five days of the cycle.
Viscosity. This part of the presentation was devoted mainly to the problems of implementing new tools. It was about the difficulties with the process of moving to new tools, and the accompanying delays in deadlines, and about situations when the guys in the teams did not understand the meaning of implementing certain tools, their essence and significance. Some things have already been corrected: Vladimir Vereshchagin, Deputy CTO of Sravni, shared the interim results.
Examples of solutions:
Introduced voting on the implementation of new tools.
We have created a clear checklist for their implementation.
When introducing new tools, we started to conduct tech demos.
We set up automatic reminders for implementation deadlines.
Lack of UNIT testing culture in the company. The process of implementing UNIT tests is not standardized, the use of different approaches introduces an element of lack of control. Akhmed Akhmedov, Deputy CTO of Sravni, spoke about improvements in this area.
Examples of solutions:
Implemented a coverage assessment tool: added a library in test mode that determines code coverage in one repository of each stack.
We debugged and deployed a tool that is a report collector for all of the company's repositories.
Staff shortages and turnover. Not all leads are equally good at managing employees, including new ones. And leads often lack context for recruiting processes: for example, timely receipt of information about new vacancies. What has already been improved in this area – said Vasily Byakhov, Deputy CTO of Sravni.
Examples of solutions:
We conducted a large survey of leads, which revealed bottlenecks in employee management and began to work on them.
We increase leads' awareness of vacancies and various aspects of recruitment by strengthening their communication with HR People Partner.
All this is only a part of the topics and far from all the voiced conclusions of our retro (in addition to the finished results, plans for further development were also discussed a lot); the guys' presentations took an hour and a half in total. After that, there was an hour-long break for lunch, and we moved on to the main part of the program.
Gathering leads together – but who is a team lead?
In a practical sense, we decided to reveal the topic of our meeting as follows: to create a matrix of team leader competencies based on its results, record it in the company and use it to optimize processes. What effect did we plan to get from such a matrix?
Make the development tracks of specialists more transparent. With the help of the matrix, any developer who aspires to become a team leader will understand what skills and competencies he needs to strengthen to develop in the profession. The same applies to tech leadership: the matrix as a whole is tailored to leadership competencies in IT.
Simplify onboarding. At Sravni, we strive to grow leads ourselves, but of course, there are cases when a good lead can come from outside. The matrix will allow a new specialist to quickly get an idea of the expectations for his role and get into the process.
Creating a reserve of team leads. Indirectly, this expectation is related to the first point: to assemble a pool of potential team leads (from among developers who strive for this) to connect to new products/directions in the company.
Finally, the matrix would be useful for the leads themselves as a visual reminder of the scope for professional development, which, of course, always exists. Especially in the case of leads who combine two quite different roles: technical and managerial.
For example, in the team lead's backlog in Sravni, DIY development is about 10-20% of all tasks. The rest is people management, tasks at the intersection of development and business, research into new tools, and development of architectural solutions. In order for the team to achieve goals for metrics, and for the guys to have everything in order with motivation, it is important to give leads the skills and tools to work with the team in different areas – from communication to strategic planning.
But what should be developed as a priority? This is exactly what the team leader’s core competencies were formulated by the guys during the brainstorming session. The discussion took place using the “world café” technology. The participants were divided into several tables, each table had two leaders — a kind of “knowledge holders”, and the rest of the participants moved between the tables and supplemented, developed and adjusted the ideas of their predecessors. At the same time, of course, the specifics of the company were taken into account: the goal was not to put together a portrait of the ideal team leader in a vacuum, but to get an idea of what is important to him in a practical sense, for solving real business problems.
As a result, each table worked on two competencies – and we got a basic idea of the content of the future matrix. We identified the following: technical skills, team management, initiative, communication skills, adaptability, the ability to correctly set tasks, understanding of business, independence, immersion in external communications.
The next step is to work out a set of skills within each competency. Leads and their teams are already doing this (in addition to solving the tasks that were outlined at previous meetings and have not yet been fully completed). When our matrix is fully formed, we plan to evaluate the skills included in it in our leads – and help with their development. We will present the results at the next LeadHub meetings.
In the meantime, we suggest watching a short report video from LeadHub #8: about how the event went, literally in five minutes.
What's next?
In the case of nurturing technology leadership, it is important to understand that this is a process that cannot be contained within the framework of point meetings (even if they are held very often). At LeadHub, we essentially celebrate what has been achieved and record plans. And then there is a lot of work to do: follow agreements, distribute information among teams, take into account everything that has been discussed in solving daily tasks. Six months before the next LeadHub is the time when we need to make maximum efforts to eliminate the previously noted problems. And to what extent this will be possible and where we will move next, we will tell you in the winter – based on the ninth LeadHub meeting.
