Motivation, delegation and automation: the recipe for creating a super team
Meet this Dima. He is a team leader and is responsible for technical debt and code review, for planning and technical processes, for developers performing tasks on time - motivates, hires and, if necessary, dismisses. Dima wants to work only on important tasks, but he works on a million very different ones, constantly thinks about work and does not get enough sleep. Everything is on fire in him: deadlines, tasks, time and self-esteem. Dima is in hell.
Common situation? For Alexey Kataev ( deusdeorum ) - exactly. Alexey has been involved in web development for more than 15 years as a backend, frontend, fullstack developer and team leader. Now Alexey works at Skyeng and once he managed to make a super team from the team - the best in the company. And since then, Alexey has been engaged in creating super-teams on Skyeng on an ongoing basis. How he does it, in deciphering the report, which the participants of TeamLead Conf 2019 called the best at the conference.
')
We recommend watching the video if you have time, - Alexey charges you with enthusiasm for change. And the article is better suited to view the main points to think about something that has always eluded before.
Dima you are already familiar with. Previously, he was a good developer - he took 3 tasks every day and did them to the end - this is the most important thing. Green dice next to Dima is an indicator of hell in his life.
What happens next with Dima? If you think that he becomes a timlid and hell becomes a little more, then you guessed it. A product comes to Dima and says: “ Let 's go and plan Q2! When will task 1653? We have a release soon ! ”And the hell is getting a little more.
And then comes the CTO: “ We need to hire another developer. What is your technical debt? And here's another questionnaire in Google Doc - fill it in, please! ” And hell has become even more.
Then the developers came: “ We want to grow! Increase our salary! ” And Dima starts to burn.
Everything leads to the fact that Dima is not getting enough sleep. In the morning he goes to the shower and thinks about the developer and the product, and about what and to whom he has promised. Tasks are lost - either Dima forgot about them, or they are somewhere far in backlog and will never be fulfilled.
Locally this can lead to bad consequences when Dima says: “ Everything! I will no longer be a team leader! I just want to do my own tasks, leave me alone ! ” Or they will fail the task, because there are many of them, and Dima is alone - it is difficult to keep the focus on everything. As a result, we will lose a lot of money or do not release anything in time.
I will tell you how to remove hell from life and create a super team. At the end of the tradition will be bonuses.
Skyeng has 17 development teams, each working independently on its product. Most often, in addition to developers, the team includes at least a product and a team leader.
Product sets business goals - he has a vision of the product, he is responsible for the money we earn and spend, and communicates with all customers and clients.
Timlid, that is, Dima, is responsible for the technical strategy, technical solutions, technical debt - for all technical. He is a technical leader . Another team leader is the project manager . We do not have a dedicated project role, so the timlid is responsible for planning and all processes: for the fact that tasks are performed by the right developers and do not hang in statuses. Timlid is a leader and mentor , working with people: hires and dismisses, develops and communicates, leads and motivates.
Let's look at the tasks that Dima does. I share them in:
In my classification, important tasks are investments with a long payback period. These are the resources that we spend on the team now to improve it over the long haul. These are the tasks of a manager that only he can or should do. Of course, Dima wants to do only important tasks, but all the others don’t.
Yes, you immediately thought that everything should be delegated and automated, and happiness would come. Dima also knows that this should be done, but for some reason it does not work. Perhaps the reason is that Dima works 10 hours a day, and on weekends, when he is finally tormented by Slack, he completes important tasks. It also takes time for delegation, because everyone needs a long time to explain what and how - it is better to do everything yourself. To automate, it also takes time - you need to write some code, and there is not enough time even to create a turnip.
This is a way that everyone knows, but no one does. But there is another way, similar, which I passed.
First you need to find low-hanging fruits - very simple tasks that take the most time, but which are also easy to get rid of. You know these tasks, and if not, worklogs will help.
Most likely, this will be work with appeals . In my experience, team leaders spend a lot of time to answer questions from developers, products, CTO, customers - Slack is always full of messages. Now I will tell you how easy it is to get rid of this noise.
When I joined the billing team with a tmlid, I immediately said that I did not answer a single question . I created the #billing channel, said that there were all the questions there, and put it in the “I don’t answer in person” status.
In Slack, I replaced the red icon so that my dot never burned, and appointed the attendants - someone must respond to the people in this channel. Attendants can be selected from among the developers or QA. I made a schedule for QA and asked me to mark the necessary developers if the attendants cannot answer by themselves. I also told the team not to look at this channel - there is hell, and we are just working.
Then I saw how people wrote appeals:
- Aah! Nothing works, nothing is paid! The money has disappeared! We all will die!
Therefore, I wrote the rules how to write calls to support. Then we quickly coded the bot, who wrote these rules when entering the channel.
By the way, we do not write bots ourselves. None of the team spends time on it. For this, we have allocated two people in the company, and sometimes we order work from freelancers. It is cheap and fast. There are no requirements for the quality of the code - we ordered this bot with the rules and received it in a couple of hours.
Total: in an hour I got rid of spending a lot of extra time to answer questions. Yes, someone was offended, probably, but then you can do other things.
How else to improve this solution?
FAQ section . Ask the attendants to write answers to the most popular questions and make a short instruction not to waste time on the answer.
Quality control . Look at the cool support, borrow ideas. I made the quality control simple: I told the attendant to write once a week the number of calls, how many questions we answered, and how many problems we did not solve.
Then we integrated another bot, which, in all channels, analyzes by emodzhi whether the appeal was processed, and will post the same digest channel ala SLA by appeals.
As I said, you can give tasks to developers, QA, bots. But when you hire cool specialists to the team, pay them a lot of money, it is inconvenient to ask them to do nonsense such as transferring documents from one Google Doc to another, subtitles, file swapping. And you do it yourself, which is even more stupid.
Therefore, in Skyeng there is a special department of administrative assistants . This is an internal YouDo, but with differences.
We delegate many tasks to assistants. For example, the classification of applications - view a thousand applications for the year and break them into categories. We write videos of all our meetings : daily, meetups, retrospectives, and someone has to pack them in teams and folders. Now assistants do it, and you can always see any meeting for any day.
Then Dima decided to further optimize his time management and read Maxim Dorofeev’s book “Jedi techniques”. From the book, Dima took a bunch of life hacks. At the end of each day, he decided to keep a checklist : what he did today, what he did important and what he would do better.
Dima keeps a check-list and seems to need to be analyzed at the end of the day, but it does not work. Why? Because on Tuesday, the food fell, Dima repaired it all night, and now his head does not work.
Here, everything is pretty trivial. We use auto escalation - we set up a special bot. In Skyeng, this is OpsGenie, which calls us at night if the food is broken and makes us repair it. But we just want to get away from it and not get up at night!
The duty is set to escalate: if the developer did not take the problem, the bot will call the team leader. The next day, the team will figure out why the developer did not get up. But it will be useless if the developer, after 10 minutes, as he wakes up, will start calling the team leader.
Therefore, we give all attendants access to all diagnostic tools at once : Kibana, Sentry, New relic, as well as root access to servers, and write brief documentation on how to use it, where to look and what to repair.
True, it does not work in the billing team - there is too much money, but in all other teams there is. We write a special document “Panic doc” - what to do if everything is broken. When you wake up at night, everything is lying, allergies are piling up and you don’t understand what to do at all, there’s a simple Google Doc for one page, where steps are described how to proceed in this situation.
Returning to the checklist. Now Dima slept well and can analyze by the records that he did important things in the last days: June 3 - nothing, June 4 - nothing, June 5 - nothing. This is a classic situation, I often have this. The main thing is to be honest with yourself and not enter in the checklist nonsense, which did 5 minutes.
Dima looks at what he did today:
All day some meetings!
You are waiting for me to say now: “But let's delegate meetings!” This is a “head on” solution, which we will consider using the example of a technical review.
If Dima says: “ Max, you are conducting a technical review tomorrow ,” then, most likely, it will not work. Dima spent two years conducting technical reviews, he read articles, he has a lot of experience - it would be strange to lose it.
How do I organize technical reviews in a team? I tried to formalize all my experience - I wrote a document about how I conduct technical reviews. By the way, it helped me to formulate some things. I wrote a framework in which were:
I spent 40 minutes on the document. My life hacking, how to quickly write documents: I put on the basis, showed all the team leaders in the company and received a bunch of comments. As a result, in this manual we combined the experience of the whole Skyeng, because there were many interesting offers.
What's next? You can not just throw, like a jar of canned meat, into a person with this document: “ Conduct a technical review of this algorithm! "It does not work. I asked who wants to conduct a technical review - it turned out the whole team! We made a schedule and started reviewing by turns.
It is important not to exclude yourself from the process, because it is impossible to do well what you yourself do not do perfectly. Timlide must be turned on, watch how everything happens and pump yourself too.
I have seen this error many times, if you do not take part yourself and do not do it on 10 out of 10, then it will turn out badly.
We began to conduct technical reviews in turn and collect feedback: after each meeting, each participant received a questionnaire, where he assessed the meeting process, and moderated “interesting” , “constructive” , “all opinions heard” and “free feedback” categories.
The last point is the most important. There were interesting and funny things: “I can’t immediately think of where to improve. They are yelling screaming children, but they are always furious. ”- The specificity of the remote team. But there were also useful suggestions: “Before recording the decision, it is worthwhile to make everyone shut up and once again voice the conclusions.”
We spent several rounds in a circle, improving and improving, until there was nowhere to improve. The algorithm is also changed in the process. After that, those who conduct technical reviews were chosen better - they introduced the role of facilitator . We also automated this process and wrote a bot, which instead of a timlid conducts a survey, generates a schedule of technical reviews at the right time. Now we want to automate even a part of the meeting itself in backlog, replacing the leader with a bot.
As a result, Dima got rid of the need to hold all the meetings . It seems time has come, but all the same, when at technical meetings the colleagues cannot come to a common opinion, they ask Dima to join the conversation and help resolve the technical conflict.
But Dima read the Haypah book of Ray Dalio 's Principles and decided that it was necessary to formulate technical principles that would help make a decision without his participation — to formalize them.
We gathered the whole billing team, I sketched out the basis of these principles, we discussed them for a long time, voted, improved. The result was a list of 12 principles. Here are three of the twelve: what is important for us - the quality of the code or the speed of development, is it possible to outsource our development and do we think about the consequences?
The billing team's answers showed that billing is for everything good and against all bad: we are always for quality , we cannot outsource and think about the consequences .
But there are teams in the company, where the answers to these questions are different. For example, speed is important for a platform team - not that they write bad code, but the speed of hypothesis testing is important. Outsourcing is not only possible, but necessary - they truly outsource their product. The implications are also important , as is billing, because if the platform lies - financial losses are huge.
But there are dozens of other teams that do not think about the consequences, and this is normal for their products.
We also formulated the principles of work and recorded them on paper. Yuval Noi Harari at Homo Deus. A Brief History of Tomorrow ”wrote that thoughts have special magic when they are recorded, and not just spoken. Therefore, we recorded what is important to us.
For example, we do nothing for nothing, communicate culturally and openly talk about problems and risks . This is our most important principle - we are not silent at the meetings.
When I summed up, I considered the standard deviation of the vote and brought out the most contradictory principles, where we do not come to a common opinion.
Thank God we have no democracy and the principle of accepting principles works: “A team can choose principles”. Therefore, the first paragraph crossed out and the second left.
Only those in which you have to participate are left, because there really are considered complex or undescribed cases. But then the principles can also be supplemented.
The product comes and torments Dima - we have not got rid of this.
I am a fan of Kanban, because he just allows it. In my opinion, the pipeline looks like this: there are columns, we push tasks.
Everyone has already heard about the bot of Arsenius. The bot pushes tasks from column to column and writes every morning: “You didn’t roar, you didn’t release.”
I saw that this does not always work, because some tasks hang in the waiting column for weeks. For example: “I’m waiting for Alexey’s response from the infrastructure team,” and Alexei doesn’t know what the task is waiting for him. And Arseny also does not know that Alexey does not know.
Therefore, I introduced the role of the pusher , which I peeped from 2GIS. I was visiting them, where I was told that they had a person who missed tasks every morning. He looks at the board and asks if it can be done faster, can it somehow be pushed through now?
I performed this role myself, until I realized that my eye was becoming blurred - I already seemed to remember that someone was waiting for someone, I would not ask about it, and there was no time. Therefore, we came back to the same thing - we made this role on schedule.
The attendant with fresh morning glance looks at the board and skips the tasks . Every week we change it. The role of the pusher can also be performed not by the timlid, it can be quite distributed.
You made the working mechanism: there is a Kanban-board, all tasks are transparent, but there are 40 of them. Product is too lazy to look at it, he wonders when he will have direct payments.
In SCRUM there is a Demo day — something like a sprint-demo. We moved the idea to Kanban, and now we have a meeting every Friday, at which the person tells 7 minutes what he did. And you cannot say that you repaired production or set up the environment - what we say at daily meetings, but only what tasks from the plan really were released.
So that I don’t have to remind people to do this, I made a presentation template on which it’s large:
If you have your own tasks against the background of this template, it is impossible to insert any nonsense there.
In the same template there is a slide “What I will do next week” , which should be in the next presentation for comparison between what was promised and what was actually accomplished.
So we distributed a part of the task of the team.
Now I will talk about the experiment that I am conducting now. I can not yet say whether he is successful, but I like it, so I hasten to share with you.
In a rough approximation, the flow development in Skyeng looks like this: goal - plan - problems - solutions - technical solutions . We used to always do this.
The product and team leader set a goal for the quarter , they themselves come up with an optimal plan for achieving it and beautifully present the plan to the team.
Then we put together a team and together we come up with the cheapest and fastest solution , for example: "And let's not code at all!". We make technical decisions in a small group during a technical review, as I said.
The scheme works, we used it for a long time. But recently, on the same team, we tried to deviate from the standard, which, I think, works more interesting.
The product is responsible for the business and sets the goal : “Our goal is to increase the conversion by 2 times” or “Reduce the failures of payment systems by 10%”. But then the scheme changes.
We divided the team into small project subcommands . Each subcommand was given a goal and suggested to think for themselves how to achieve it. Timlid and product are now just consultants .
We dedicated a whole meeting of the presentation of the plans. Previously, at such meetings, the product told his plans, and few people listened to him. Now the developers will present their plans to achieve the goals. With technical solutions, everything remains as before.
I implemented this scheme, because I think that it is possible to increase motivation. When not someone told you: “This is the plan, it will work,” and you yourself came up with a decision, you are responsible for the result and make a kind of promise, you can’t say that it cannot be done at all if you presented your plan to the team 3 month ago.
So we saved the team leader from almost the entire routine, distributing everything that is possible. Although some part of the routine work remained, he can use more time for more important things.
Team motivation . I am convinced that one of the duties of a manager is to come every morning and say:
- Guys, we figachim! Here is our product, here are our goals, here is our culture!
So we transfer our energy, culture and charge to people. If the team leader is rotten, then the team is the same. Examples I have seen many times.
Hiring and dismissal . It is expensive and difficult to delegate these functions. Timlid - the only one who sees the whole team entirely. This is an important lever that he has to influence the performance and command.
1: 1, as a two-way communication tool . So team lapel maintains feedback with his team. He is no longer so immersed in all processes, and he must have a feedback channel. According to him, the team leads problems out of development.
Revolutionary changes . Cool mature teams can make changes themselves at kaizen meetings. But the developers do not see the whole picture. They are focused on their tasks and projects, and should not spend time on it. Timlid is needed to come up with something incredible.
- Let's divide the team into two parts, or donayem 10 more people, or rewrite the backend from PHP to Go.
Such things will not visit the head of an ordinary developer.
Let's return to Dima, who initially had everything on fire. We helped him get rid of the fire. Now Dima has optimized his time, and he began to miss on important tasks.
Immediately make a reservation - I told about my experience of building a super team in one article, but it is impossible to do it as quickly - this is not a week, not two and not three. In my experience - at least a year will go to build these processes. There will be a routine anyway, you need to analyze your situation for a long time and quietly instill responsibility in the team. You cannot immediately say: “Tomorrow we are holding a stand-up, I’m not doing anything else - do it all yourself!”
So everything will fall apart - move in steps. Perhaps someone will be able to go faster, but in our experience it has not been possible for anyone. If you succeed - write in the comments, your experience will be interesting.
Now let's talk about how to take the vacant time for Dima. You can go to conferences and talk about success. But I am a supporter of the fact that all the time you need to invest in those very important things - upgrade the team.
The tmlid mechanism is his team . Invest in the mechanism, conduct the team as an orchestra and improve it.
There are four of them. Principles . These are 12 of our technical principles and 12 principles of work. Of course, they will not suit you, but it will from what to make a start. I also advise you to read the book, but it is very thick, and here is a small file. The technical review algorithm that we’ve gained is how we conduct technical discussions. He can also be useful. Template demo of the day and the rules of calls to the channel . Maybe something will be useful for your support organization.
Want to get a bonus to the report - write to Alexey on a telegram (@ ax8080) or on Facebook . Alexey also runs a telegram channel, Timlid Leonid , in which he collects useful materials and shares his Timlid observations.
Common situation? For Alexey Kataev ( deusdeorum ) - exactly. Alexey has been involved in web development for more than 15 years as a backend, frontend, fullstack developer and team leader. Now Alexey works at Skyeng and once he managed to make a super team from the team - the best in the company. And since then, Alexey has been engaged in creating super-teams on Skyeng on an ongoing basis. How he does it, in deciphering the report, which the participants of TeamLead Conf 2019 called the best at the conference.
')
We recommend watching the video if you have time, - Alexey charges you with enthusiasm for change. And the article is better suited to view the main points to think about something that has always eluded before.
Dima you are already familiar with. Previously, he was a good developer - he took 3 tasks every day and did them to the end - this is the most important thing. Green dice next to Dima is an indicator of hell in his life.
What happens next with Dima? If you think that he becomes a timlid and hell becomes a little more, then you guessed it. A product comes to Dima and says: “ Let 's go and plan Q2! When will task 1653? We have a release soon ! ”And the hell is getting a little more.
And then comes the CTO: “ We need to hire another developer. What is your technical debt? And here's another questionnaire in Google Doc - fill it in, please! ” And hell has become even more.
Then the developers came: “ We want to grow! Increase our salary! ” And Dima starts to burn.
Everything leads to the fact that Dima is not getting enough sleep. In the morning he goes to the shower and thinks about the developer and the product, and about what and to whom he has promised. Tasks are lost - either Dima forgot about them, or they are somewhere far in backlog and will never be fulfilled.
Locally this can lead to bad consequences when Dima says: “ Everything! I will no longer be a team leader! I just want to do my own tasks, leave me alone ! ” Or they will fail the task, because there are many of them, and Dima is alone - it is difficult to keep the focus on everything. As a result, we will lose a lot of money or do not release anything in time.
I will tell you how to remove hell from life and create a super team. At the end of the tradition will be bonuses.
Intro
Skyeng has 17 development teams, each working independently on its product. Most often, in addition to developers, the team includes at least a product and a team leader.
Product sets business goals - he has a vision of the product, he is responsible for the money we earn and spend, and communicates with all customers and clients.
Timlid, that is, Dima, is responsible for the technical strategy, technical solutions, technical debt - for all technical. He is a technical leader . Another team leader is the project manager . We do not have a dedicated project role, so the timlid is responsible for planning and all processes: for the fact that tasks are performed by the right developers and do not hang in statuses. Timlid is a leader and mentor , working with people: hires and dismisses, develops and communicates, leads and motivates.
Let's look at the tasks that Dima does. I share them in:
- important tasks ;
- tasks that can be delegated or automated to be performed by someone else, but you need to spend time on it;
- routine - simple tasks that must be performed.
In my classification, important tasks are investments with a long payback period. These are the resources that we spend on the team now to improve it over the long haul. These are the tasks of a manager that only he can or should do. Of course, Dima wants to do only important tasks, but all the others don’t.
Surface solution
We get rid of the whole routine, delegate everything that can be delegated, automate everything that can be automated.
Yes, you immediately thought that everything should be delegated and automated, and happiness would come. Dima also knows that this should be done, but for some reason it does not work. Perhaps the reason is that Dima works 10 hours a day, and on weekends, when he is finally tormented by Slack, he completes important tasks. It also takes time for delegation, because everyone needs a long time to explain what and how - it is better to do everything yourself. To automate, it also takes time - you need to write some code, and there is not enough time even to create a turnip.
This is a way that everyone knows, but no one does. But there is another way, similar, which I passed.
Getting rid of the routine
First you need to find low-hanging fruits - very simple tasks that take the most time, but which are also easy to get rid of. You know these tasks, and if not, worklogs will help.
I lead the vorklogs every day, write down everything I did, and then analyze.
Appeals and questions
Most likely, this will be work with appeals . In my experience, team leaders spend a lot of time to answer questions from developers, products, CTO, customers - Slack is always full of messages. Now I will tell you how easy it is to get rid of this noise.
When I joined the billing team with a tmlid, I immediately said that I did not answer a single question . I created the #billing channel, said that there were all the questions there, and put it in the “I don’t answer in person” status.
In Slack, I replaced the red icon so that my dot never burned, and appointed the attendants - someone must respond to the people in this channel. Attendants can be selected from among the developers or QA. I made a schedule for QA and asked me to mark the necessary developers if the attendants cannot answer by themselves. I also told the team not to look at this channel - there is hell, and we are just working.
Then I saw how people wrote appeals:
- Aah! Nothing works, nothing is paid! The money has disappeared! We all will die!
Therefore, I wrote the rules how to write calls to support. Then we quickly coded the bot, who wrote these rules when entering the channel.
By the way, we do not write bots ourselves. None of the team spends time on it. For this, we have allocated two people in the company, and sometimes we order work from freelancers. It is cheap and fast. There are no requirements for the quality of the code - we ordered this bot with the rules and received it in a couple of hours.
Total: in an hour I got rid of spending a lot of extra time to answer questions. Yes, someone was offended, probably, but then you can do other things.
How else to improve this solution?
FAQ section . Ask the attendants to write answers to the most popular questions and make a short instruction not to waste time on the answer.
Quality control . Look at the cool support, borrow ideas. I made the quality control simple: I told the attendant to write once a week the number of calls, how many questions we answered, and how many problems we did not solve.
Then we integrated another bot, which, in all channels, analyzes by emodzhi whether the appeal was processed, and will post the same digest channel ala SLA by appeals.
Dima refused to answer questions, shifted this responsibility onto QA's shoulders, wrote the rules for contacting support, created the FAQ and controls the quality of support work - hell in life has become less.
Administrative Assistants
As I said, you can give tasks to developers, QA, bots. But when you hire cool specialists to the team, pay them a lot of money, it is inconvenient to ask them to do nonsense such as transferring documents from one Google Doc to another, subtitles, file swapping. And you do it yourself, which is even more stupid.
Therefore, in Skyeng there is a special department of administrative assistants . This is an internal YouDo, but with differences.
- Pre-signed NDA . Everyone has access to all corporate Google Doc, you do not have to spend time on it.
- Quality control . There is a special person who is responsible for the quality of the work of assistants. They were long hired, trained and fired if they did not work well.
- Strict rules for setting tasks for administrative assistants . Trello has a card format that is created in one minute - voila! - simple tasks are performed. And it is available not only timlidam, but also to developers. Anyone can use the services of an administrative assistant.
We delegate many tasks to assistants. For example, the classification of applications - view a thousand applications for the year and break them into categories. We write videos of all our meetings : daily, meetups, retrospectives, and someone has to pack them in teams and folders. Now assistants do it, and you can always see any meeting for any day.
We have also reduced the amount of routine in Dima’s life at the expense of administrative assistants, their work regulations and quality control.
Jedi technology
Then Dima decided to further optimize his time management and read Maxim Dorofeev’s book “Jedi techniques”. From the book, Dima took a bunch of life hacks. At the end of each day, he decided to keep a checklist : what he did today, what he did important and what he would do better.
Dima keeps a check-list and seems to need to be analyzed at the end of the day, but it does not work. Why? Because on Tuesday, the food fell, Dima repaired it all night, and now his head does not work.
Production Fix
Here, everything is pretty trivial. We use auto escalation - we set up a special bot. In Skyeng, this is OpsGenie, which calls us at night if the food is broken and makes us repair it. But we just want to get away from it and not get up at night!
Therefore, we create a schedule of attendants and remove ourselves from this schedule. Timlid should not wake up at night.
The duty is set to escalate: if the developer did not take the problem, the bot will call the team leader. The next day, the team will figure out why the developer did not get up. But it will be useless if the developer, after 10 minutes, as he wakes up, will start calling the team leader.
Therefore, we give all attendants access to all diagnostic tools at once : Kibana, Sentry, New relic, as well as root access to servers, and write brief documentation on how to use it, where to look and what to repair.
True, it does not work in the billing team - there is too much money, but in all other teams there is. We write a special document “Panic doc” - what to do if everything is broken. When you wake up at night, everything is lying, allergies are piling up and you don’t understand what to do at all, there’s a simple Google Doc for one page, where steps are described how to proceed in this situation.
Returning to the checklist. Now Dima slept well and can analyze by the records that he did important things in the last days: June 3 - nothing, June 4 - nothing, June 5 - nothing. This is a classic situation, I often have this. The main thing is to be honest with yourself and not enter in the checklist nonsense, which did 5 minutes.
Dima looks at what he did today:
- Morning rally.
- Technical review - this is what we call a technical discussion of tasks.
- 1: 1 with Oleg.
- Retrospective or kaizen.
All day some meetings!
You are waiting for me to say now: “But let's delegate meetings!” This is a “head on” solution, which we will consider using the example of a technical review.
Technical Review
If Dima says: “ Max, you are conducting a technical review tomorrow ,” then, most likely, it will not work. Dima spent two years conducting technical reviews, he read articles, he has a lot of experience - it would be strange to lose it.
How do I organize technical reviews in a team? I tried to formalize all my experience - I wrote a document about how I conduct technical reviews. By the way, it helped me to formulate some things. I wrote a framework in which were:
- The answer to the question, why even conduct a technical review.
- Algorithm step by step.
- Tips for facilitators, for example, how to prevent holivar at meetings.
- Templates: for voting, for tasks, for a schedule, so that everything is in the same style, and a person would not have to write everything anew.
- Examples of success story: the task was described as follows, we’ve reviewed it, and it has become as it should be.
I spent 40 minutes on the document. My life hacking, how to quickly write documents: I put on the basis, showed all the team leaders in the company and received a bunch of comments. As a result, in this manual we combined the experience of the whole Skyeng, because there were many interesting offers.
What's next? You can not just throw, like a jar of canned meat, into a person with this document: “ Conduct a technical review of this algorithm! "It does not work. I asked who wants to conduct a technical review - it turned out the whole team! We made a schedule and started reviewing by turns.
It is important not to exclude yourself from the process, because it is impossible to do well what you yourself do not do perfectly. Timlide must be turned on, watch how everything happens and pump yourself too.
I have seen this error many times, if you do not take part yourself and do not do it on 10 out of 10, then it will turn out badly.
We began to conduct technical reviews in turn and collect feedback: after each meeting, each participant received a questionnaire, where he assessed the meeting process, and moderated “interesting” , “constructive” , “all opinions heard” and “free feedback” categories.
The last point is the most important. There were interesting and funny things: “I can’t immediately think of where to improve. They are yelling screaming children, but they are always furious. ”- The specificity of the remote team. But there were also useful suggestions: “Before recording the decision, it is worthwhile to make everyone shut up and once again voice the conclusions.”
We spent several rounds in a circle, improving and improving, until there was nowhere to improve. The algorithm is also changed in the process. After that, those who conduct technical reviews were chosen better - they introduced the role of facilitator . We also automated this process and wrote a bot, which instead of a timlid conducts a survey, generates a schedule of technical reviews at the right time. Now we want to automate even a part of the meeting itself in backlog, replacing the leader with a bot.
As a result, Dima got rid of the need to hold all the meetings . It seems time has come, but all the same, when at technical meetings the colleagues cannot come to a common opinion, they ask Dima to join the conversation and help resolve the technical conflict.
But Dima read the Haypah book of Ray Dalio 's Principles and decided that it was necessary to formulate technical principles that would help make a decision without his participation — to formalize them.
Technical principles
We gathered the whole billing team, I sketched out the basis of these principles, we discussed them for a long time, voted, improved. The result was a list of 12 principles. Here are three of the twelve: what is important for us - the quality of the code or the speed of development, is it possible to outsource our development and do we think about the consequences?
The billing team's answers showed that billing is for everything good and against all bad: we are always for quality , we cannot outsource and think about the consequences .
But there are teams in the company, where the answers to these questions are different. For example, speed is important for a platform team - not that they write bad code, but the speed of hypothesis testing is important. Outsourcing is not only possible, but necessary - they truly outsource their product. The implications are also important , as is billing, because if the platform lies - financial losses are huge.
But there are dozens of other teams that do not think about the consequences, and this is normal for their products.
Each team must have its own principles, which depend on the product and team.
Work principles
We also formulated the principles of work and recorded them on paper. Yuval Noi Harari at Homo Deus. A Brief History of Tomorrow ”wrote that thoughts have special magic when they are recorded, and not just spoken. Therefore, we recorded what is important to us.
For example, we do nothing for nothing, communicate culturally and openly talk about problems and risks . This is our most important principle - we are not silent at the meetings.
When I summed up, I considered the standard deviation of the vote and brought out the most contradictory principles, where we do not come to a common opinion.
Personal life is more important than Skyeng .People shared equally on those for whom privacy is more important, and those for whom - the company.- It is at home, working at home . We are not "offtopic"!
Thank God we have no democracy and the principle of accepting principles works: “A team can choose principles”. Therefore, the first paragraph crossed out and the second left.
Dima figured out the technical review, the technical and principles of work and does not participate in all meetings.
Only those in which you have to participate are left, because there really are considered complex or undescribed cases. But then the principles can also be supplemented.
Pusher
The product comes and torments Dima - we have not got rid of this.
Dima's task is not to answer all these questions quickly and go tormenting developers along the chain, but to build a mechanism where tasks are solved by themselves and fly away to the prod.
I am a fan of Kanban, because he just allows it. In my opinion, the pipeline looks like this: there are columns, we push tasks.
Everyone has already heard about the bot of Arsenius. The bot pushes tasks from column to column and writes every morning: “You didn’t roar, you didn’t release.”
I saw that this does not always work, because some tasks hang in the waiting column for weeks. For example: “I’m waiting for Alexey’s response from the infrastructure team,” and Alexei doesn’t know what the task is waiting for him. And Arseny also does not know that Alexey does not know.
Therefore, I introduced the role of the pusher , which I peeped from 2GIS. I was visiting them, where I was told that they had a person who missed tasks every morning. He looks at the board and asks if it can be done faster, can it somehow be pushed through now?
I performed this role myself, until I realized that my eye was becoming blurred - I already seemed to remember that someone was waiting for someone, I would not ask about it, and there was no time. Therefore, we came back to the same thing - we made this role on schedule.
The attendant with fresh morning glance looks at the board and skips the tasks . Every week we change it. The role of the pusher can also be performed not by the timlid, it can be quite distributed.
Kanban + Demo
You made the working mechanism: there is a Kanban-board, all tasks are transparent, but there are 40 of them. Product is too lazy to look at it, he wonders when he will have direct payments.
In SCRUM there is a Demo day — something like a sprint-demo. We moved the idea to Kanban, and now we have a meeting every Friday, at which the person tells 7 minutes what he did. And you cannot say that you repaired production or set up the environment - what we say at daily meetings, but only what tasks from the plan really were released.
So that I don’t have to remind people to do this, I made a presentation template on which it’s large:
99% complete - not done.
If you have your own tasks against the background of this template, it is impossible to insert any nonsense there.
In the same template there is a slide “What I will do next week” , which should be in the next presentation for comparison between what was promised and what was actually accomplished.
So we distributed a part of the task of the team.
New scheme
Now I will talk about the experiment that I am conducting now. I can not yet say whether he is successful, but I like it, so I hasten to share with you.
In a rough approximation, the flow development in Skyeng looks like this: goal - plan - problems - solutions - technical solutions . We used to always do this.
The product and team leader set a goal for the quarter , they themselves come up with an optimal plan for achieving it and beautifully present the plan to the team.
Then we put together a team and together we come up with the cheapest and fastest solution , for example: "And let's not code at all!". We make technical decisions in a small group during a technical review, as I said.
The scheme works, we used it for a long time. But recently, on the same team, we tried to deviate from the standard, which, I think, works more interesting.
The product is responsible for the business and sets the goal : “Our goal is to increase the conversion by 2 times” or “Reduce the failures of payment systems by 10%”. But then the scheme changes.
We divided the team into small project subcommands . Each subcommand was given a goal and suggested to think for themselves how to achieve it. Timlid and product are now just consultants .
We dedicated a whole meeting of the presentation of the plans. Previously, at such meetings, the product told his plans, and few people listened to him. Now the developers will present their plans to achieve the goals. With technical solutions, everything remains as before.
I implemented this scheme, because I think that it is possible to increase motivation. When not someone told you: “This is the plan, it will work,” and you yourself came up with a decision, you are responsible for the result and make a kind of promise, you can’t say that it cannot be done at all if you presented your plan to the team 3 month ago.
So we saved the team leader from almost the entire routine, distributing everything that is possible. Although some part of the routine work remained, he can use more time for more important things.
Important functions of the team
Team motivation . I am convinced that one of the duties of a manager is to come every morning and say:
- Guys, we figachim! Here is our product, here are our goals, here is our culture!
So we transfer our energy, culture and charge to people. If the team leader is rotten, then the team is the same. Examples I have seen many times.
Hiring and dismissal . It is expensive and difficult to delegate these functions. Timlid - the only one who sees the whole team entirely. This is an important lever that he has to influence the performance and command.
1: 1, as a two-way communication tool . So team lapel maintains feedback with his team. He is no longer so immersed in all processes, and he must have a feedback channel. According to him, the team leads problems out of development.
Revolutionary changes . Cool mature teams can make changes themselves at kaizen meetings. But the developers do not see the whole picture. They are focused on their tasks and projects, and should not spend time on it. Timlid is needed to come up with something incredible.
- Let's divide the team into two parts, or donayem 10 more people, or rewrite the backend from PHP to Go.
Such things will not visit the head of an ordinary developer.
Let's return to Dima, who initially had everything on fire. We helped him get rid of the fire. Now Dima has optimized his time, and he began to miss on important tasks.
Immediately make a reservation - I told about my experience of building a super team in one article, but it is impossible to do it as quickly - this is not a week, not two and not three. In my experience - at least a year will go to build these processes. There will be a routine anyway, you need to analyze your situation for a long time and quietly instill responsibility in the team. You cannot immediately say: “Tomorrow we are holding a stand-up, I’m not doing anything else - do it all yourself!”
So everything will fall apart - move in steps. Perhaps someone will be able to go faster, but in our experience it has not been possible for anyone. If you succeed - write in the comments, your experience will be interesting.
Now let's talk about how to take the vacant time for Dima. You can go to conferences and talk about success. But I am a supporter of the fact that all the time you need to invest in those very important things - upgrade the team.
The basic principle is that we should not be engaged in extinguishing fires or fixing specific problems, but work on a mechanism.
The tmlid mechanism is his team . Invest in the mechanism, conduct the team as an orchestra and improve it.
Bonuses
There are four of them. Principles . These are 12 of our technical principles and 12 principles of work. Of course, they will not suit you, but it will from what to make a start. I also advise you to read the book, but it is very thick, and here is a small file. The technical review algorithm that we’ve gained is how we conduct technical discussions. He can also be useful. Template demo of the day and the rules of calls to the channel . Maybe something will be useful for your support organization.
Want to get a bonus to the report - write to Alexey on a telegram (@ ax8080) or on Facebook . Alexey also runs a telegram channel, Timlid Leonid , in which he collects useful materials and shares his Timlid observations.
In the meantime, we are already preparing for the next TeamLead Conf - in St. Petersburg on September 23-24. We are looking for new speakers, select relevant issues with familiar experts. Here is a sample list of topics we want to focus on in the program of the St. Petersburg conference:
- Processes, planning, management.
- Personal work with the employee.
- Building a team and internal relations.
- Interaction with stakeholders.
- Personal growth.
I will tell you in more detail in one of the following posts, but you already submit reports if one of the thorny paths already passed. If in doubt, you can first write to me or someone else from the Program Committee - let's discuss, prompt, help.
Source: https://habr.com/ru/post/456512/
All Articles