Contract Management
Let's talk about managing the arrangements. Why is this all of a sudden? Yes, because, at TeamLead Conf , we like to discuss pains and problems, but we also remember about solutions. Surely everyone has problems related to arrangements for work.
The pain with them, first of all, is that the agreements are not fulfilled - everyone knows that, even our friend Captain Obvious, who will help us in this article.
It would seem, what's the problem? A lot of what goes wrong, as we would like. For example, there are not always sunny days in St. Petersburg. So what, the city is worth, people come, love it. Not always what is going wrong is the real problem.
However, in this case, Stas Michalsky claims that the problem is more than serious. Under the cut, we will figure out to what the fact that the agreement is not being implemented, and how, in the end, to make them indestructible.
About speaker: Stas Michalsky has been involved in web development since 1998. He has gone from a junior Perl programmer to a director of development at Biglion. He participated in the development of several dozen projects with high attendance and ensured their support.
Why is this a problem
Business and leadership from our teams and us as team leaders, waiting for the result. Performing a task on time may not lead to a result, but this is a separate story.
The result is a consequence of the work - the implementation of tasks, projects, subprojects. There may be different divisions, but somehow the work consists of some actions, each of which is actually a consequence of the agreement.
It would seem that everything is clear: when we do not perform actions, we break agreements.
Consider the standard examples. Compliance with the code style standard is an agreement with a specific developer. Not all the team responds with one voice: “Yes, wise Kaa, we will comply with the code style,” but everyone says personally that he promises to comply with it. Launching the release on Friday or Monday is also an agreement. Whatever we do, someone has asked us about it or we ourselves decided that it is necessary for something, if a result is expected from us, then it is an action under an agreement.
- If we ourselves decided that they are waiting for this from us - is this an agreement?
- Yes, an agreement with himself, but this is a special case.
That is, not an agreement is broken, if the action is not executed, and the unfulfilled action is a consequence of the failed agreement . We didn’t, because we didn’t agree, or didn’t really want to, or something else. In the center is the problem with the agreement. Thus, we get a picture in which a failed agreement leads to unfulfilled action, which naturally affects the quality of work, and ultimately to the lack of result.
I want to convey to you the idea that developers, backenders, frontendders, testers, team leaders, development managers are all some of the functions and roles within which we do something. But if we look a little higher, then all our work is the conclusion of agreements.and their implementation. It's like UDP - everything else is wrapped up in an arrangement. If we do not know how to conclude an agreement properly, then we can be excellent front-tenders or back-tenders, write excellent code, but there will be no result.
On the contrary, if we learn to create the right arrangements, then:
What to do?
This is understandable to all, even to Captain Obvious, you just need to make sure that the agreements are fulfilled, and you do not need to do so that they are not carried out.
The classic model of how this can be achieved:
Let's talk a little more detail. There are three actors:
If you look at all this from all sides, then you can probably understand what the problem is and how to improve the situation. I hope that the situation requires intervention, everyone agrees.
What is the arrangement?
The arrangement consists of two parts: a commitment and a promise. The difference between them is that the commitment is taken, the promise is given .
A promise is a byproduct, a message to someone that I made a commitment. In principle, you can not even give it, since it is just a notification message. But I undertake this commitment. Therefore, a commitment without a promise is much better than a promise without an obligation. We encounter the latter quite often.
To be honest, it seems to me that the whole problem is that far from everything (and we too) and not always when we make agreements, we think about obligations. We do not always make a decision consciously and really understand what this promise threatens us with. We just nod: “Yes, yes”, we leave, and we don’t take the obligation with us - and this is a big problem.
In fact, it is still much more complicated, because the agreements are different in type:
These are completely different arrangements, the person treats them differently, and they need to work completely differently.
As a rule, the issues that are in some sense more important, it seems to me, than the current coding level of a developer go beyond the scope of the main work, because it can transform through them. If a person knows how to learn, it is completely different than if he has just learned to code quickly and without mistakes in 10 years. Sometimes agreeing with a developer to read a book is much more difficult than requiring him to document the code. But it is even more fun when it comes to changing behavior.
The classic example is when it used to be unimportant to come to 10 or to 12, because, if anything, you can linger and work it out, but now you need to be in the workplace no later than 11, because there are processes and so on. If a person simply agrees: “Yes, well, tomorrow I will come at 11” - this is not a change in behavior, but an achievement. If it turns out that this requires, perhaps, life to be rebuilt - go to bed a little earlier or not play Warcraft, it means that the person himself has to change. It is difficult, and, most importantly, uncontrollable, like any other project.
Therefore, it is very important to understand what kind of agreement we are talking about. The degree of elaboration depends on what type of agreement we are trying to conclude.
Breakdowns
Not only do the agreements break down, they break down, first, unexpectedly, and secondly, at the finish line - because it's so much more fun. Although this is unexpected, as a rule, it is at a predictable point. I always know when an arrangement breaks down.
We are now working in teams, the age of loners and garage computers is gone. We have a team, processes, and each arrangement, in a chain. If it collapses, everything collapses. If a person simply did not read the book, then, in principle, nothing will spoil and break, but in a year your team will not be better than now. For me, this file is much more than two hours of failure of all systems.
Breakdowns are also different.
Failure - This is my favorite, the most honest and the most innocent kind of breakdown. We agreed, the man promised and did not - it happens. This is a simple breakdown, because everything is clear with him.
There are more unpleasant options, such as formal execution.
Formal execution is when on Friday evening the developer (under a pivas for inspiration) smears 40 hours of work time according to tasks that he did during the week. In reality, the person who made this arrangement with you does not receive anything at this moment. If logging time is not needed to press everyone to the nail, but to statistically understand how long different types of tasks take, what is the average error, etc., then such an implementation ruins the whole initiative. No statistics will not be, because the data are taken from the head. As a result, the agreement has not been fulfilled, although it seems that something has been done, and everything is fine.
The problem is that we do not always register a formal implementation, as a broken agreement. Especially if they themselves are not very interested. For example, I am a tmilid, the director said to me from above: “Write the clock, otherwise I will punish everyone!” I came to the team and broadcast that you need to record the clock, otherwise everyone will be punished. As a result, the clock is somehow recorded, I am satisfied - I have something to show the director. I myself participate in this sabotage, and formal execution is important for me. For the task provider, it is unacceptable.
Substitutionslightly different from the formal implementation of the form, but in fact it is the same attempt to break the agreement. Just instead of the visibility of the completed task, a substitution is created. Using the example of time logging, it sounds like this: “To record the time of each task, I need 5 minutes. In total, it is two hours a week. Oh him. I've done a task I didn't intend to do in 4 hours. I did more than I promised, and that time did not pledge me.
This is an attempt to give you something to get behind with checking, but in fact this is also a failure. The problem is that, as a rule, we have a lot of other things; unlocked time is not the worst. We connive ourselves.
I repeat: the unfulfilled agreement is the work in the minus, the result in the minus.
How to survive in the world of non-enforceable arrangements?
You can simply remind : "Do you remember that we log the clock?". If we are talking about behavior change, then a reminder is a good scheme. The most cunning ones hang up posters that support the behavior model: “He pledged the time - the beaver saved!” In fact, we just remind you that there was an agreement, without checking its status at all at the moment.
You can be a little more persistentand asking how the arrangement is being carried out, whether the person has already done something. This differs from a reminder in that it forces one to give an articulate answer. But so you put a person before a choice: to lie or not to lie. The answer, by the way, is not obvious to everyone. In a sense, you are pushing a person towards the bad. Asking - this is a latent type of control - it seems to be asked, but not checked. The man lied, but we leave it on his conscience.
You can check :
We already discussed checking by result. The question is what to do if the result is unsatisfactory, but we will return to this later.
By steps and dynamics, you can check the implementation of the agreement in work and outside work. For example, we persuaded a person to fill out the knowledge base, mapped out a plan with him and go on this plan - this is still all right. But what about behavior change? A person either logs time or does not log; either comes on time or not. It is ridiculous to track this transformation step by step and dynamics — today it’s half an hour late, 25 minutes late, and the day after tomorrow.
The biggest problem with verification is that it is not always possible. Considering that agreements are concluded all the time and with many people, it is also very labor-intensive .
A management model in which the manager takes almost all the time to control the execution of tasks exists, but does not work well in IT. Yes, and the last century. I hope that this management approach will die one day, like the last dinosaur.
Instead of controlling, let's better understand why a breakdown actually occurs - why the person who made the promise did not fulfill it.
Causes of failure
This is probably an incomplete list, but here are the most vivid examples:
Often, behind all the excuses lies the king of the broken agreements - sabotage . When we do not want to do and do not want to admit that we do not want to do, it turns out sabotage. Crucifying 40 hours a week for tasks using a scientific method is sabotage. To come to work at 9 am and an hour to drink coffee is sabotage. It is based on a reluctance to do, which was not explicitly expressed.
In fact, there are more systemic causes of failure . What we have said lies on the surface, and if you dig deep, then there are only three reasons:
Moreover, the first and second paragraph may be present both at once. When we make an agreement, we do not think about what we agree on. Often it sounds like this:
- Hey, do it!
- OK, I will! - and fled.
You can do this when we talk about work in work, for example, about writing a module: “Quickly do task 28”. But this cannot be done when it comes to preparing for speaking at a meeting, for example. In an amicable way, in order to prepare a speech at the mitap, you need to sit down, figure it out, explain how important it is, etc. But often we do everything in the same rhythm : “Do this” or “Look, don't be late anymore!” - and ran .
It happens that we agree, being in a different understanding of the type of agreement. A classic example is documenting code. Over the past time, perhaps everything has changed, but when I came across this, we had a constant debate with colleagues about whether the developer should document the code or not. I, as a manager, believe that I should. The developer believes that the code works, and well, given the load and constantly changing priorities.
The conflict of understanding of the type of agreement is not always revealed. We often believe that this agreement is not necessary to explain, reinforce, because everything is clear: just take it and make it. The subordinate believes that what he wants to do is not wanted from him. And then sabotage begins .
The most popular situation, as I said, is a promise without commitment. An agreement that gave rise to a promise, but did not generate an obligation, will not be fulfilled for one reason or another: the piano will fall, the person will be distracted, something else will happen.
In fact, in the conditions of the complexity of the systems, the intensity of changes: when we are all in a hurry to write the code, we quickly roll out and rework, in other words, under the conditions of entropy, something can always happen that will prevent the agreement from being executed. Of course, you can control every step, harness each case of each of your subordinates, try to help him come to fulfill our agreement. But then there is not enough time for anything more than to drag everything on your own.
If I have a desire to fulfill the agreement, I will deal with all the departing problems: with falling pianos, with the fact that I made a mistake in the assessment, etc.
This is similar to the Scrum ideology, and the complexity of the task is also completely unknown. We make some assumption with an error of previous experience, evaluate, and then just do everything to close the sprint. We recognize that, yes, it will be difficult, that we could have mistaken somewhere in the assessment, that the system may surprise us, but we will simply do so to solve the problem.
With the agreement should be the same as with the sprints in Scrum. A person who has committed himself to do something just has to do it. It's simple!
Summarizing, what was said about the reasons for the breakdown of the agreement:
In other words:
For the standard situation of the GAP analysis, “To Be” is the ultimate goal to which we aspire, but not the fact that we will reach it. But we must strive.
It remains to understand what is a solid agreement and how to manage it.
Lasting agreement
Strong agreement - these are real obligations that are made with an obligatory person. It is very important. We talked about obligations, as about some package that needs to be passed, and now we'll talk a little bit about the carrier of this package.
Agreements made with an optional person lead to inconsistencies. If you present the work in the form of a flow of agreements that are sent in different directions in packages, then when you are trying to make an agreement with an optional person, be prepared for the fact that with a 50% probability you will lose time. Therefore, the first thing to start with is to increase the price of the word.
Word price
Each of your colleagues should ideally understand that servicing obligations is his main job. This is the essence of his work. The written code, the rolled out release are derivatives of the fulfilled obligations. Therefore, I try to talk to people about obligations and that the problem is not that the code is not written or there is no result. This is a consequence and a big pain. But the essence of the problem is that, by making a commitment, we did not find a way to fulfill it.
If you have never talked about this with people, then this, in general, is not so obvious. I suspect that in order to talk about this, it may be necessary to first run through the ladder from the beginning of the report “result - work - action - agreement” and back. But people need to convey the idea of nuclear agreement and commitment, about the fact that the agreement is an obligation, and the obligation, if made, is practically indestructible.
The funny thing is that if you succeed in getting this across, be prepared to reduce the number of agreements. You will be much less likely to promise anything. You tried to make the arrangements work, but in the end, instead of 10 promises, you will have only 3. True, the good news is that they are practically indestructible.
This is natural, because people can not cope for objective reasons - everything can not be done. Reducing the number of obligations is normal, but they will be really strong.
It remains only to figure out what is generally capable of engaging a person in such a bondage of obligation, if it cannot be further violated.
There are several reasons for this, but the real one is an employment contract : "I promised you to do this, because you pay me money for it."
Opportunity is a prerequisite, but not a guarantee. If a person cannot fulfill an obligation, he will not fulfill it — quite obviously. This is the criterion to follow.
A wish- this is the main reason. I have long powdered your brain just to bring a simple idea.
Our task, if we really want to create solid agreements is to involve a person in the implementation of each of them.
Bison Bridle
There is a simple rule from the book “The Law of Raspberry Jam” by J. Weinberg, which I really like - a bison for a bison. The author writes that he had a friend who planted bison. These are healthy, poorly controlled animals. Even the fence does not help much to prevent them from going somewhere. When Weinberg asked his friend how he dealt with the bison, he replied that he had a bridle, which consists of two parts:
Although this is practically a quote from Tony Robbins, this makes sense. You are not a nanny - not a person who goes behind the back of his subordinate and controls his every step. In an amicable way, you should let him go and wait for the result. You do not have and should not have a control panel, but most likely you have one for each subordinate. This should not be, a person should do everything himself . For this, he must want.
There are three more things that are important to add so that the bridle is strong:
Formalization
Formalization is a protocol by which we agree and need to be set up once, make sure that it works, and simply check that it is not moving away.
We must agree that the arrangement never changes unilaterally . The change of priority, which came to Vasya, cannot be the reason for changing the agreement unilaterally.
It is necessary to report about change instantly that it was possible to reconsider the arrangement.
With the possibility of revisionconnected thin moment. I believe that the agreement can be revised, although this may be a loophole: a person made a commitment, and then he says that he does not cope and asks to postpone the term. In fact, the person involved will not use this loophole, but, on the other hand, he will have the freedom of action and the understanding that he is not cornered. A person needs flexibility, because the only chance to fulfill an obligation is when a problem arises, to find the right solution. Fulfillment of commitments in an unstable world is always tacking.
Of course, the obligation must have a content and deadline.. Content is an expected, “tangible” result. For example, in the case of a change in behavior, this is a process that is worked out. In an amicable way, an agreement on behavior change should not consist in changing behavior, but in passing through some process of changing it. It may look like this:
- Come on, you will arrive on time!
- Come on.
But it can be different: “Listen, I need you to come on time. Come this week, right by the hour, I'll be waiting for you in the workplace with a cup of delicious cappuccino at 10:55. We will mark you daily on the blackboard on time or not. ”
I will wait for a person who must learn not to be late, with coffee 5 minutes before the start of work - this is not sabotage, but a bribe, but this is different. Thus, we will have: a plan of action, control and evaluation criteria.
Then commitment — this is important — refers to passing through this plan, and not ephemeral behavior change.
How to involve people?
This is the most important question that rests on everything: how to involve a person? I have 4 questions on which I build my speech when I need to agree on something:
Questions can go in different sequences. As a rule, I run over them in advance. The main thing is that as part of my speech to the person, I am ready to answer all four of them .
Before the conference as part of a thematic coaching, Alexander Ziza put a footboard on me and said: “You know, in a good way, you don’t need to answer these questions to people, they have to answer them themselves, and you just think how to contribute to this!” The topic of the next report, I have not yet figured out how to do it.
In fact, I'm not very sure that it will work for any person of any level. So far I have been using this as follows. When I ask a person to do something, I explain why it is for me, why it is for him, and what will happen if done and not done.
The answer to the question "Why is it for me" in my understanding gives meaning to the whole agreement. If I just ask a person to log time, this is one thing. If I explain that I want on the basis of this to try to understand what type of tasks gives the greatest error in the assessment - this is completely different.
The answer to the question “Why is this for you?” Sometimes sometimes rebuilds the entire agreement, because it must be for some reason needed by the person with whom we agree. If he does not understand why it is for him, then the bison will not go anywhere - the bridle does not work. Sometimes I have to reformulate the task so that it is also beneficial to the person. This can be represented as a manipulation or sale, but in fact it is just a reason to think about how to make the agreement mutually beneficial .
Summing up, how to work with arrangements:
In the beginning, you can make a register of agreements, up to a plate in Excel, to forget anything: who, what, content, term. But this is not necessary, now I no longer lead the tablet.
What to do with violators?
It is important to remember that the breakdown of an agreement is simply a consequence, and the violation lies in the fact that the person has not revised his attitude to the obligations and their significance. And this means that he could not change while ...
How long should I wait? How many chances to give? I believe in the rule of three points - it never let me down: the first time is an accident, the second is a coincidence, the third is a pattern.
It is important that after each “point” you need to talk to a person, explain the importance, draw perspectives in the end. And the intervals between “measurements” need to be made significant - after all, it is a question of changing behavior. But if the “third point” happened, instead of the question “What to do with it?” The question arises, “To put up with it or not?”
And this is already a personal choice of everyone ...
"The agreements are not fulfilled", - captain Obvious
The pain with them, first of all, is that the agreements are not fulfilled - everyone knows that, even our friend Captain Obvious, who will help us in this article.
It would seem, what's the problem? A lot of what goes wrong, as we would like. For example, there are not always sunny days in St. Petersburg. So what, the city is worth, people come, love it. Not always what is going wrong is the real problem.
However, in this case, Stas Michalsky claims that the problem is more than serious. Under the cut, we will figure out to what the fact that the agreement is not being implemented, and how, in the end, to make them indestructible.
About speaker: Stas Michalsky has been involved in web development since 1998. He has gone from a junior Perl programmer to a director of development at Biglion. He participated in the development of several dozen projects with high attendance and ensured their support.
Why is this a problem
Business and leadership from our teams and us as team leaders, waiting for the result. Performing a task on time may not lead to a result, but this is a separate story.
Work and result are different things, but let's talk about this another time.
The result is a consequence of the work - the implementation of tasks, projects, subprojects. There may be different divisions, but somehow the work consists of some actions, each of which is actually a consequence of the agreement.
It would seem that everything is clear: when we do not perform actions, we break agreements.
Consider the standard examples. Compliance with the code style standard is an agreement with a specific developer. Not all the team responds with one voice: “Yes, wise Kaa, we will comply with the code style,” but everyone says personally that he promises to comply with it. Launching the release on Friday or Monday is also an agreement. Whatever we do, someone has asked us about it or we ourselves decided that it is necessary for something, if a result is expected from us, then it is an action under an agreement.
- If we ourselves decided that they are waiting for this from us - is this an agreement?
- Yes, an agreement with himself, but this is a special case.
Now the most interesting thing is actually the opposite: a failed agreement = unfulfilled action.
That is, not an agreement is broken, if the action is not executed, and the unfulfilled action is a consequence of the failed agreement . We didn’t, because we didn’t agree, or didn’t really want to, or something else. In the center is the problem with the agreement. Thus, we get a picture in which a failed agreement leads to unfulfilled action, which naturally affects the quality of work, and ultimately to the lack of result.
I want to convey to you the idea that developers, backenders, frontendders, testers, team leaders, development managers are all some of the functions and roles within which we do something. But if we look a little higher, then all our work is the conclusion of agreements.and their implementation. It's like UDP - everything else is wrapped up in an arrangement. If we do not know how to conclude an agreement properly, then we can be excellent front-tenders or back-tenders, write excellent code, but there will be no result.
On the contrary, if we learn to create the right arrangements, then:
- save a lot of time;
- significantly reduce the overhead to all controls, disassembly, etc .;
- we can really do our work.
What to do?
"To make arrangements that are fulfilled"
Captain Obvious
This is understandable to all, even to Captain Obvious, you just need to make sure that the agreements are fulfilled, and you do not need to do so that they are not carried out.
The classic model of how this can be achieved:
- Understand the reasons.
- Identify and take action to eliminate these causes and change the result.
Let's talk a little more detail. There are three actors:
- An arrangement to deal with.
- The breakdown that happens with the arrangement.
- The reasons for the breakdown.
If you look at all this from all sides, then you can probably understand what the problem is and how to improve the situation. I hope that the situation requires intervention, everyone agrees.
What is the arrangement?
The arrangement consists of two parts: a commitment and a promise. The difference between them is that the commitment is taken, the promise is given .
A promise is a byproduct, a message to someone that I made a commitment. In principle, you can not even give it, since it is just a notification message. But I undertake this commitment. Therefore, a commitment without a promise is much better than a promise without an obligation. We encounter the latter quite often.
To be honest, it seems to me that the whole problem is that far from everything (and we too) and not always when we make agreements, we think about obligations. We do not always make a decision consciously and really understand what this promise threatens us with. We just nod: “Yes, yes”, we leave, and we don’t take the obligation with us - and this is a big problem.
In fact, it is still much more complicated, because the agreements are different in type:
- Within the framework of direct responsibilities , for example, to write comments in the code, complete the release to the environment.
- Beyond the basic work , for example, monitor the relevance of information on a wiki, read a book, take courses.
- Change behavior , for example, start coming to work at a specific hour, or keep track of the time spent on a task.
These are completely different arrangements, the person treats them differently, and they need to work completely differently.
As a rule, the issues that are in some sense more important, it seems to me, than the current coding level of a developer go beyond the scope of the main work, because it can transform through them. If a person knows how to learn, it is completely different than if he has just learned to code quickly and without mistakes in 10 years. Sometimes agreeing with a developer to read a book is much more difficult than requiring him to document the code. But it is even more fun when it comes to changing behavior.
The classic example is when it used to be unimportant to come to 10 or to 12, because, if anything, you can linger and work it out, but now you need to be in the workplace no later than 11, because there are processes and so on. If a person simply agrees: “Yes, well, tomorrow I will come at 11” - this is not a change in behavior, but an achievement. If it turns out that this requires, perhaps, life to be rebuilt - go to bed a little earlier or not play Warcraft, it means that the person himself has to change. It is difficult, and, most importantly, uncontrollable, like any other project.
Therefore, it is very important to understand what kind of agreement we are talking about. The degree of elaboration depends on what type of agreement we are trying to conclude.
Breakdowns
Not only do the agreements break down, they break down, first, unexpectedly, and secondly, at the finish line - because it's so much more fun. Although this is unexpected, as a rule, it is at a predictable point. I always know when an arrangement breaks down.
We are now working in teams, the age of loners and garage computers is gone. We have a team, processes, and each arrangement, in a chain. If it collapses, everything collapses. If a person simply did not read the book, then, in principle, nothing will spoil and break, but in a year your team will not be better than now. For me, this file is much more than two hours of failure of all systems.
Breakdowns are also different.
Failure - This is my favorite, the most honest and the most innocent kind of breakdown. We agreed, the man promised and did not - it happens. This is a simple breakdown, because everything is clear with him.
There are more unpleasant options, such as formal execution.
Formal execution is when on Friday evening the developer (under a pivas for inspiration) smears 40 hours of work time according to tasks that he did during the week. In reality, the person who made this arrangement with you does not receive anything at this moment. If logging time is not needed to press everyone to the nail, but to statistically understand how long different types of tasks take, what is the average error, etc., then such an implementation ruins the whole initiative. No statistics will not be, because the data are taken from the head. As a result, the agreement has not been fulfilled, although it seems that something has been done, and everything is fine.
The problem is that we do not always register a formal implementation, as a broken agreement. Especially if they themselves are not very interested. For example, I am a tmilid, the director said to me from above: “Write the clock, otherwise I will punish everyone!” I came to the team and broadcast that you need to record the clock, otherwise everyone will be punished. As a result, the clock is somehow recorded, I am satisfied - I have something to show the director. I myself participate in this sabotage, and formal execution is important for me. For the task provider, it is unacceptable.
Substitutionslightly different from the formal implementation of the form, but in fact it is the same attempt to break the agreement. Just instead of the visibility of the completed task, a substitution is created. Using the example of time logging, it sounds like this: “To record the time of each task, I need 5 minutes. In total, it is two hours a week. Oh him. I've done a task I didn't intend to do in 4 hours. I did more than I promised, and that time did not pledge me.
This is an attempt to give you something to get behind with checking, but in fact this is also a failure. The problem is that, as a rule, we have a lot of other things; unlocked time is not the worst. We connive ourselves.
I repeat: the unfulfilled agreement is the work in the minus, the result in the minus.
How to survive in the world of non-enforceable arrangements?
You can simply remind : "Do you remember that we log the clock?". If we are talking about behavior change, then a reminder is a good scheme. The most cunning ones hang up posters that support the behavior model: “He pledged the time - the beaver saved!” In fact, we just remind you that there was an agreement, without checking its status at all at the moment.
You can be a little more persistentand asking how the arrangement is being carried out, whether the person has already done something. This differs from a reminder in that it forces one to give an articulate answer. But so you put a person before a choice: to lie or not to lie. The answer, by the way, is not obvious to everyone. In a sense, you are pushing a person towards the bad. Asking - this is a latent type of control - it seems to be asked, but not checked. The man lied, but we leave it on his conscience.
You can check :
- by result;
- step by step;
- on the dynamics.
We already discussed checking by result. The question is what to do if the result is unsatisfactory, but we will return to this later.
By steps and dynamics, you can check the implementation of the agreement in work and outside work. For example, we persuaded a person to fill out the knowledge base, mapped out a plan with him and go on this plan - this is still all right. But what about behavior change? A person either logs time or does not log; either comes on time or not. It is ridiculous to track this transformation step by step and dynamics — today it’s half an hour late, 25 minutes late, and the day after tomorrow.
The biggest problem with verification is that it is not always possible. Considering that agreements are concluded all the time and with many people, it is also very labor-intensive .
A management model in which the manager takes almost all the time to control the execution of tasks exists, but does not work well in IT. Yes, and the last century. I hope that this management approach will die one day, like the last dinosaur.
Instead of controlling, let's better understand why a breakdown actually occurs - why the person who made the promise did not fulfill it.
Causes of failure
This is probably an incomplete list, but here are the most vivid examples:
- Reckless agreement. A person agrees, because it is embarrassing to refuse: you are his leader or simply a respected person, or he genuinely wants to help you, he likes you, or he does not like to refuse at all.
- Error in the assessment. A person may think, agree, but make a mistake in the assessment. Then he will come and say: "Yes, I promised, but the work turned out to be two times more than I expected."
- The change of priorities: “I’m almost finished, but then Bob came, his problem is even more important, so I'm sorry.”
- Lack of resources - just not enough time.
- Unforeseen circumstances - a grand piano fell from above.
- Sabotage.
Often, behind all the excuses lies the king of the broken agreements - sabotage . When we do not want to do and do not want to admit that we do not want to do, it turns out sabotage. Crucifying 40 hours a week for tasks using a scientific method is sabotage. To come to work at 9 am and an hour to drink coffee is sabotage. It is based on a reluctance to do, which was not explicitly expressed.
In fact, there are more systemic causes of failure . What we have said lies on the surface, and if you dig deep, then there are only three reasons:
- The type of arrangement is not considered.
- No agreement type agreed.
- Promise without commitment.
Moreover, the first and second paragraph may be present both at once. When we make an agreement, we do not think about what we agree on. Often it sounds like this:
- Hey, do it!
- OK, I will! - and fled.
You can do this when we talk about work in work, for example, about writing a module: “Quickly do task 28”. But this cannot be done when it comes to preparing for speaking at a meeting, for example. In an amicable way, in order to prepare a speech at the mitap, you need to sit down, figure it out, explain how important it is, etc. But often we do everything in the same rhythm : “Do this” or “Look, don't be late anymore!” - and ran .
It happens that we agree, being in a different understanding of the type of agreement. A classic example is documenting code. Over the past time, perhaps everything has changed, but when I came across this, we had a constant debate with colleagues about whether the developer should document the code or not. I, as a manager, believe that I should. The developer believes that the code works, and well, given the load and constantly changing priorities.
The conflict of understanding of the type of agreement is not always revealed. We often believe that this agreement is not necessary to explain, reinforce, because everything is clear: just take it and make it. The subordinate believes that what he wants to do is not wanted from him. And then sabotage begins .
The most popular situation, as I said, is a promise without commitment. An agreement that gave rise to a promise, but did not generate an obligation, will not be fulfilled for one reason or another: the piano will fall, the person will be distracted, something else will happen.
In fact, in the conditions of the complexity of the systems, the intensity of changes: when we are all in a hurry to write the code, we quickly roll out and rework, in other words, under the conditions of entropy, something can always happen that will prevent the agreement from being executed. Of course, you can control every step, harness each case of each of your subordinates, try to help him come to fulfill our agreement. But then there is not enough time for anything more than to drag everything on your own.
The only chance that the agreement will be fulfilled is that the person wants to fulfill it.
If I have a desire to fulfill the agreement, I will deal with all the departing problems: with falling pianos, with the fact that I made a mistake in the assessment, etc.
This is similar to the Scrum ideology, and the complexity of the task is also completely unknown. We make some assumption with an error of previous experience, evaluate, and then just do everything to close the sprint. We recognize that, yes, it will be difficult, that we could have mistaken somewhere in the assessment, that the system may surprise us, but we will simply do so to solve the problem.
With the agreement should be the same as with the sprints in Scrum. A person who has committed himself to do something just has to do it. It's simple!
Summarizing, what was said about the reasons for the breakdown of the agreement:
- A promise is not a guarantee.
- Control is difficult.
- The failure is detected in fact.
It is clear that you need to do: just create strong arrangements that are easy to manage, and finally go to the Bahamas.
Captain obvious
In other words:
- As Is - now the system looks like this: quite fragile arrangements that are difficult to manage.
- To Be - should be: unbreakable agreements, the management of which is transparent and not time consuming.
For the standard situation of the GAP analysis, “To Be” is the ultimate goal to which we aspire, but not the fact that we will reach it. But we must strive.
It remains to understand what is a solid agreement and how to manage it.
Lasting agreement
Strong agreement - these are real obligations that are made with an obligatory person. It is very important. We talked about obligations, as about some package that needs to be passed, and now we'll talk a little bit about the carrier of this package.
Agreements made with an optional person lead to inconsistencies. If you present the work in the form of a flow of agreements that are sent in different directions in packages, then when you are trying to make an agreement with an optional person, be prepared for the fact that with a 50% probability you will lose time. Therefore, the first thing to start with is to increase the price of the word.
Word price
Each of your colleagues should ideally understand that servicing obligations is his main job. This is the essence of his work. The written code, the rolled out release are derivatives of the fulfilled obligations. Therefore, I try to talk to people about obligations and that the problem is not that the code is not written or there is no result. This is a consequence and a big pain. But the essence of the problem is that, by making a commitment, we did not find a way to fulfill it.
If you have never talked about this with people, then this, in general, is not so obvious. I suspect that in order to talk about this, it may be necessary to first run through the ladder from the beginning of the report “result - work - action - agreement” and back. But people need to convey the idea of nuclear agreement and commitment, about the fact that the agreement is an obligation, and the obligation, if made, is practically indestructible.
The funny thing is that if you succeed in getting this across, be prepared to reduce the number of agreements. You will be much less likely to promise anything. You tried to make the arrangements work, but in the end, instead of 10 promises, you will have only 3. True, the good news is that they are practically indestructible.
Increasing the likelihood of each commitment, we reduce their number.
This is natural, because people can not cope for objective reasons - everything can not be done. Reducing the number of obligations is normal, but they will be really strong.
It remains only to figure out what is generally capable of engaging a person in such a bondage of obligation, if it cannot be further violated.
There are several reasons for this, but the real one is an employment contract : "I promised you to do this, because you pay me money for it."
Opportunity is a prerequisite, but not a guarantee. If a person cannot fulfill an obligation, he will not fulfill it — quite obviously. This is the criterion to follow.
A wish- this is the main reason. I have long powdered your brain just to bring a simple idea.
A person will do what he wants and will not do what he does not want.
Our task, if we really want to create solid agreements is to involve a person in the implementation of each of them.
Bison Bridle
There is a simple rule from the book “The Law of Raspberry Jam” by J. Weinberg, which I really like - a bison for a bison. The author writes that he had a friend who planted bison. These are healthy, poorly controlled animals. Even the fence does not help much to prevent them from going somewhere. When Weinberg asked his friend how he dealt with the bison, he replied that he had a bridle, which consists of two parts:
- Bison can be taken anywhere, if he wants to go there.
- Bison can not be allowed anywhere, if he does not want to go there.
Although this is practically a quote from Tony Robbins, this makes sense. You are not a nanny - not a person who goes behind the back of his subordinate and controls his every step. In an amicable way, you should let him go and wait for the result. You do not have and should not have a control panel, but most likely you have one for each subordinate. This should not be, a person should do everything himself . For this, he must want.
There are three more things that are important to add so that the bridle is strong:
- The arrangement is formalized.
- Man is involved.
- The content is worked out.
Formalization
Formalization is a protocol by which we agree and need to be set up once, make sure that it works, and simply check that it is not moving away.
We must agree that the arrangement never changes unilaterally . The change of priority, which came to Vasya, cannot be the reason for changing the agreement unilaterally.
It is necessary to report about change instantly that it was possible to reconsider the arrangement.
With the possibility of revisionconnected thin moment. I believe that the agreement can be revised, although this may be a loophole: a person made a commitment, and then he says that he does not cope and asks to postpone the term. In fact, the person involved will not use this loophole, but, on the other hand, he will have the freedom of action and the understanding that he is not cornered. A person needs flexibility, because the only chance to fulfill an obligation is when a problem arises, to find the right solution. Fulfillment of commitments in an unstable world is always tacking.
Of course, the obligation must have a content and deadline.. Content is an expected, “tangible” result. For example, in the case of a change in behavior, this is a process that is worked out. In an amicable way, an agreement on behavior change should not consist in changing behavior, but in passing through some process of changing it. It may look like this:
- Come on, you will arrive on time!
- Come on.
But it can be different: “Listen, I need you to come on time. Come this week, right by the hour, I'll be waiting for you in the workplace with a cup of delicious cappuccino at 10:55. We will mark you daily on the blackboard on time or not. ”
I will wait for a person who must learn not to be late, with coffee 5 minutes before the start of work - this is not sabotage, but a bribe, but this is different. Thus, we will have: a plan of action, control and evaluation criteria.
Then commitment — this is important — refers to passing through this plan, and not ephemeral behavior change.
How to involve people?
This is the most important question that rests on everything: how to involve a person? I have 4 questions on which I build my speech when I need to agree on something:
- Why do I need this?
- Why do you need it?
- What happens if you do?
- What happens if you don't?
Questions can go in different sequences. As a rule, I run over them in advance. The main thing is that as part of my speech to the person, I am ready to answer all four of them .
Before the conference as part of a thematic coaching, Alexander Ziza put a footboard on me and said: “You know, in a good way, you don’t need to answer these questions to people, they have to answer them themselves, and you just think how to contribute to this!” The topic of the next report, I have not yet figured out how to do it.
In fact, I'm not very sure that it will work for any person of any level. So far I have been using this as follows. When I ask a person to do something, I explain why it is for me, why it is for him, and what will happen if done and not done.
The answer to the question "Why is it for me" in my understanding gives meaning to the whole agreement. If I just ask a person to log time, this is one thing. If I explain that I want on the basis of this to try to understand what type of tasks gives the greatest error in the assessment - this is completely different.
The answer to the question “Why is this for you?” Sometimes sometimes rebuilds the entire agreement, because it must be for some reason needed by the person with whom we agree. If he does not understand why it is for him, then the bison will not go anywhere - the bridle does not work. Sometimes I have to reformulate the task so that it is also beneficial to the person. This can be represented as a manipulation or sale, but in fact it is just a reason to think about how to make the agreement mutually beneficial .
Summing up, how to work with arrangements:
- We involve the performer.
- We work with him content.
- At every opportunity, we inform you that the essence of the work actually relates to the fulfillment of obligations, and nuclear quality for an employee is an obligation, that is, the ability to maintain obligations.
- We cultivate the "price of the word" at all angles. Let the best commitments be less, but they will be strong.
In the beginning, you can make a register of agreements, up to a plate in Excel, to forget anything: who, what, content, term. But this is not necessary, now I no longer lead the tablet.
What to do with violators?
It is important to remember that the breakdown of an agreement is simply a consequence, and the violation lies in the fact that the person has not revised his attitude to the obligations and their significance. And this means that he could not change while ...
How long should I wait? How many chances to give? I believe in the rule of three points - it never let me down: the first time is an accident, the second is a coincidence, the third is a pattern.
It is important that after each “point” you need to talk to a person, explain the importance, draw perspectives in the end. And the intervals between “measurements” need to be made significant - after all, it is a question of changing behavior. But if the “third point” happened, instead of the question “What to do with it?” The question arises, “To put up with it or not?”
And this is already a personal choice of everyone ...
But the choice to go to TeamLead Conf or not, in my opinion, is obvious. Moreover, the program is almost ready. But you can choose Moscow in February or Peter in September, and subscribe to the newsletter, not to miss new videos and articles, the opening of Call for Papers and key dates.