Management of a distributed team in multi-project mode (overview and video report)

On September 23-24, Saint TeamLead Conf 2019 was held in St. Petersburg. Flant took an active part in it: Igor Tsupko (our director for the unknown) held a meeting where participants understood how to find and reveal secret knowledge within the organization, and Sergey Goncharuk (project manager) made a presentation “Managing a distributed team in multi-projection. " By tradition, we publish a review of the report and its video (~ 37 minutes).

“Distributed team” and “multi-project”

Under a distributed team, different companies understand very different things - for example, a branch network or office and remote workers ... But in our case there is no office in its “real” sense.

Now we have more than 80 employees who live in more than 20 cities of Russia and beyond. Most of us see each other “live” only 2 days a year, at the “Flanta” birthday.

The rest of the time we live in Moscow, Samara, Tyumen, Nizhny Novgorod or any other city, we work with birdsong or the smell of coffee. Instead of renting a place, we invest money in something really useful. And since everyone works remotely, we do not have a division into “branches” or “castes”.

And most importantly - we hire the best, despite any boundaries! That is what "distribution" in our understanding means.

Let's now deal with multi-design, but for a start it’s important to dive a little into the Flanta device.

We are an engineering company, we have many engineers. Five to seven engineers under the guidance of the team leader and manager make up the team. There are several such teams, and each team has its own set of projects.

For us, a project is a client infrastructure for one product or one development team. That is, the project has clear boundaries, but there are no restrictions on growth and development!

Each project has its own needs, which need to somehow convey to the team.

This is done by the manager. These are the basics of "multi-design."

Now that we have a common understanding of the terms from the title of the report, the question is: what is needed to ensure that under such conditions everything does not just work, but works well?

The team manager is responsible for resolving this issue. Being a “translator” from client to engineering is one of his key competencies. The second is the organization of constructive communication within the team and with customers. And the third core competency is finding a balance between the flow of work and the real capabilities of engineers:

We will analyze each competency in more detail.

1. Broadcast expectations

Even the same client may have conflicting expectations. For example, a client’s business requires that the money-producing production is stable. And besides, it was constantly replenished with new features that help increase revenue.

Well, if any accident happens (the business is ready for the accident to happen), then it will be eliminated as soon as possible. That sounds very predictable, right?

But this client also has developers. And their expectations, it turns out, are completely different! For dev developers, production is more important (after all, business also presses on them), and they also expect that any of their requests will be heard and made right now (usually this is described by the phrase "after all, there’s 5 minutes of work”).

The only thing that unites both business and developers in requirements is that they both expect that the planned tasks will be done accurately and on time.

Let's look at the picture as a whole ... Yes, it is immediately full of mutually exclusive paragraphs!

Adding new features always adds new points of failure. Babah! And production is unstable after Friday's release.
Our engineers carried out as quickly as possible during the day everything that the developers asked for, and the planned tasks remained untouched because of this.
Or is this the story: the stability of which environment to pay more attention to? We stabilized dev by allocating resources for this, but after another roll-out, production started to fall!
A frequent case: production broke and the whole team went to repair it. At the same time, of course, there is no progress on planned tasks, and even developers from India have already switched to the Russian language chat in the chat, because they can not wait for an answer.

And we understand that the requirements themselves are contradictory, which means that it is impossible to directly transmit them.

2. Communications

There really are problems in broadcasting expectations. Well, maybe then at least with communications everything is easier?

To communicate with each other and with customers, we use Slack for text and Google Meet for meetings and occasions when it is easier said than written. But in the chat we often receive messages that do not carry a useful meaning or contain so many errors that it is difficult to recognize the meaning!

Why do we pay attention to this? The fact is that, for example, only in July 2019 we received 1993 requests from customers at Slack, requiring a mandatory response. And, of course, with the growth in the number of customers, there is a steady trend in the growth of the number of such requests. In July, we spent about 165 engineering hours on the reaction to such calls. But for each appeal, it was also necessary to do something!

We are very sorry when the time of engineers, which could be invested in planned tasks, reaction to other calls or even to repair accidents, is wasted.

The problem with chat rooms is obvious, but videoconferencing probably has no problems?

We said above that we use Google Meet for daily team rallies, and the rest of the time we do the tasks that we sorted out at the rally. Every day we spend about an hour on rallies. We try to spend at least seven hours a day on direct work, that is, 6 hours are left to complete the tasks. But our tasks are very different in duration.

So it turns out that in an hour of the rally we could have completed several small, but probably important for our clients tasks. And we need to understand whether hourly rallies are really needed or is it better to go and work this time?

If you try to bring the communication problems together, we get that the chat generates useless interruptions and regular rallies “eat up” working time.

Effective communications do not line up on their own.

3. Planning

Well, we need to solve problems in communications and broadcasting expectations, but in planning, probably, there are no pitfalls? Let's figure it out.

Every day a large number of new tasks are created. I would like us to close tasks as fast as they grow. But in life, an ideal is rarely attainable. First, sometimes something breaks in the infrastructure. Secondly, there are always some small things that are easier to do right away. Thirdly, there are tasks that we agreed to address at a team rally:

And sometimes it happens that because of accidents and tugging on trifles, it is impossible to get to the planned ones at all! At the same time, new tasks do not stop arriving - all the promised dates are broken.

Our recipe

But for all the problems with the translation of expectations, with communications and planning, the method of stuffing cones, we managed to get, as it seems to us, the correct answer.

One of the key business processes that affect all three core competencies is a team meeting. And we had the assumption that if we make a team meeting effective we can achieve 80% of the result with twenty percent of the effort? We tested this theory.

As you remember, we have a team serving our set of projects. And she has a certain list of requirements from these projects. But each requirement, as a rule, is only one in a chain of interrelated tasks. And so in every project! And before taking on a new task, we need to understand if we have completed the previous stage?

Yesterday, task A-1 was performed by Egor, task B-1 - Semyon, and task B-1 - Zhanna. But how do we immerse all engineers in all projects so deeply that Yegor succeeds in coping with task B, and Semyon with two small tasks A and B. “Why all these difficulties?” You ask. Yes, the fact is that Zhanna will not perform planned tasks on vacation today!

Our focus is a lot of similar tasks. On average, we receive about 25 new tasks per team every working day. And since there are many tasks, the connections between them are confused and there is no understanding whether all the tasks of the previous day have been completed. In order to unravel all this, a team rally is needed, and every working day, otherwise we will not be able to manage this flow.

Given the volume of the flow, it is worth preparing for the rally in advance. At the training, without engineers, we will not be able to understand which tasks have been completely completed and which ones have not. And, of course, we will not be able to transfer knowledge from engineer to engineer. But we are unequivocally able to determine the priorities for taking new tasks to work.

Task prioritization

What are we based on when prioritizing tasks? Firstly, we have strategic agreements with the client about the goals that need to be achieved. Secondly, once a week we update tactical plans at an online meeting with the customer. The client’s needs in preparation are upheld by the manager, and the technical need and the procedure for performing a particular task is the team lead. Just so, on the basis of the parity of the opinions of the team leader and manager , a list of tasks for the day is formed.

Culture of team meetings

As soon as we have determined the list of tasks for the day in order to clarify what has been done and to immerse our colleagues in the details, we begin a team meeting at which each engineer should tell in detail what he did yesterday, and the whole team should hear and, most importantly, understand the changes that have taken place. But this is easier said than done.

We introduced a number of cultural features of the rally, which allowed us to achieve the desired result:

At the beginning of the rally, while everyone is gathering, we spend 10-15 minutes talking about life. About news and events not related to work, about hobbies of colleagues. So engineers who are in different cities and almost never see each other become friends or even friends. And these 10-15 minutes a day help the team to be more united .

After teambuilding conversation we proceed to the substantive part. Let's go back a bit.

Remember this illustration? The fact is that neither Semyon nor Yegor know what tasks and projects they will carry out today before the rally begins. For a number of reasons: vacations, business trips, illness, duty, etc. - the task can change performers every day until it is completely solved. And every engineer understands that today a task can be assigned to it, that is, all engineers are already initially interested in understanding the details of each task .

At the rally, we analyze the blockages that have arisen by the whole team. We insist that the whole team take part in solving the speaker’s problem. So we motivate to plunge into tasks and solve them together .

If the team works in the office, informal communication often occurs “at the cooler”. But in a distributed team, the need for such communication exists. That is why, during a discussion of tasks, the conversation often leaks somewhere in the wrong direction. But we stop any distractions. How exactly? We manage to do this quite easily: after all, there is a specially allotted time for abstract conversations, and now it’s working time. Therefore, even the usual oral “let's get to the point” is enough for everyone to return to the business agenda. By stopping distractions in the process of parsing tasks, we set up the team to work .

We try to control the report time of each engineer. Sometimes, to dive into the details, we need a long and detailed story about the problem. However, in most cases, we try not to stretch the rally .

Effective rallies - a silver bullet?

Thanks to the preparations for the rally based on the parity of the opinions of the team leader and the manager and our cultural features of the rally, we really made them effective. But did you manage to close 80% of all competencies? Not really.

We did a good job with broadcasting expectations, but there are still problems with uninformative chat messages in communications, and there are interruptions in planning that prevent us from effectively doing scheduled tasks.

Yes, but non-informative chat messages are also interruptions. And we need to find a mechanism that will help us efficiently handle interrupts of all kinds.

Fighting Interruptions

We thought, what if we have a separate person who will “close” the team working on planned tasks from the interrupt flow?

The idea is not new and generally good, but who exactly will do it? We considered two options: finding and hiring such a service or using existing engineers. The search for new people required time and financial resources, and existing engineers were already “tested in battle” and immersed in all the team’s projects. Therefore, the option of hiring new people was rejected.

It remains to decide on the question of how to organize such a service from current engineers. Here the solution was on the surface: they simply applied duty on a schedule, with a rotation of engineers from the team. We keep the duty schedule in Google Calendar, plus set up notifications in Slack about who is on duty today.

It would seem that everything should be fine now? Hurrah? No, actually the problem remains. Remember, a little earlier we said that in Slack alone we get almost 2,000 hits a month, which is about 16 hits a day for each team. But in addition to Slack, the duty officer will have to process messages from monitoring systems, and on the day it:

112 - from Prometheus;
16 - from okmeter;
25 - from external blackbox monitoring systems;
14 - from various custom scripts;
and even 2 phone calls from customers.

These are 198 interruptions every day from different sources! But in fact, there are even more sources:

Almost every client has a Prometheus;
and Okmeter is installed on each client;
but custom scripts, even one client can have as many ...

In order for any engineer from the team to cope with this without magic and superpowers, we collected alerts from all interrupt sources in one place. We called this tool Madison, and each message in it is an Incident.

But Madison only collects incidents and keeps a fortune about them. But we need to understand what kind of incident to take into work first, that is, to perform triage, to have a clear order of processing and escalation in order to easily carry it out in a stressful situation.

We also created such an instrument - called it Polk:

Polk is the workplace of the duty engineer. It allows the attendant to focus only on incidents, not being distracted by planned tasks, receive incidents from all sources in one place, helps with determining the criticality of an incident according to a predefined Severity, has a set of clearly defined statuses and a processing algorithm that determines the movement of these statuses.

Technical and cultural features of chatting

Excellent: now the attendant, equipped with such a powerful tool, really closes the team from interruptions. But even with such tools the watch is exhausting, and useless interruptions only add fuel to the fire.

To combat useless chat interruptions, we can use a small set of technical tools, but the main solution to this problem definitely lies in the cultural plane.

From a technical point of view, at Slack we shared information on projects, creating a separate channel for communication with representatives of customers, and for each project, a channel for engineers to discuss work on it. We also wrote the @flant

bot, when accessed by Polk, an incident is automatically created that the duty officer processes.

In addition, we recommended that customers use @flant

, and @channel

(an event notifying all channel members) and @here

(an event notifying all channel members online) should be used only in those rare and exceptional cases when you really cannot do without them (for example, when the @flant

bot @flant

unavailable).

On the first day of our cooperation with the client, we post detailed instructions on interaction in the channel. And at the first regular meeting, we are sure to discuss interaction, including the difference between @channel

, @here

and @flant

.

In particular, we focus on the fact that the call to @flant

for us, first of all, is an action with a mandatory reaction, and @channel

and @here

for most of the team is just an interruption, which is also addressless and can be ignored while diverting the entire team from solving planned tasks, including for this project.

But new colleagues from clients who do not know about the bot come to chat. Others just forget. If this happens, we gently recall its existence.

For communication between engineers, we use the same rules for @channel

and @here

: do not use them unless absolutely necessary. And yet, we insist on adhering to the rule “Don’t just say“ hello ”in the chat - immediately formulate a thought”. This rule is a must-read for all beginners. Those who forgot it will be reminded of this - if necessary, deployed.

Total: with the introduction of shifts and the correction of communication problems in chat, we dealt with most of the useless interruptions and with the influence of interruptions on the fulfillment of planned tasks.

Procrastination and blocking

We checked how our indicators improved after that: indeed, they became clearly better, but there was still a problem in planning.

When the team rally is over, it's time to work. But often, engineers, especially those working remotely, tend to procrastinate. Or, during work, run into a problem and walk in circles in an attempt to solve it.

Let's try to deal with procrastination. How to overcome it? There are too many tasks in Redmine (our task tracker) - you need a focus on those that will be in work today. And even among them, you need to understand what tasks to do first, that is, to determine priorities. And ideally, if you roughly plan the time that we are ready to spend on each task ...

We created a tool that helps solve all this, and named it Ford:

It is in it that the engineer receives the task for the working day in the form of cards arranged in priority order. For all planned tasks, we put down the approximate time that the engineer must adhere to when solving them. The engineer takes into account the time he spent on solving the problem. And if the time is approximately the same, but the problem is not solved, this is a marker that the engineer has reached a dead end.

What can be done with this? In addition to the priority in which the cards are located,

we also introduced priority categories, highlighted them with colors:

The gray box is used for ordinary, scheduled tasks;
Green field - for tasks that should be started in the current day only if tasks in all other fields are over;
Yellow field - for tasks that suddenly occurred unplanned during the day;
Red field - for tasks that need to be resolved before the end of the current working day.

If an engineer is blocked by a task in gray and green fields, then he just has to start the next task, and dismantle the lock at the next team meeting.

But it is obvious that if an engineer is blocked by tasks in the yellow or red zones, then you should not wait for the next meeting: you need to call for help from the team in the appropriate channel for engineers to communicate on the project in which the task is set. And, in accordance with our culture, team engineers or team leaders will definitely come to the rescue.

It is worth mentioning that Ford’s capabilities are much wider and we have touched only the “tip of the iceberg”, which you can implement using other open tools.

Summary

It turns out that to combat procrastination and blocking, we use Ford as a technical solution and simple rules in team culture.

Did these tools help us? Yes! But for some reason, not 100%?

The fact is that the world is changing and moving forward. And we are also changing under these conditions, striving for the ideal, but, as you know, it is unattainable.

On achieving ideals and the role of manager

All the great that was created by mankind for the entire time of its existence was made by teams of professionals who had cool managers.

We, Flant, are also a team of professionals. And it would be cool if there were more cool managers in our team. Come to us to work and help make our processes better:

Videos and slides

Video from the performance (~ 38 minutes):

Presentation of the report: