❕ 🖐🏻 🖖🏻 “What to do when dramatic changes in processes demotivate a team.” The experience of the backend engineer who became a team leader ⌚️ 😶 🍇

For 7 years I worked as a backend engineer at Miro, then became a team leader. Over the past years, our engineering team has doubled, become distributed and international, which entailed many changes.

One of them was the introduction of cross-functional teams that could solve the problem completely, from developing the idea to the release of features. For this, the backend and frontend engineers had to quickly master many of the things that we had never done before: testing, working with releases, conducting scrum rituals - without losing speed and quality.

The first steps in this direction led to an increase in the number of errors, a decrease in the speed of development and demotivation of teams. During this difficult period, I just became a team leader, so my personal fear of failure and my own incompetence added to the general stress.

As a result, we coped with the storm, halved Lead Time and significantly advanced in the effectiveness of cross-functional teams. This was largely helped by a change in our attitude to the ongoing changes, the transition from Fixed mindset to Growth mindset.

Below is a video and a transcript of my performance at Saint TeamLead Conf 2019, where, using my team as an example, I talk about the processes and tools that made these changes possible.

History No. 1. Changing the development process to reduce lead time

In 2016, our development consisted of 20 people and 5 teams. Teams effectively interacted with each other, quickly exchanged information and experience. With the growth of employees and teams, the introduction of CI / CD processes and code reviews, the number of interdependencies between teams increased.

For example, in order to launch a big feature on a prod, the team needed to work with 6 more engineering teams:

Give code to code review.
Give a feature to the QA test. If necessary, QA will include the DevOps command to create a special test environment.
Relieve the feature using the release manager, who is responsible for all releases in the company.
Connect additional commands if something goes wrong during the release.

And this is without taking into account the dependencies with the marketing, design and technical support teams, which are also actively involved in the launch of features.

The more dependencies, the more Lead Time, that is, the time from the start of development to release. The higher the Lead Time, the less value we deliver to users.

A large number of communications and low delivery speed demotivate the team. What to do? Reduce dependencies and shorten lead time.

We are trying to build a conveyor in development

To solve this problem, we first tried to build a conveyor:

Describe all stages and processes;
introduce SLA (Service Level Agreement, level of required quality) to determine the time for which the task must go through each stage;
straighten flows to prevent the task from retreating to the previous stages for improvements.

Unfortunately, the pipeline did not work: an error at any stage led to the suspension of the entire chain, while each team was simultaneously forced to solve problems from its own backlog. For example, QA needed to choose: to deal with a bug on the pipeline or to engage in tasks to improve the testing process. This problem of prioritization led to the fact that we either released features, but did not have time to improve internal processes, or were engaged in process optimization and did not have time to release features.

Then we decided to rebuild the conveyor to move it inside each team.

Trying to build cross-functional teams

Cross-functional teams are able to deal with the task from beginning to end: from working out the idea to putting the finished feature on the product. For this, the team needs to have inside all the necessary competencies, knowledge and processes.

We decided to conduct an experiment on several teams before rolling out the changes to the entire company. My team also got into the experiment, which deals mainly with low-level tasks (I wrote about one of our work examples - implementing ActiveMQ and Hazelcast). The team consisted of 3 backend developers, a part-time QA engineer and me as a team leader.

We determine the interdependencies

First of all, we determined the current dependencies that we want to get rid of:

There is no full-time QA engineer, as a result of which we can wait for testing from a few days to a week.
, -.
full-time -, , .

There were other dependencies, but we decided to focus primarily on the three. Now we needed to learn a lot from what the QA engineer, Scrum master and release manager did before.

We learn to test independently.
Previously, engineers independently wrote unit tests and tested the basic functionality, the rest checked QA. Now we have learned how to independently test borderline situations and write end-to-end tests to test the interaction between the client and server.

Learning to release yourself
We agreed that we want to release at least once a week. To do this, we need a release manager within the team. One of the backend developers became of their own accord.

We carry out scrum rituals on our own
The external scrum master did not have time to deal with all the teams, so inside our team we chose the one who wished for this role. He needed to learn how to independently carry out planning, grooming and retro.

Naturally, no one threw us at the barricades. QA, release manager and scrum master passed knowledge and advised in difficult cases.

First failures

The results of the first sprint were unsuccessful. We really began to bring tasks to the master branch much faster, but we were not able to independently make a single release. It turned out that our processes and scripts were not ready for this. The release script was able to release only all services at a time, so we could not release our part of the service separately.

We twisted a part of the processes and at the end of the second sprint we put the tasks out of the first sprint into the release. However, something went wrong again. Half of the released functionality contained critical bugs, so we decided to roll back the release. And they faced a new problem: our backend developer and part-time release manager in the team, learned to release, but still did not learn to roll back the changes. Therefore, we needed the help of an external release manager.

All this led to the demotivation of the team: we fail the second sprint in a row, release functionality with critical bugs - the feeling that we cannot do anything on our own.

History No. 2. A New Role and Fear of Mistake

At the beginning of the experiment with cross-functional teams, Max, one of the backend engineers, volunteered to become a scrum master. However, after the first sprint, he came up to me and said that he no longer wanted to be a scrum master. Following Max came Andrei, another engineer, and said that he would not be testing: "I am a developer, not a tester." As a team leader, it was important for me to understand the causes of both failures.

As a rule, one of the 4 reasons that can work with each of them is the cornerstone of the decision to refuse the task:

   → , , .
(, , ) → , .
  , → : , .
   → .

Max understood the value that the scrum master brings to the team, but was afraid not to cope with the difficult tasks of facilitating meetings. Agreeing to a new role, he knew little about the work of the scrum master and did not give himself a full account of the skills that he would need for this. Max was afraid that he could not cope, he would waste the team’s time and would look incompetent in the eyes of his colleagues.

In the situation with Andrei, it turned out that he tested his code on his own and was sure that everything was fine. However, just in case, I gave QA for verification, and he found 5 bugs in the code. This was repeated several times, which demotivated Andrei, and he decided not to do testing anymore.

I was well acquainted with the situations of Max and Andrei. I myself have recently turned from an experienced backend engineer into an inexperienced team leader. And just as I was afraid that I could not cope with the tasks, I would not live up to expectations and, in general, team leadership was not mine.

Installation on growth and installation on a given

When I became a team leader, I was advised to read the book " Flexible Consciousness " by Stanford University professor Carol Dweck . In short, it describes two types of thinking:

Fixed mindset - the belief that intelligence and abilities are fixed once and for all, it is impossible to influence them, and failure indicates a lack of talent. People with such thinking try not to take complex tasks so as not to lose motivation and faith in themselves.
Growth mindset is the belief that intelligence and abilities can be improved throughout life if efforts are made to do so. Failure is a reason to learn something, so people with this kind of thinking are constantly trying to get out of their comfort zone and take on complex tasks.

Naturally, the world is not divided into black and white, in different situations the same person may be dominated by a different type of thinking. For example, a person may consider that programming is a skill that any person can learn, but at the same time he believes that cooking deliciously is a talent inherent in nature, and this cannot be learned.

The whole scheme is on the Carol Duque website.

This approach describes a person’s attitude towards the changes that are taking place.

People with a predominance of Fixed mindset (setting for granted)
: « , ».
, . , , .

Growth mindset ( )

, , .
, .
, .

This approach has helped me change my attitude towards errors. Therefore, I decided to talk about the approach to the team, since it could give us a single coordinate system, teach us to treat changes differently and reduce the fear of mistakes. Like any tool, growth orientation works to solve specific problems, so I talked about it at 1: 1 meetings to give everyone the information that would be useful to him specifically to solve his situation.

In addition, I told everyone in the team about my own example of working with settings at the time of changing roles from engineer to team leader. This added to the rest of self-confidence (“I was not the only one to encounter this”, “it is really possible to change this situation”).

Continuation of the story number 2

An experiment reduces expectations and stress. After discussing the approach with Growth & Fixed mindset, we agreed with Max to launch an experiment in which he will try a new role as a scrum master. The word "experiment" well reduces the degree of stress. In the experiment, it’s not scary to make mistakes, but it’s important to do the work on the mistakes and make a useful experience. In the same vein, we talked about the new role of Max to the team, which lowered the expectations of the team.

Talent is earned experience.Andrei, when discussing his refusal to test, dropped the phrase: "I am talented in programming." It turned out that Andrei considered programming and testing to be inborn talents. He had the first, but not the second. We started discussing Andrei’s experience and realized that Andrei went through programming through sleepless nights in search of errors, days of immersion in other people's projects, independently wrote tens of thousands of lines of code. It turns out that his expertise in programming is not a talent, but an experience to which he went for a long time and purposefully. Just by learning something, we often forget about the first steps taken in this direction.

Personal OKRs.In order to make our progress visible even with a slight advance, we agreed with the team that we will track the progress of each training. This will help not only to see the path traveled, but also to understand how much more you need to go to the intended goal.

At the company level, we have OKRs, so we decided to apply it for the level of personal training. The conditions were as follows:

We add to personal OKRs only what helps in the current work;
Key Results should be measurable at any given time and help answer the question “How far have I progressed compared to last week ?;
Each key outcome has a list of initiatives that allow it to be achieved;
(, ), , ;
OKRs 1:1.

Implementing personal OKRs for the quarter
A few weeks after the launch of the initiative, we realized that nothing was happening. It turned out that we stood on our own rake - overstated our own expectations. The team was worried that it was necessary to make ideal OKRs for a long time and this was a stupor.

Then we agreed that we would regard this as one of the iterations. OKRs can always be reviewed and refined, this is not something carved into stone, but rather just the direction you want to develop. This helped to perceive the initiative as an interesting game, and things went.

Example of OKRs by Andrey

Bonus, we agreed to share personal OKRs within the team. It helps to learn from each other and works like a public commit.

Continuation of the story number 1

Thanks to a change in attitude, in retrospects we began to look for the causes of difficulties in ourselves, and not outside. Now there were no excuses that could have sounded earlier: "So the process is built, what can I do." We began to refine processes that did not suit us. The team got a sense of ownership of the ongoing processes.

This allowed us to begin to stably implement a small number of tasks. Although it was half as much as before, but we brought it to sale completely independently and without bugs.

All this added to us self-confidence. After some time, Andrey independently automated complex test cases. Roma, who is responsible for the releases, optimized the process so that each team member can now release independently.

As a result, based on the results of the quarter, we were able to reduce Lead Time by 2 times due to the reduction of dependencies, increase of competencies within the team and change of attitude towards difficulties and mistakes.

Our productivity is affected not only by the knowledge and skills that we possess now, but also by how we relate to changes in the company. Sometimes new processes can demotivate, and tasks that are too complex can undermine self-confidence. But with this you can work both for yourself and at the level of the whole team.

My team was helped to cope with the changes and attitude towards errors of the Growth & Fixed mindset. We treat it as a working tool that solves specific problems. Of course, the installation did not change in a few weeks and months. But changing the attitude to specific situations, we were able to move forward significantly in the quarter in relation to daily work tasks and difficulties.

“What to do when dramatic changes in processes demotivate a team.” The experience of the backend engineer who became a team leader