Communities for analysts, engineers and DS – why work in them is more productive than in traditional teams

Communities for analysts, engineers and DS – why work in them is more productive than in traditional teams

The effectiveness and success of the team directly depends not only on the professionalism of the participants, but also on the way of organizing work processes. After all, if you have the best specialists in the field, but the processes at the same time are limping on both legs, then it will be as difficult to do something significant as if there were no specialists at all.

In this post, we’ll talk about how the format of communities (chapters) helps us work. To do this, we talked in detail with Mykhailo Blagovy, the leader of the data engineers chapter. Mykola Beznosov (Data Science chapter) and Artem Smirnov (Data Analytics) also helped us.

When it comes to organizing teamwork, two approaches are most often used.

The first is the format competence centers (CC). These are special divisions within the company that concentrate all knowledge in a specific area. Actually, that’s where the name comes from. As far as data engineers are concerned, it is all knowledge of data analysis and processing. And when one of the colleagues has a task that requires, say, advanced analytics, then everyone knows that you just need to go to the appropriate Central Committee, they will help you there.

But there are a number of peculiarities here. For example, if the task is not the greatest financial effect or everything is smooth with positioning, then this task is unlikely to be taken. There are bound to be more priority, monetary or lobbying projects. And even under such a scheme, situations sometimes arise when the performer and the customer do not interact directly and exchange requirements and results, which is called “over the fence”. Because the customer does not want to take responsibility for the project, and the executor is not always able to shake off from the customer a clear TOR and clarifications to it.

The second is work in product teams. The main difference from the Central Committee here is this – in the format of product teams, employees are 100% immersed in business tasks, while the product owner himself manages his team. Solving tasks in the field of telecom, such as, for example, improving the work of the call center, working with customer churn, optimizing the quality of the network and fighting fraud require being in operational communication with the owner of the business process.

In Beeline, we chose this approach – we have several dozens product teams in different divisions and with different owners. In this case, there are also disadvantages: expertise in teams is uneven, and approaches to solving the same tasks are different.

But here they come to help chapters

Why chapters, if there are product teams?

We can say that the need for a chapter structure arose because of the key shortcoming of Agile and a purely product approach — because of the difficulty of sharing knowledge between independent teams.

Just imagine – let’s say you have one big friendly department. Typical processes, typical questions. Any problems are quickly solved. If someone comes up with something useful, say improved monitoring of ML models, it can be quickly scaled up and implemented in others.

If you have many independent teams with their own tasks, then each of them will have their own problems and questions. Some are typical, and some are specific to the team. This results in each of the teams being in their own information bubble and being able to develop a bike from time to time. In such a scheme, the new team has to repeat the same path that other teams have taken (perhaps more than once).

In order to share expertise, solutions to common problems and best practices, we created chapters. In chapters, we hire and grow specialists, introduce analytics and machine learning into business processes. Of course, we are not the first to come up with such a form, but we have made a number of optimizations and our own specificity to it.

Chapter structure

A chapter is a horizontal structure. A community that unites specialists of the same profile. For example, the mission of our chapters is growth and development (both professional and career) of chapter members, accumulation and dissemination of expertise in ML, data analysis and engineering, promotion of a data-driven approach in the company. Such trade unions-2023:) Only without membership fees.

The main thing that a chapter should have is this leader. He drives the whole process. The chapter leader (a.k.a. “chapter head”) is often not even the administrative head of the staff below. He is the leader of the chapter itself as a community, but at the same time he is not included in the system of administrative or functional subordination.

There are also team leaders, their responsibility is leading activities in major product areas, hiring employees and onboarding newcomers, conducting certifications and reviews, participating in meetups, promoting a data-driven culture, and more. By the way, any other employee can participate in all this, it’s just optional for the employee, and part of the job duties for the team.

So it turns out that the team leader in the chapter is not only a team leader familiar to all, whose tasks include the organization of the production process, decomposition of tasks, work with business requirements, staging and current control of the execution of tasks. It is also an active member of the chapter, which helps with hiring data engineers for all teams, conducts certifications to assess the professional level of data engineers, develops standards and best practices, conducts internal training of employees

Tasks solved by the chapter

Telecom is just an abyss of different tasks, because the business is initially multifaceted, here is just a part:

  • forecasting demand for devices in communication salons,

  • identification of new potential points for coverage expansion,

  • network quality optimization,

  • anti-ebb, classic recommendation tasks,

  • processing customer requests in call centers,

  • video and audio analytics,

  • antifraud;

  • antispam,

  • geoanalytics,

  • prediction of network problems,

  • automation and improvement of interactions with customers and counterparties,

  • building product analytics,

  • much more.

In a number of tasks, the chapter can resemble the Central Committee. For example, when someone cannot figure out which filter or algorithm to use for a task related to the subscriber database, he comes to our chapter. Someone cannot download the necessary data – contact us. Someone trying to determine the most efficient location to install a new base station — well, you get the idea. If you want to quickly set up analytics for your product, come to us as well. We will also help you hire a data expert to join your team or find out what tools are used in the company for data processing.

What is important is that the chapter does not solve its tasks for such an employee, the chapter teaches how to solve them independently.

Much more can be done in this format, such as standardizing the approaches used. From the height of the chapter, you can look at some processes or tasks in different teams, notice that people can work differently, and help them unify the process so as not to reinvent the wheel once a month. And the chapter also helps a lot with the grading of colleagues, their training and hiring.

We have hundreds of petabytes of the data we need to work with, so we use the classic BigData stack – we write the code in Python and Scala, we store the data in Hadoop, in general, there are no surprises here. We try to keep the infrastructure closer to K8S. Of course, the work is not complete without interaction with the company’s data storage ecosystem – these are various relational and NoSQL databases, message buses and queues, APIs and file stores.

Organization of the chapter’s work

Since there are many people and they are actively coming, it is important to create a Welcome Guide and other documents for quick onboarding and immersion in the topic in a system that is convenient for everyone.

Documentation is a very important element in the work of data specialists, we try to keep it as up-to-date as possible (at least on key issues).

When it comes to being a chapter leader, it’s important to delegate. For example, you can later delegate some of the interviews to other experienced employees. The interview, by the way, is not just a recruitment of people – it is a very important stage, and the interview process should be structured as efficiently as possible. We have had cases where a candidate chose beeline over competitors during an interview, precisely because he liked the interview process (comprehensive) and the team.

Do not forget that everyone wants to work in a strong team, and the interview itself is your chance to prove to the candidate that you are one of them.

Development of chapter members

We actively organize meetups and meetings to share experience, so this saves us from the situation when someone finds himself in a bubble and does not know what his colleagues are doing.

Because one of the main tasks of the chapter is the growth and development of the employee. Everyone wants to understand how to grow from June to Middle and what exactly to do for this. Or how to become a team leader. For this purpose, we implemented the most transparent evaluation system. Each employee is evaluated according to three parameters:

  1. Hard Skills – possession of certain tools and technologies necessary for work (Scala or Python, Spark, knowledge of the ecosystem, ML or Deep Learning).

  2. Soft Skills – how active, independent, responsible a person is.

  3. Performance — for big tech, a standard metric of the format “meets expectations”, “exceeds expectations”, etc. This is about reflecting the employee’s contribution to the chapter in general.

For hard&soft skills, we have a matrix of competencies with scores from 0 to 5, and for clarity we have written expectations for each score. That is, the employee here will not have questions why he has 4 and not 5, for example.

The evaluation takes place approximately every six months (sometimes once a year). The employee undergoes a self-assessment based on these three parameters, then the chapter experts evaluate his hard skills, and the product team leaders – soft skills + performance. The final level of the employee (from Junior to Expert) is formed from the combination of these ratings.

A spoon (teaspoon) of tar – minuses of chapters

Perhaps the main disadvantage is that it is not always possible to help those who do not currently have a budget for their own team. Of course, when they come to us with such requests, we try to help with advice at the expense of our own resources. But only at first, because then in any case leadership from the product owners is necessary.

It is worth actively monitoring the matrix of competencies, because if you move away from it, the growth of the chapter by professional competencies may slow down.

And you also need to work competently with communication, because if there are a lot of people in the chapter, then you can imagine what the workers will turn into if they are not moderated.

The load factor on the chapter leader remains important — sometimes, when there are many people in the chapter (as well as tasks), it is not always possible to pay 100% attention to it purely physically.

And most importantly: a chapter is not a center of competence. It won’t help you allocate budgets or provide engineers on an hourly basis.

To whom the chapters will suit, and to whom – not

Today, Beeline is an engineering company, and its strategy stipulates that all decisions (from auditing to the call center) should become digital, and they should be made on the basis of data and their analysis. So, the chapter approach fits this quite naturally. Unfortunately, from the outside, beeline is still perceived by inertia as a classic TV, rather than an engineering company, but we are trying to fix it.

And most importantly, if you read all this and you also wanted to collect chapters, keep in mind that this format will not work everywhere. For example, if you have a small startup, this is not for you. Or, on the contrary, a large company that is accustomed to strict vertical management: it will be strange to use a horizontal management structure here.

But if you have a product approach and horizontal interactions are encouraged, look towards matrix structures and chapters. Perhaps it will significantly help you in your work. It didn’t work for us the first time either, so don’t be afraid to experiment.

After all, it is very difficult to develop without it.

Related posts