From the closed caste to Servant Leadership: the evolution of the team leader on

    On the way from the traditional hierarchy of developer - teamlead - CTO to the mysterious Servant Leadership in, there was also autonomy. A great idea, to give people freedom, the opportunity to develop, grow, achieve their goals themselves, was to motivate employees.

    Georgy Mogelashvili ( glamcoder ) on TeamLead Conf told about all the stages, including the fact that it is impossible to simply declare autonomy, and send the Timid people to the cold . The company tested organizational changes, conducted trainings, and autonomous teams did work. But only the involvement of people did not grow, and in some places even fell. Then the process of reorganization began with a new force and the timlid returned, but with a different role .

    Under the cut details andmodern management device in a company with 1,500 employees in IT .

    About the speaker: Georgy Mogelashvili has been working in IT for more than 10 years, he has been working for in Amsterdam for the last four years, 2 of them being a team leader.

    We will cover three main topics:

    • The process of evolution (what we went through during the time I was in the company).
    • Autonomy is good or bad, and why we had it.
    • The concept of Servant Leadership.

    I will talk about what we have now and what the team leader in our organization is at the moment.

    Evolution of the structure of

    Everyone knows for sure that the main page looks like this:

    A pretty well-known yellow dice with a search, various banners - everything is beautiful, all with pictures. But few people know that in fact the company was founded in 1996 in Amsterdam - very few people know that so long ago, and very few people know that in Holland, that this is not an American company. is really founded by the Dutch, only subsequently bought by the Americans.

    In 1996, the company's website looked like this:

    There is a search button here, but there is no search form, of course, there is nothing interactive. Bookings were made manually by phone. When someone sent a request on the site, the owner - the owner of the company himself took the phone in his hands, called the hotel, said: “Hello, such a guest wants to call on you. Is it possible, no? Yes? Fine". He called back the client and said that "your booking is confirmed." Now everything, of course, is automated.

    Since then, the company has grown a lot. In 2000 there were only 8 employees, in 2014, when I joined the company, there were 6,000 employees, of which about 400 were in IT. We currently have more than 15,000 people in 198 cities around the world. IT employs more than one and a half thousand people, with more than half working less than one year. We are growing rapidly and lately have greatly increased the staff in IT.

    I came to the company in 2014, moved from Moscow. At that moment there was only one development office - the headquarters in Amsterdam. 500 people worked there and approximately 600,000 rooms / nights booked per day. At that moment, the organizational structure of the company looked in such a way that there were many, many Agile teams of five to six people, each with a team leader and product owner.

    There was a management level, which was located a little higher - the senior team leader and the senior product owner, who had several different teams under them.

    Further, the chief technical officers and the chief product officer appear.

    These are all our management structures for 2014.

    Team Leaders and Product Owner

    These two people were responsible for ensuring that the team worked successfully.

    • Timlid was responsible for organizational issues, processes, for holding various meetings, interaction with external teams, partly for the growth of people, assessment of their performance, plus writing code.
    • The product owner was fully engaged in the product: prioritizing and backing up, controlling various metrics, reporting to the business, setting the team’s vision, what it should do and what it shouldn’t.

    When I say code, it means that this is either a backend, frontend, design, or any other human role that he occupied before he became a team leader. Timlids are not just backenders. Timlides can be front-end developers, designers, copywriters, testers. All these people calmly become tmlidy. We have no discrimination for anything.

    The role of the team leader can be characterized approximately in such proportions: this is the time that the team leader usually spends on various tasks. Code and design is most of the time. Then comes the performance of the team and the growth of people.

    Over time, we begin to grow. We understand that soon we will hire a lot of people. Business challenges are growing. We need to expand, introduce new products, we have very strong competitors. We want to compete with them. We are expanding the team. First there was one office, then a few more. We have 5 offices in Amsterdam, where people are engaged in development, and that does not include customer support and other offices. Almost 1,000 people become IT at IT, we beat the record and make one million bookings of rooms / nights per day.

    We are growing, and we need to ensure this growth somehow. We want people with us to understand that this growth is important, and we want to work for the company, so that they want to be that they are laid out in full in order to develop the company with us. How to achieve this?

    We did some research on the market for concepts, psychological programs and other things to help motivate people.

    We found Autonomy Mastery Purpose , which can be described as:

    • Give people autonomy, give more responsibility and freedom.
    • Let them improve their skills, grow as technical specialists.
    • Set clear goals for them.

    With these three components, people will be motivated, they will want to work further and will themselves be responsible for their own growth, for their progression. But in order to achieve this, it is not enough to come to the team and say: “Guys, now you have complete freedom, autonomy, you are great. Come on, work. ” At the same time, there is a Timlid, to which they are accustomed, and they knew that a Timlid would cover their backs and always resolve conflicts. Just to come and say that you now become autonomous in the presence of a timlid cannot be. What to do?

    In we put a lot of experiments on the site. We very often do A / B testing. Virtually any feature that rolls out goes through an experiment. Experimentation underlies all principles of how we work. It is logical that this time we decided to do an experiment and see how we can optimize the process of managing people and the organization of teams in general.

    Autonomous teams

    So we called this experiment. We remove tmlidov. There were Timlides, but now we are refusing them and we will not use them. How to live further is not clear. We leave the product owners in the team, because there should be no complete anarchy. The product must be developed according to some clear plan. A business must be answered by a person who is specially trained and understands which business indicators are important and which tasks should be taken into work.

    Since this is an experiment, and we introduce it for several teams, we want to measure the success of the initiative.

    We plan to do this through a poll, which we call Team Effectiveness . The survey is built on Google research called Perfect Team . There are 7 main criteria, such as:

    • psychological safety (in Russian - psychological safety)
    • ability to work autonomously,
    • ability to make decisions
    • engagement, etc.

    Based on the survey, we will compare 82 teams from the control group. Of these, 24 teams are autonomous, and 58 teams remained old - with tmlidy - for comparison. We will weigh where it arrived, and where it departed.

    If to illustrate, the structure has become such.

    There are much more horizontal connections. People began to interact with each other, began to communicate. Responsibility blurred, there is no one person or two people who are responsible for the integrity of the team. We have distributed responsibility evenly across different people.


    Just do not come to this. You can’t just say: “Guys, there is Timlid Vasya. From today, you no longer need it. Vasya, thank you, go. You are autonomous. Start working together. ” Of course, no team can simply become autonomous. We need to help this process happen. For this, we had two main concepts, the first of which was bootcAMP.

    bootcAMP is a two-day training that we conduct for all autonomous teams at the stage of their formation. For two full days we put the team together.

    We conduct team building at the training, pumping people who have never thought about it before, according to soft skills:

    • communications,
    • reflection,
    • how to give feedback
    • how to build autonomy in a team.

    We begin to pump them in what we were previously engaged in mainly in the organization. This is an activity where people can set up some kind of connections between themselves and agree on something, how they will continue to work in this team. An important outcome of this training is the development of agreements in the team - who will be responsible for what, how we will work (for example, at what time stand-up meetings) and the like. It is important that the team finally understands what its goals and vision are.


    This is the second point that helped us develop and grow these autonomous teams. Kickstarter is a person who, as a rule, used to be a team leader. Since you can not just throw Vasya in the cold, we came up with the role of kickstarter. This is a man who helped autonomous teams in their development at first. He came to the team, spent 2-3 months with her, watched so that all processes were set up as it should, so that people would interact, so that the autonomy machine would start moving. After that, he left the team, or stayed.

    The important point is, if a person leaves the team to continue being a kickstarter on another team, all is well. If for some reason the kickstarter remains in the team, it is important to ensure that he does not start to lead it. Because if a person in an autonomous team takes on the role of a tmlid, little by little all autonomy will flow again to that person, and the whole process will go down the drain.

    We removed the team leaders and, it seems, everything is going well. But there are questions: who does the things that the Timlid did before, how to solve problems, how to solve conflicts ?

    Previously, if Masha does not like Petya, the team leader looks at it from the side - yeah, for some reason, Masha interacts poorly with Petya. Come and ask: “Masha, is everything all right? Somehow in recent times do not communicate. " She says: “You know, he swears when he writes code. I do not like it". “Petya, listen, Masha is here, the girl is fragile, she doesn’t like it when you swear at you. Let's get smaller. ” “Yes, I understand. Good". All conflict, I hope that is exhausted.

    How does this interaction occur in autonomous teams? Timlida is not. There is no one to help this process somehow without loss, so that they do not quarrel with each other. In fact, I have examples of how in my team it worked in a standalone format. I am a very happy person, because all the examples that I will give, they all worked, everything was very cool.

    In our team on the bootcAMP, when we were just being formed, we agreed that we would conduct retrospectives every two weeks. Moreover, retrospectives are not about how the product developed, how we closed backlog well in the last sprint and so on, but about how the team feels. Every two weeks we checked whether everything was good with us in the team, whether we were moving towards autonomy correctly, whether we had built the processes correctly, whether everything was in order or if there were any conflicts.

    Our team consisted of one girl from Argentina and three Russian-speaking guys. As it happens, there are many Russians everywhere, including When the team works, in what language will we communicate with each other? Of course, we are talking, joking, even discussing work in Russian. It began to strain her, because she did not understand what we were talking about. Learning Russian is not an option. We learn Spanish - not an option. To speak English among themselves, when all Russians are strange too. At one retrospective, she says: “Guys, you know, our process is going well, we discussed everything with you. But I have a specific moment for you. Please speak English more often or stop speaking Russian next to me. I also want to understand what is happening, but I do not understand. ” We: “Yes, probably true. We did not notice. Thank, what you told us, we will definitely take note of the information. ” Indeed, we eventually began to recall this conversation and, when we switched to Russian, after a while: “Damn, she does not understand. Let's switch to English, include it in the discussion and discuss what we are now planning to talk about. ” It worked great. This is one of the examples of how collectively we could discuss some kind of problem that had arisen in our team. There were many such examples. This is one of the examples of how collectively we could discuss some kind of problem that had arisen in our team. There were many such examples. This is one of the examples of how collectively we could discuss some kind of problem that had arisen in our team. There were many such examples.

    The second point is very important - how to give feedback . When there is a team leader, it is always clear that this is a person to whom you can come and talk, he will look at your performance, give you some kind of assessment and say that you can improve. When there is no team leader, where can I get this person? Who is he? Where to go, who to talk to?

    We solved it in our team in one way. We all divided it into the whole team. Feedback we gave each other. We made a small schedule, where we broke up into pairs a week and knew that this couple should talk and discuss how they see each other from the outside. But an example of something else. Very delicate subject - how to set grades .

    Quarterly, we have a review of employees, which is rated on a scale from 1 to 5 based on how the employee worked. Previously, this was done by a tmlid. He has the full picture, his duty to rate, because he is the boss. Now there is no boss. What to do in this situation? One of the teams decided to do it together at a round table, openly giving each other ratings. We took it from them.

    I was a team leader, I know how this process happens. First of all, there is a struggle for these assessments, you need to prove why this is so, and why. And here I understand that I will come to the room now, and all the other people are there, and they will give me marks. I do not understand what is happening. How to be? The first time was incomprehensible and unpleasant, probably everyone did not like this idea, but no one admitted. I went: “Yes, cool, awesome idea, dudes. Now we’ll be calibrated together, we’ll put together marks for each other - we’ll live very well! ” And inside I think: "Damn, we will not live." But healed. You know, happy team. I was very lucky.

    There was a situation when we had one guy put a very high rating, rated himself at 4 on a five-point system, and the team said that it was 2. I thought that a storm would break out now, but, to my surprise, he was very responsible, whether he was afraid that we would beat him, but he said: “Yes, guys, thanks for the feedback. You really laid out on the shelves, let me know that there is a problem. I will work with her. ” In the next quarter, with the support of the team, when we already know his improvement points with our support, he improved his performance, he grew gradually from two to three, from three to four, and became an excellent, cool guy. He just had communication problems. We then constantly gave him feedback: "Better communicate with people."

    Of course, this is not magic, it does not happen. There were problems. Our team was so unique and everything was good in it. Not all of the autonomous teams that we had were working in the same solid and cool way. I was thinking about why this could be. Probably because I was a timlid before. I understood how it works. I guided people a little bit and helped them unite the team. I was a little bit of a kickstarter who remained in the team. Our team is lucky. In other teams, of course, it was worse. There were teams where everything was very bad.

    As a result, of course, there were problems with autonomy in the company as a whole. First, it is a frequent change of commands.

    If you know Takman's model, this is a model of team development stages.

    There are four main stages:

    • Forming - the team has just been formed.
    • Storming - people worked for a while with each other, but conflicts begin. They do not understand something, do not agree.
    • Then we go to Norming - the team is formed, and more or less people understand each other.
    • The final great stage is Performing. Everyone starts to work, start to fucking drive.

    The Takman model works very well, but there is a problem - when a new person comes to the team, you roll back a step .

    In such specificity that people change teams very often. When hiring we say that, on average, you will change a team in a year. These are just business features, we can't do anything about it. We direct people to where there are more priorities in the company, in business. And indeed, the ability to easily change a team is a great motivation and a way to grow our employees.

    Imagine there is an autonomous team, all is well. We have different connections between people, they are of different colors, but people somehow communicate with each other.

    Then one new person comes - one has left, one has come - some of the connections have evaporated. Another one came, some other connections were gone. A new PO came, for example, and there, too, everything collapsed. As a result, we have the following picture:

    At this moment, the team is rolled back one stage. If the team was performing, a new person came - the team rolled back and became norming. Norming is still good, you can quickly recover in performing. One more person comes - we roll back still and get already storm. And the storm is installed in perform quite hard, and a lot of effort is spent. At this moment another new one comes, and here ...

    A lot of teams were subject to this effect, and many teams never reached the stage of performing. Without a leader, without a person who would control it all the time, it was very difficult for the team to unite by itself. BootCAMP training is not conducted every time a team member changes, and the kickstarter does not participate every time.

    Another problem is the growth of people without support .

    Despite the fact that we gave everyone freedom, we removed the team leader, who previously could have been the person directing you in your growth. A developer, if he wants to become a leading developer, needs to take some definite steps. This is not just the person who writes the code the longest in the company. He needs the necessary qualities. How to get them and how to understand that you are really on the right track? Timlid earlier could help, tell, direct, bring together with the right people, find a mentor, provide support, give feedback all the time. Under the conditions of an autonomous team, even though we had feedback, spread across the entire team, and you constantly communicated with people, there was no one with whom you could build trust and spend your growth with this person.

    Another problem is of courseload on senior timlidov .

    Imagine, there used to be a manager who has 5 other managers subordinate to him. And now this is the same manager, and instead of 5 managers he has 25 employees, and everyone needs to give marks, everyone needs to communicate, conduct one-on-one and something like that. Load increased fivefold. They are, frankly, a little bit under the list. We tried to grow them, to make more senior timlidov, but it did not help much.

    But the main problem is the fall of engagement . We were going to increase engagement, motivation and employee involvement.

    Compared to teams that stayed with team leaders, engagement even fell in many teams. On average, it has not changed. It did not help people to be more involved.. We need to do something about it.

    We realized that in general, autonomy works, autonomy is good, but not in the form in which it was originally ours. The obvious conclusion - you need to enter back timlidov. We need a man who would manage the team and control it.

    In 2017, we thought about taking the team leader, trying to preserve autonomy and make friends together. The concept of Servant Leadership was born .

    Servant Leadership

    According to Wikipedia, Servant Leadership is a person who shares responsibilities, puts the needs of other people above all else and tries to develop them as much as possible.

    What is it all about? The team was like that.

    Then she became such.

    We have implemented a team leader. He is also an equal participant in the team. He also builds horizontal connections with everyone, but his role is a guide, he is responsible for the development of the team. In fact, this is the kickstarter, about which I spoke a little earlier, but on an ongoing basis: the person who is always with the team, he covers the backs of people, is responsible for making people in the team grow.

    An important distinctive feature of the new timlid servant leadership from the previous one, which is the mini-boss, is adaptability.

    Recall Takman's model: the team goes through forming, storming, norming, performing. A good illustration of the adaptability and nature of the servant leadership - so let's imagine that the nightstand is our team. The command is in formation now. [ George stands in front of the nightstand ]. I, as a team leader, stand up in front of the team and lead it along. At some point, I even indicate what to do. I build processes from scratch and lead people along. The team behind the leader continues to evolve. Passed the stage of forming, go to storming, norming. At this point, the team leader can retreat a little bit back and go hand in hand with them. [ George rises to the side of the nightstand ]. The whole team, as a whole, is moving forward to becoming successful, becoming developed and productive.

    We have reached a certain level of development. The team became independent, performing on an excellent level. Timlid is no longer needed. He moves back and leaves the team working the way it works. [ George passes for the bedside table ]. At this moment I can focus on the code, I can do other things, no longer caring that the team needs my attention. Of course, I see that everything is good, because at some point I can come here again. [ Georgy again rises to the side of the bedside table ]. For example, a new employee came, I stood side by side and helped him to join the team. I can get out here [ George gets up in front of the nightstand ], but I can generally go around and stand on the other side - there are many options.

    The main, key feature of the servant leadership is the adaptability of the team leader to the current situation. This is not only the boss, not the person who is always approached with questions and always knows that he will decide. This is a person who knows how to build processes in a team in such a way that at some point people start working without his participation . I can go on vacation and nothing will change. I can be fired and nothing will change.

    Servant Leader is now spending much more time on growing people and team productivity.

    But at the same time it is important to understand that these inscriptions on this picture - productivity, growth of people, etc. - are not the duties of a specific team leader. These are areas of responsibility that a team leader should set up and be responsible for. But this does not mean that he himself is engaged in this. is he should build an environment in which people will grow, will help each other, in which the team will become productive and will delegate features in the way we expect. But in no case is he the person who says and indicates what to do, and is essentially a commander.

    If we compare the old and the new team leader, it is clear that growth and productivity have become much larger sectors in the diagram.

    How to achieve autonomy? It can not be built just like that. We must first get people to trust. It's not easy to do. With each person absolutely differently. But it will be a good practice to show that you are also a person and also vulnerable. For example, to share some experience.

    At bootcAMP, we had such a thing: each told his own life story, how he came to this day. You had to draw a chart of ups and downs, good and bad moments in your life, how you came here, and where you feel now. Through such activity it is very easy to show that at some point you had a very bad thing: you quit the girl, you were fired from your job, you broke your leg, and all that in one day. You have been very hard and sad. You are a person too, you experienced it. Or, for example, when you became a timlid, on the first day you think: “What is happening? How do I continue to work? Yes, it is such a pain, and to share this pain with people, say: “You know, I was also very worried. I worry now for you, as you, my team, will work, whether all will be well. I'm terribly excited. ” People are starting to quietly think: “So he's normal. He, too, seems to be somehow worried, afraid of something. So normal, you can work with him. " And little by little, trust is restored and built.

    To give a choice, to distribute responsibility, to provide opportunities - these are key moments of autonomy. In the picture is a dog that is stuck in the fence.

    There are two options. Or help her out - come up, somehow push out and pull out. She will then think that the master will always help. Or stand, poke a finger into it, laugh, say: "Why are you so stupid, climbed into the fence, let's get out." After some time, perhaps the dog somehow backs down, hardly, perhaps, will not immediately understand what is happening, whine, but will get out. The next time she gets out herself, without your participation. This is an approach to autonomy, to how your team should work.

    It is important to remember that autonomy is NOT:

    • work alone;
    • anarchy;
    • carelessness;
    • permissiveness.

    This is the work of all together on a common cause, and in our case it is now under the cover of such a cap from the team leader.

    Where to get tmlidov

    We had 28 autonomous teams that became sharply non-autonomous. Where should tmlidy come from? This is problem.

    There are two solutions. The first is to grow it yourself.

    We are doing it quite successfully. We find people who potentially can and want to be timlidov. We conduct trainings for them, the same bootcAMP, but already another, purely for the team leaders. This is also a two-day training session, where people who are going to become Timlides come. They are taught there, supported and doing everything possible so that they understand what servant leadership is and how to build autonomy in teams and then lead them forward.

    Three other points are Booking Agile Essentials.(BAE). We have developed a framework that helps determine whether everything is good in a team. These should be stand-ups, retrospectives, KPIs, team vision and OKR - Objective and Key Results. Just a framework, striking out the checkboxes in which you can understand for yourself that my team is as expected.

    We also have an Agile coach 'and, which has become much more in the company with all the transformations. We hired them enough. They help team leaders and teams in pressing issues. In addition to simply coaching and working with people on a personal level, this is help in holding rallies, and some other work with teams in case there is a need to help the team leader so that he does not do all this.

    The second solution to the search for team leads is their hiring.

    We have never done this before. We have always hired only developers and designers. We never really hired the Timlids, because we did not know how to integrate them correctly into the team. There must be a person who knows Booking, how we work, knows its features. Now we understand that we can no longer live like this. We need someone from the outside, because we do not have time inside to grow as many Timid as we need. Therefore, we search for candidates around the world, transport them to our headquarters, train and grow them. The same bootcAMP, training and trial period, so that they join the company and understand how everything works. Thus, we also close holes in timlidestvo. By the way, if you want to become one of the timblids in booking, then you can safely follow this link .

    A few conclusions:

    • Change can and should be. This is not very bad. Do not think that if you always have one concept worked, then it will work all your life. Not always. Try, experiment , implement an autonomous team, if you understand that your people are not motivated enough, not sufficiently independent. Implement Servant Leadership, if you know right away how to implement it. Look at the options, read the literature. There are many options. Change is good .
    • Autonomy is not scary . It sounds scary because it's incomprehensible. No one has ever done this before, it seems, did not try. And what will happen if people start to wander, pull like a swan, cancer and pike, in different directions, their teams. With this you can cope. Of course, we need processes, we need help, support for Agile coaches, perhaps, Timid, if we save them under the concept of Servant Leadership, for example. This is normal. This is not bad and not scary. This, on the contrary, is good. People are starting to think not only about what they are responsible for, but about something more global.
    • Be a leader, not a boss! As an example with that dog or as in the parable of the fisherman and fish: give a man a fish, and he will be fed one day, give a man a fishing rod - he will be fed all his life. We must try so that our people always give the bait, so that they know how to solve their questions on their own. The first time to help, and then themselves.

    Georgy Mogelashvili is a member of the Saint TeamLead Conf Program Committee and plans to hold a round table on the topic “How to measure a programmer?” Look at what other applications we have received and join the discussion of the team leadership pains.

    Also popular now: