At TeamLead this year, Sergey spoke about how Agile is transforming in a large organization and, accordingly, how your environment (team leaders and teams) is changing and what new requirements are being placed on you as leaders. And he showed the whole Agile process with photos.
Getting started with Agile
If you already have Agile, how did you decide? Have you decided on your own and consciously that this process (Scrum or Kanban) is what you need and what exactly will it help to solve your problems? Was your first acquaintance with Agile like this?
... or did this happen?
In large organizations, the usual story is when a manager comes in: “That's it, tomorrow everyone is Scrum! There is no time to figure it out - you are a Scrum Master or a Product Owner. " Moreover, from the study "Agile in Russia" the figures show: the larger the scale, the more often this story occurs. But no matter how you managed to get into Agile, let's figure out where you got to, what this environment is and what requirements it places on you and your teams. If this is not dealt with, very often the implementation of Agile turns into a factory of features.
In the past, developers took tickets from Jira. Now they do the same thing, but they take from what is now called the backlog: a backlog is rolled up to you, you take from it - and the conveyor goes on. At the same time, somewhere, your products introduce the user to what happened in the end: user and product, kiss!
Is it really Agile? We didn't do it for that.
What is Agile and Why?
You know that Agile is an approach to how to execute projects in the face of great uncertainty. This is Stacy's confusion matrix:
Agile works well in a situation where you have two big uncertainties:
- what you need to do for your consumers so that they vote for your company and product with money;
or
- you do not know with what technologies to implement this,
then you find yourself in a complex environment in which you are offered:
- give up the opinion that you know what your users need;
- put forward hypotheses;
- conduct a series of experiments;
- get feedback from the end user (at first dissatisfied, and in the future we hope to find a way to solve his problem).
As a result, your teams and, in general, your entire organization have two focus:
- What is customer value? You need to learn how to measure it by working with the customer's value systematically.
- Do it quickly. It is sometimes said that a team's toughness is measured by the number of hypotheses tested per unit of time.
How can we land this all on our realities?
What is the leader's task?
There are two actors in the system: you, as leads, and your teams. Consider a simple example: a team makes a product, but the customer is unhappy. What should we do as leads, what is our task in this story? Of course, figure out what the problem is: you, as an expert, go and figure it out. Let's say the development team submits for testing on the last day, so a huge number of problems reach the user. What are we doing next?
We already know what the problem is, we identified it. The easiest thing to do now is to come to the team and say: “Listen, guys, you’re doing this now - let’s not do that! Let’s do it right. ” This is usually done with children. I tell my seven-year-old son: "Vladik, don't do this, please!" And this, by the way, really works - he stops doing that. True, later my wife tells me that he only does not do this in front of me. And when I'm at work, everything continues as before.
So it doesn't work. What do we do then? We change the process, ask the team questions about what could be done so as not to do badly. Basically, all we can as leaders is to customize the environment that determines the behavior of our teams. We create an environment that makes negative behavior impossible and motivates people to behave differently:
For example, you are implementing Scrum. From now on, it becomes impossible not to deliver the result at least once every 2 weeks. No, a developer can do that, but they will receive motivating and stimulating feedback when you, as a leader, invite people to review the sprint, who will say everything they think about the product, without hesitation in expressions. Gradually, for some reason, he becomes a little ashamed to drag the same task every day - every day he has to answer to the Daily Scrum what he did yesterday, what he will do today, and even with the evil addition “within the sprint goal”.
That is, you create an environment that gradually changes people's thinking, and they begin to behave differently. Our task is to constantly think about how to set up the environment. In this sense, we become not leaders of people, but mechanics for setting up the system. Imagine a system - cogs-bolts spin by themselves (these are our smart specialists), and there is friction between them. You run around with an oil can and add where something starts to crack - you set up a system that works on its own.
And the coolest of us make it so that the system for some reason begins to develop itself. For example, you create an environment in which the team knows how to look at the results of their work and, as they say, coach themselves: what else can be done to become even cooler? However, if you have set up such a system, you are in trouble, sadness (or joy) - you no longer need this system (at least on a daily basis), the system begins to develop itself. This is what is called a self-organized team.
But how can this be achieved?
What is the Scrum team responsible for?
Let's go from the bottom up - just take one Scrum team, no scale yet. A question for you: what are the teams responsible for at the end of the sprint? When the sprint is over, what do you scold them for?
The usual answer is for features. If a team is a feature factory, then how are features related to each other? Why are we doing these features, and not others? There is no answer to these questions - such an environment has not yet been created. A classic example is the board of the team from Avito about 2.5 years ago. It can be seen that at the end of the sprint a lot of tasks are still unfinished - only about 40% are ready:
Let's figure out what the problem is. One of the most common problems at the start is that teams don't know how to evaluate. We need to teach them what Story Point is, how to approach it correctly if there is backing, front, etc. in the team. Show them how to do this by example.
There is another problem - they can do it all, but they have no focus. Then we bring the team to a retrospective and ask: "What was the purpose of your work?" In response, a goat's look at the button accordion and the question: "What are the sprint goals?" OK, let's put in a large box what you've been doing over the past two weeks. They sound, you write. After that, everyone anonymously puts a rating on the sticker: "How far have you as a team achieved these sprint goals?" That is, the team has to answer the question, reviewing everything that has been done:
Let's look at examples.
Sprint goals - 8
In essence, these are common tasks. Moreover, I created an environment that showed that each employee had their own goal (task). And when another person answered, I took a marker of a different color:
It can be seen that everyone had their own work. And the team's understanding of how we achieved the goal is completely different. After that, the question is usually asked: "How much are we a team?" For it looks like everyone sawed only their own work. Probably, the dude who gave a two was really carrying on a difficult task and, it seems, no one helped him. The comrade with the nine did not help especially - he cut his task down and, probably, at the end of the sprint he was engaged in self-development, although in the other part of the team there was bombing and help was needed.
Sprint goals - 6 pieces
This is a different team, but the situation is the same. The understanding of reality is already near 8-9, but there is a six. This is exactly the team leader - he understood better than anyone how close they were to the goal:
Sprint goals - 5 pieces
Compressing goals. It's funny, but there is already a normal distribution. 3-4-5 and 7-8-9 are two sub-teams of three people inside the team, who together dragged one job, and they more or less succeeded. The guys from 3-4-5 had a difficult feature, they did not cope. But they are about the same understand that they grumbled. The three sixes are the seniors who understand best what is going on because they helped the Juns in both parts:
Sprint goals - 2-3 pieces
What if you pinch at all? The fewer the sprint goals, the more understanding of reality - what we actually did and how much we achieved it - begins to coincide in people's heads:
Why did I show all this? Why is it cool if the team has one goal?
The Importance of Purpose in Agile
Because Agile differs from the classics by this:
In the classics, we promise a set of features and we can continue to play: either invest more resources in development, or sell the deadlines. There are only these two parameters, because you need to do the entire volume.
In Agile, we understand in advance that we are in an area of uncertainty and do not know what set of features our consumers really need: we only have hypotheses. Sometimes they say hallucinations, and the biggest expert in them is our Product Owner. He hallucinates within two limits: resources are committed (full-time team, all 100% allocated) and the sprint will end exactly when it ends, not earlier and not later. Both parameters are fixed, and we want the scope to be floating. This is not a bad thing, this is a cool feature: we would like to be able to change the scope, receiving feedback - whether we are doing or not. But you need a meter - this is the goal. When else does the target shoot?
What is the purpose of the Sprint Review?
There are two options for conducting a Sprint Review.
The team shows the product owner a working product at the end of the sprint. See how he looks at him. It asked the most crucial question: “Product Owner, give us feedback: how far have we achieved the sprint goal? And how do we need to change the further backlog? " The Product Owner has a closed pose: “What can I tell you here? Well, yes, the buttons seem to work. " A bewilderment arises: how can a product owner give feedback on working buttons if there is no real information about how it will work in the fields, that is, there is no feedback from end consumers: The
second option is my favorite story of one of the Avito teams, which also about 2 years. This team connects sellers and buyers in the messenger. It has two key metrics:
- , , , ..
- , .
The team within the sprint has implemented a banal feature - a round piece, which shows that at the other end of the line the buyer or seller is now online: you can quickly write, and he will immediately answer. During the sprint review, they showed the results of an A / B test, rolling out the feature to production for a limited number of customers and seeing if it really correlates with these two metrics. There was no obvious correlation, and the team asked for another week to take data and understand: if this feature is still needed, then how to modify it?
These are two different options. Your goal will work when you set it not just as a slogan, but when it is formulated in metrics that can be measured. Otherwise it is again a profanation.
What can be the goals of a sprint?
You can set goals based on milestones: make a release by such and such a date, etc. There is little information here again: how do you measure that this is what your consumers want?
OKR offers a different approach: we set goals based on metrics, and customer-specific. How does a customer interact with your product? How does this affect the fact that he solves his problems faster, better, better, etc. and ready to vote for your business with money? Therefore, you must have meters.
One of the properties of a goal, as the OKR says, should be a level of ambition. That is, for the sprint we want to improve the client's life not just, but by how much - up to 80%, 52%, etc. This is the meter where you want to jump:
Bottom line: what kind of environment are we creating?
The product backlog is just a set of hypotheses. We, as the mechanics of this system, at the team level, must mentally change the attitude of people towards the backlog. You have hallucinations in your backlog. Therefore, always ask a question to the product owner, business, etc. - why are we doing this? Why are you sure that this is what our clients need? If not sure, how can we measure that this is really what they want? Change the mentality of both the team and your business customers in order to together give up the feeling that you know everything in advance.
The team is committed to the goal of the sprint. Please do not take any commitment from teams for scoping. This is how you essentially push them into Waterfall, although you call it Scrum. It's not about doing all the features in the sprint. No, your team within the sprint of the Scrum process can even change your product backlog if they suddenly find that what you hallucinated a week ago was not something that brings you closer to your goal. Of course, two weeks is a short period of time, and at the end, maybe not much will change for you. Nevertheless, change mentally - on the scale this problem comes out in all its glory.
The product and sprint backlog is just a plan for achieving a goal. The plan should be regularly checked against the result and changed in case of rejection. I already said that in the Daily Scrum you need to ask the question every day: "What are we doing, with the goal in general correlates?" Gradually, you will train people to think more about the goal than the scope. But first, you need to repeat this several times so that people finally understand why we are doing this.
The focus is more on the end result than on the predictability of delivery times. We focus more on getting some metrics changed than just pulling in features. It is even possible not to finish some features: maybe, after completing 2/3 of your sprint backlog, you will achieve an improvement in key metrics for the client, and it will no longer matter that 2 features were not completed. The goal is something else.
Sprint Review - Assess your progress towards your goal based on customer feedback. Moreover, from real customers. This is a challenge for all employees related to the engineering practice that your team uses: Continuous Integration, Continuous Deployment, etc. This is what is currently storming other industries where Agile is trying to apply.
For example, the Siberian Gurman company in Novosibirsk, which makes dumplings, decided to experiment with the area of uncertainty: what if you change the flavoring filling of dumplings or the wrapper, how will this affect the purchasing power of the product? Cool! - now we will conduct experiments and receive feedback. But what does experiment mean? They come to the retailer with a new dumplings format, but the retailer does not want to make small purchases and offers a large supply for six months - this is how the experiment lasts a year. As a result, Sibirskiy Gurman opened its own store, where you can quickly get feedback, but the store is a completely costly part of the project.
In IT, as you can see, everything is simpler. Everything has already been invented. And in other industries, people are creative to get feedback as quickly as possible. But it happens for everyone.
What happens on the scale?
Somewhere here in the picture is your team. And it begins: each team has its own backlog, its own goal, you understand who your client is, but for some reason a lot of people (contractors, stakeholders, etc.) come running to you who want something else from you ( for example, stick your hallucinations into your backlog), and for some reason you have to do them too:
At the level of final symptoms, we have the following:
- A huge number of dependencies.
- We often do not know in advance who we depend on - this is the low transparency of who I have to negotiate with in order to roll out some feature. You start doing it inside the sprint and at that moment you will find out: it turns out that we cannot change the API ourselves, we must run to that one; but here you need to agree on regulations, information security, etc. That is, it is not known in advance who to run to.
- , . , . , . .
- — . - , , ? , , , . .
- — . : « , ! !» — « ?» .
Where does all this come from on a scale and why does it arise? Let us consider the example of a classic example of obtaining a loan, from where all these dependencies arise in the bank.
The first thing a bank should do is tell people that it has great loan conditions: high-quality, fast, etc. In fact, working with a client starts with marketing. Then there is an assessment, registration, etc., until the complete closure of the loan. The company has operational services that directly serve the client and communicate with him:
Then there are IT systems that support, accelerate, automate - in general, they do it so that the client gets a loan cool and quickly. This is where our people and our organizational structure appear. Here is a contrived example: there are 310 developers in the IT department of Moscow, 30 people in Estonia and another vendor in America (150 people):
A real example about me. When I was getting my third mortgage at my favorite bank, at stage # 2 (quick assessment of applications) I was refused. In the evening of the same day, my VIP-manager calls me with the classic question: “Sergey, is everything good with you with our bank? Maybe I can help you with something? " Of course, I run into him: “Dude, what happened? I'm your VIP client. Why was my mortgage denied when everything was fine with me? " He asked for a timeout and called me back in the evening - he could not immediately answer the question, because he looked into the CRM and did not see any information there at all that I had even submitted an application.
The reason was that in those years, this bank outsourced the first part of its operational services to its partner. That is, there was a parent bank and a partner bank that served clients at the entrance - roughly speaking, it was not the parent bank that loves me, but its partner who refused me. Since the responsibility of one bank ended at the junction with the responsibility of another, the integration broke down. A small mistake made the parent bank unaware that his beloved client was not treated very well by the partner bank. At such junctions, a business very often loses its customers and, as a result, money.
Why am I doing this? Imagine that your Scrum team - cross-functional in terms of backing, front, etc. - is somewhere within this structure. The key question is, how cross-functional are your teams in solving customer problems? Ideally, the cross-functionality should be such that you can help the client at any stage of his communication life cycle with the company. Can you imagine how many competencies you need to fit into one Scrum team, for example, for 11 people?
Unfortunately, on a large scale, this is the main problem: the team ceases to be cross-functional with respect to the client. The solution is this: let's put together a large team of teams that together will be as cross-functional as possible.
Here's an example (two red stickers). A sticker with the inscription "Mortgage" means that we are changing the organizational structure in such a way that a mortgage division appears (stream, tribe, train, etc., in different companies it is called differently). We combine business (responsible for financial metrics for issuing mortgages) and teams (live in Moscow and Estonia) to develop systems in the first part of this stream, fix any integration errors, etc .:
In my story, the vendor could not be dragged into this topic. They said: "Write us the TOR, we will do everything." But in any case, you form a division that looks at its client as broadly as possible. There is often a toast: “Focus on the customer, value,” but count the number of steps this unit closes. The more it closes, the cooler it is, more precisely, it will gradually become steep and will be able to solve all the client's problems.
Why am I telling this? The lead's task is not just to build an environment for team development. First you need to understand:
- What context are you in?
- What steps and client problems does your team or department solve?
- Who is your business?
- What is the end customer KPI for your business unit? That is, what do you improve, and not only your team, but the entire circuit.
As an example, I present three options for cross-functional units.
Option 1: per channel with platform
One of them is essentially the entire web feed, where all the web developers are. For example, for a bank, the main metrics will be in terms of attraction, so that the client can try to calculate it with a loan calculator and become a mortgage borrower.
A mobile app (iOS, Android, etc.) already with metrics related to activation and maintenance. There can also be a platform division, that is, making a component, the consumers of which are other divisions:
Option 2: by products with platform
The second option is cooler: you change the organizational structure in such a way that each unit becomes cross-functional with respect to channels. We need to fix something in the credits - we do this in the web channel and in the mobile phone, the same with debit cards. The department can completely change any channels. But you need to make sure that the divisions can make changes to the same codebase.
This is a more difficult but cooler option. The business really likes it, because the debit stream is earning: you can understand how much we earn, plus there is a payroll for the development teams. As a consequence, you combine revenue with costs. Your department becomes a small company inside a huge one, because it has its own P&L and you can see how effective you are as a micro-organization:
Option 3: step by step value stream
Complex cases have a huge number of units, and each is responsible for a set of metrics. In large organizations, this is the most popular option:
What kind of environment do we create at scale?
At scale, we create the same environment as at the level of one team. It actually does the same thing, but we're growing cross-functional across the entire client journey. Therefore, there is a sea of difficulties: communication with business, other teams, more complex cycles (not two-week, but quarterly):
Sharing Quarterly Goals Planning: OKR Planning (PI Planning)
Okay. Your team already understands that you cannot help your client at all stages. But you understand that there is a business with which you need to plan to change customer metrics. You see, there are still a lot of people: about 150 other specialists (10-12 teams). And with whom, it seems, will have to communicate, because you depend on them, and they - on you.
How to communicate? In all approaches, Agile gives a simple recipe: "Just talk: you have an addiction with someone, go and talk to him." Developers, especially those who like to communicate more with the monitor than with other people, say: "Well, I can't do that - how can I just talk?" Therefore, all frameworks offer communication compulsion: “Okay, you can't communicate. Now you will communicate, but according to the following algorithm. "
Collaborative OKR planning (in another approach called PI Planning) is gaining popularity. The idea is that for a long period of time (a quarter) we together, with the whole crowd, understanding who our business is and our dependencies inside, plan common goals. This is a two-day event, but some people manage to hold it in a day if the teams have already learned to communicate with each other. Roughly speaking, this is a two-day facilitated question-and-answer event, such as:
- Who do we depend on?
- What are we doing this quarter?
- What financial metrics do we want to get? Business, please answer.
That is, we make sure that everyone comes to an agreement with everyone and works out where we want to run by the end of the quarter. These are real photos when three years ago Sberbank first tried to launch such events:
Joint OKR planning or PI Planning is carried out in stages.
Briefing
At the start, a briefing is required. Business should say: “I would like that by the end of the quarter ...” And for example, here above is Sberbank about 3 years ago, and below is GameDev-company Xsolla from Los Angeles. The Americans, by the way, told a simple story that they have no problems with activating new clients: everything is cool with the metrics on activation. But there is a problem with repeat purchases: for some reason, the percentage of repeat purchases is very low. And the second problem is that for some reason additional services are not bought, the average check is low. And the business asked: "Please, all the features in this quarter are aimed at repeat purchases and an increase in the average check (additional services)":
This is one of the ways a good vision can look like: when we talk about business context and financial metrics. But we do not know in advance what will be done in the quarter. What happens next?
Architect's speech
In IT companies, we definitely listen to the architect. An interesting story for him! - the environment is also changing. At such sessions, architects finally understand who their customer is (most corporate architects think that this is a business):
This architect wanted to quickly report on the “terrible” landscape of Sberbank and run away: “I told you everything! Moreover, he gave a conceptual architecture of 50-100 pages. What else can I do here? Still understandable, but if anything - call. " But after the presentation, one of the team leaders asked him a question:
- Dear architect! The third from the top right cube - did you know that this system is not yet in operation?
- Of course I know. I myself drew these cubes.
- Do you know that it will be commissioned in six months?
- Yes, of course.
- Now remember that we are at the planning session for a quarterly goal, and the business wants functionality from us, which, in theory, should pass through this system.
Here the architect understands what the question is. And the team asked him to stay with them, so that when they plan their features, they will think together how to make an inappropriate decision.
Swarming (target generation)
Then the teams set off for free swimming. They have three hours, and they must generate goals that they are willing to take responsibility for on a quarterly basis. This is called Swarming (swarming, buzzing). It's a kind of networking, but within the framework of work:
Of course, not everything is so simple. The children are given an algorithm for reaching what adequate goals they can take for the quarter. They make flipchart sheets that show the estimated sprint backlogs a quarter ahead. This is necessary so that after they, taking into account their availability, roughly fill their backlogs and talk with other teams on dependencies (who, to whom, what will / will not do what), ask them the question: “If you drag all these works, what goals you will achieve, and with what measure (metric) can you measure the degree of achievement? "
That is, we plan work backlogs, then we formulate goals based on them, after that we refuse these backlogs. It's just a technique for how to arrive at an adequate goal setting. Under no circumstances think that the guys are committing all teams for this set of works for the quarter:
- Team, come up with a goal!
- ... That's it!
- Are you sure you will reach it?
- No, you just asked to come up with.
No, we are facilitating, that is, we help to come to more or less adequate goals.
In the photo there are representatives of the teams who were forced to communicate. They sometimes come to this session with the feeling: "Yes, we understand what we are going to do, and it seems that we even know the dependencies on other teams, because we talked to them last week." But when you ask me directly to say what the teams will do this quarter, the dependencies are finally revealed:
We give them a tool so that, having talked about their addictions, they can display them and see who depends on whom. Vertical skips are sprints within a block, horizontal skips are teams. At the intersection, the team puts what feature it will do, and draws it up with a red arrow: "But they promised us to do it a sprint before the API, then we will make a button at the front." This is a protocol of agreement that we have agreed with you, who, to whom, when and what:
Product Owners presentation
Further at the presentation, product owners show the results of their teams:
The only one who is trying to glue in the brain how the end-to-end scenario will work is the business. Any question to the Product Owner at the start of the type: “What end-to-end scenario will work?” - often remains unanswered: “Wait, we are responsible for this component. It will work for us, your question is not for us. Bullets flew from our side, look in other teams for the answer to your question. " At the start, the business does not understand anything, but it tries to glue this picture together in its head.
External dependencies
Xsolla has the penultimate line of Tech Ops. The guys already understand that they need to deal with DevOps, respectively, to bring the support of the environments inside the teams. But at that time (six months ago) it was an external unit. The operation manager also presented - he walked over the red stickers and confirmed: “Yes, you shoved me here that we need to deploy such and such environments. I take responsibility, we will do it ":
It is interesting that when he said on one sticker what they would do, his team corrected:
- Wait, dude, we didn't ask you this, but something else. Got it?
- Got it.
- Will you do it?
- I'll do it.
- OK.
They had a problem with lawyers, marketing, designers - these guys were in America (in Los Angeles), and they did not come to this meeting. Therefore, the dependencies on them were hanged, but there was fear: maybe they will do it, but you need to call up separately, communicate, etc. The conclusion for this company was that they also invite them to the next quarterly planning.
Risk treatment
There is a certain algorithm for how risks are handled. Key idea: we create an environment in which, it turns out, top management can set tasks. And it's not even scary, they are ready to take them. They look: “If I fix the contract with our outsourcers here, it turns out that we can do more of what I want,” and so they get involved.
These are examples of problem solving that can be accepted if you have everything in this meeting:
Finger voting
The last step is to check if the teams are really ready to take responsibility for the goals they have developed. We ask you to raise your fingers:
- 5 fingers - straight, very confident in their goals;
- 1 finger - with goals in general, it's a disaster, they need to be redone.
You look at the big picture and if you see low confidence in the company, ask them to look around: “Look, it seems that you yourself do not believe in your goals. Go redo it, make it so that you yourself believe in your plans. Nobody pushes them into you (at least they try) ":
Joint Retrospective End-of-Quarter: OKR Review (Inspect & Adapt)
At the end of the quarter we bring everyone together again. In fact, this is a big retrospective (called OKR Review in OKR):
I will show you what is happening there with a real example. The goals that the team took on for this quarter are written out. They have a planned assessment of the impact on metrics, that is, on those goals that the business wanted from the team and the company. The actual achievement is assessed:
Here again shoots: do you know how to evaluate the plan-fact not just as "We think this feature probably influenced", but whether the products with the business collected real metrics from A / B tests, from some options reaching out to customers.
Another option: if the team has not yet set up the engineer, does not know how to quickly reach the client, they evaluate, as in Planning Poker, only with their fingers: "It seems to us that we have achieved this goal for so much":
They essentially set themselves a percentage of achievement: you can see that the team has reached 88% in the quarter. The idea is that such a metric shows:
- How ambitious goals you set with the business;
- How smoothly you know how to carry them:
At the end, there is a regular retrospective and each team works separately. Key point: common problems are pulled out: not separately for each team, but those that shoot several at once. Usually we made the criterion 3+ teams. If they have a common problem, then it is necessary to solve it at the level of the entire unit:
Summary. What is the leader's problem?
What is the challenge for us in this whole story? It seems to be clear what to do. But you are in the context of a larger environment: other teams, the business, understanding which parts of the customer journey you decide for and for which customers. In fact, there are a lot of us, such leads and team leads:
What is the requirement for us on the scale? What is the leader's problem? The fact that size matters ... :)
Cheburashka mutated into a crocodile for better survival in the harsh environments of large companies ... In other words, you need to develop yourself. This is a sore saying, but in fact, if you don't develop yourself, the people below you don't do it either. And in a huge company, the demands are ruthless about what kind of leader you should be. You need to be able to set up the environment for a huge number of teams, that is, to self-develop many times more actively.
What leaders survive in Agile
Basically, you need to stop managing people. Form environments in which people are self-governing. Stop being an expert, become a negotiator.
Here's what to verify how cool you have developed in all these areas:
This year we will hold the second TeamLead Conf in Moscow instead of the Saint TeamLead Conf in St. Petersburg. Already on November 16 and 17, we will meet live and discuss what has changed during this time. We are already yearning for real face-to-face conferences. So that you can see the speaker's charisma on stage and then ask him for another hour in the hall. To drink a monthly norm of coffee and see all the team leads you know at once. And for another month after that, sort out records with contacts, books and keywords.
, , , , . : , , -, , .
. . . 2019 .