About making sustainable decisions or a case club on Habré
Three years ago, by the will of fate, I found myself in one Volga region city with corporate training. Then for the first time I learned that people in IT companies can come to work by 8:30, and then I had a story that I never encountered again, either before or after.
Adults are known to learn from specific experiences. Actually, education theorist David Kolb even came up with a cycle on behalf of himself , which lies at the heart of many seminars and trainings. Therefore, in a standard coaching briefcase there are several dozen exercises and cases, the main purpose of which is to make sure that the students do not succeed or do not get to the end. This is not done in order to scoff at the listeners (although some coaches do not miss this opportunity), but the main goal is to start the reflection and come together to the necessary concepts and models, then to test and fix them in practice.
So, at that training in the Volga city, there was one listener in the group (let's call him Nikita), who clicked all the tasks like nuts. At the same time, Nikita was not a manager. But this did not prevent him from once in a while to offer the right, sustainable solutions to difficult situations. The current managers sitting nearby were mistaken as necessary, and Nikita decided everything — a solver machine.
')
By the end of the first day I was already burning with impatience to find out what was happening! Maybe a person worked for a long time as a general director and then returned to engineers? Well, it does not happen - it is impossible without experience, to solve complex management problems.
As it turned out for the evening beer, Nikita has long played World of Warcraft (I can make a mess, since he is not an expert in games, in my opinion, it was Warcraft). And it plays on servers, where people unite in big teams. It turned out that Nikita for a long time led a very large group of players. Persuade to unite in some groups, resolve conflicts, make decisions, etc. Since this has been going on for many years, the person has simply developed the practice of making management decisions - not at work, but in the game.
I suffered a cruel disappointment. I have practically already opened a pill, how to become an experienced manager , and on you - again, many years of practice, again you have to work. On the other hand, this story once again confirmed the idea of Captain Obvious that you can learn from cats. The main thing is to do it regularly.
And today we would like to offer a small workshop. Well, just reading the article is boring - and thinking is more interesting!
This week we are thinking of publishing a few real-life stories that real managers have encountered. Each of them made a decision, someone was right, someone was not. Now you and I will have the opportunity to climb into their skin, strain the brain and train the muscle to make the right decisions in working with people.
How to do it? Read the description of the situation - in the end there is a question. Take a pause to think. You figure out what and how you would have done in this situation. And then check with the decision in the second half of the article. (If you don’t want to train your brains, you can go directly to the second half of the article). If the decision seems controversial to you - write in the comments. It will be great if we will finalize these decisions.
Go!
Once in a large software development project, a funny story happened. Two testing teams (working in different cities - A and B) performed proactively and, without telling anyone, wrote scripts to run benchmarks on performance.
As a result, at the next planning meeting, there was something like this dialogue:
The head of testing (let's call him Sergey) immediately had a headache, whose scripts to choose so as not to offend anyone. In essence, the scripts did the same thing. But since the pro-activity and the application of the benefit was taken into account at the upcoming attestation, both teams wanted to get a plus in the column “Proactively done tasks”.
Well, said Sergey, let's compare the scripts. How to compare? Looking for metrics. Teams started discussing metrics and comparing scripts. And two days are not advanced in this matter. It turned out that according to the metrics of team A, their scripts win, according to the metrics of team B - theirs.
Exactly what happened when the rules start to come up after the game. You want the newly invented rules to win you. If you lose - obviously, the rules are not fair and do not take into account some key thing.
After two days of vivid discussions, Sergey made a strong-willed decision: the scripts are equally good, let's szhimim them (let's grow together, that is). It should be noted here that the scripts of command A were written in Perl, the scripts of command B in Shell-ovsky scripts. Two engineers from each team were entrusted to cross the grass with the hedgehog. The poor people spent a day on the phone, so that the mixed porcupine began to work.
What happened next? Then the scripts passed to team B for support and forgot about this terrible dream. As it turned out six months later, the engineer from team B cleaned out all the other pieces of code from there (“it’s easier to maintain”).
According to the results: several days of work of engineers and managers have been lost, and de facto one of two options is still chosen.
Question: what should the testing manager, Sergey, have to do at the moment when the teams brought him written scripts?
(DON'T LOOK NOW, DO NOT DECIDE YOUR DECISION YET)
At one time, I came across an excellent book by Robert Townsend “Break the system! A cure for management heartburn. Avis' legendary CEO shared his experience in brief notes. Which is quite convenient when there is not enough time for anything - and then carved out for five minutes in a secluded place, sat down and imbued with the managerial wisdom of Mr. Townsend.
So in the chapter on decision making, he wrote: “When two of your employees bring you two solutions to the same task, choose someone else’s one. In this case, you will receive at least one person motivated to implement this decision. ”
What could the testing manager Sergey do in this situation? It seems to us that there are four important steps.
Step number 1. Ask: "Friends, and who will support these scripts?" Everyone loves to write interesting programs, not everyone loves to support them. With this question, the head would a) introduce the principle on which the decision is made and b) select those who are ready for more so that his decision is made.
Like the old story, remember? The director of the company needs to choose who to send to the conference. Wishing 10 people, the budget is only for two.
Step number 2 (if both teams are ready to support the scripts). Just choose someone's alone - on a coin flip, for example. This is also a principle. But by the same token, he would have shown that not only proactivity is important, but also the speed of decision making and the fact that work and speed of getting results are more important than fights about who counts for what.
Step number 3. Announce that both teams will receive the test.
Step number 4. Discuss with the teams how to make such collisions no longer occur.
It seems to us that these four steps could a) save time on decision making b) make the decision more sustainable (those responsible for the scripts would support the code written by them) showed the principle of decision making in order to minimize mutual offenses and sediment from the situation.
If there is something to supplement the analysis of this situation, or to argue with arguments, we will be glad to see your opinion in the comments. If you had a similar situation at work - share your story, together we will supplement the case and the base of its decisions.
PS We are now launching the case club of our School of Managers, where such cases (both ours and from your practice) will be able to discuss the entire case club community. Plus parses, plus the necessary video materials, etc.
If you are interested in joining, we will be glad to see you there (this is a paid project, inexpensive, but paid):
Case Club "System People"
And this week we are thinking of opening such a branch of a case club on Habré. If the idea turns out to be interesting, then we will try to make this initiative constant on Habré.
PS In the next article we will talk about the principles of making sustainable management decisions - what to look for, what to analyze. And how to behave so that the wolves were full and all the others are intact (as much as possible, especially when choosing the lesser of evils). A case will be the case when the leadership threatened to dismiss half of the team for not handed over the project.
Adults are known to learn from specific experiences. Actually, education theorist David Kolb even came up with a cycle on behalf of himself , which lies at the heart of many seminars and trainings. Therefore, in a standard coaching briefcase there are several dozen exercises and cases, the main purpose of which is to make sure that the students do not succeed or do not get to the end. This is not done in order to scoff at the listeners (although some coaches do not miss this opportunity), but the main goal is to start the reflection and come together to the necessary concepts and models, then to test and fix them in practice.
So, at that training in the Volga city, there was one listener in the group (let's call him Nikita), who clicked all the tasks like nuts. At the same time, Nikita was not a manager. But this did not prevent him from once in a while to offer the right, sustainable solutions to difficult situations. The current managers sitting nearby were mistaken as necessary, and Nikita decided everything — a solver machine.
')
By the end of the first day I was already burning with impatience to find out what was happening! Maybe a person worked for a long time as a general director and then returned to engineers? Well, it does not happen - it is impossible without experience, to solve complex management problems.
As it turned out for the evening beer, Nikita has long played World of Warcraft (I can make a mess, since he is not an expert in games, in my opinion, it was Warcraft). And it plays on servers, where people unite in big teams. It turned out that Nikita for a long time led a very large group of players. Persuade to unite in some groups, resolve conflicts, make decisions, etc. Since this has been going on for many years, the person has simply developed the practice of making management decisions - not at work, but in the game.
I suffered a cruel disappointment. I have practically already opened a pill, how to become an experienced manager , and on you - again, many years of practice, again you have to work. On the other hand, this story once again confirmed the idea of Captain Obvious that you can learn from cats. The main thing is to do it regularly.
And today we would like to offer a small workshop. Well, just reading the article is boring - and thinking is more interesting!
This week we are thinking of publishing a few real-life stories that real managers have encountered. Each of them made a decision, someone was right, someone was not. Now you and I will have the opportunity to climb into their skin, strain the brain and train the muscle to make the right decisions in working with people.
How to do it? Read the description of the situation - in the end there is a question. Take a pause to think. You figure out what and how you would have done in this situation. And then check with the decision in the second half of the article. (If you don’t want to train your brains, you can go directly to the second half of the article). If the decision seems controversial to you - write in the comments. It will be great if we will finalize these decisions.
Go!
Case "Choose our solution!"
Once in a large software development project, a funny story happened. Two testing teams (working in different cities - A and B) performed proactively and, without telling anyone, wrote scripts to run benchmarks on performance.
As a result, at the next planning meeting, there was something like this dialogue:
- Colleagues, we sat here and wrote the scripts to run benchmarks!
- Oh, and we wrote such scripts!
The head of testing (let's call him Sergey) immediately had a headache, whose scripts to choose so as not to offend anyone. In essence, the scripts did the same thing. But since the pro-activity and the application of the benefit was taken into account at the upcoming attestation, both teams wanted to get a plus in the column “Proactively done tasks”.
Well, said Sergey, let's compare the scripts. How to compare? Looking for metrics. Teams started discussing metrics and comparing scripts. And two days are not advanced in this matter. It turned out that according to the metrics of team A, their scripts win, according to the metrics of team B - theirs.
Exactly what happened when the rules start to come up after the game. You want the newly invented rules to win you. If you lose - obviously, the rules are not fair and do not take into account some key thing.
After two days of vivid discussions, Sergey made a strong-willed decision: the scripts are equally good, let's szhimim them (let's grow together, that is). It should be noted here that the scripts of command A were written in Perl, the scripts of command B in Shell-ovsky scripts. Two engineers from each team were entrusted to cross the grass with the hedgehog. The poor people spent a day on the phone, so that the mixed porcupine began to work.
What happened next? Then the scripts passed to team B for support and forgot about this terrible dream. As it turned out six months later, the engineer from team B cleaned out all the other pieces of code from there (“it’s easier to maintain”).
According to the results: several days of work of engineers and managers have been lost, and de facto one of two options is still chosen.
Question: what should the testing manager, Sergey, have to do at the moment when the teams brought him written scripts?
(DON'T LOOK NOW, DO NOT DECIDE YOUR DECISION YET)
Case №1. Decision.
At one time, I came across an excellent book by Robert Townsend “Break the system! A cure for management heartburn. Avis' legendary CEO shared his experience in brief notes. Which is quite convenient when there is not enough time for anything - and then carved out for five minutes in a secluded place, sat down and imbued with the managerial wisdom of Mr. Townsend.
So in the chapter on decision making, he wrote: “When two of your employees bring you two solutions to the same task, choose someone else’s one. In this case, you will receive at least one person motivated to implement this decision. ”
What could the testing manager Sergey do in this situation? It seems to us that there are four important steps.
Step number 1. Ask: "Friends, and who will support these scripts?" Everyone loves to write interesting programs, not everyone loves to support them. With this question, the head would a) introduce the principle on which the decision is made and b) select those who are ready for more so that his decision is made.
Like the old story, remember? The director of the company needs to choose who to send to the conference. Wishing 10 people, the budget is only for two.
- Who wants to go to the conference?
- (10 hands)
- But according to the results of the conference, you will need to hold a master class for your team ...
- (A pair of hands is falling)
- And the conference will be held on the weekend ...
- (A couple more people fell off)
- And then you will need to work out the working days ...
- ...
“And the company will pay only half ...”
- (Remain two hands)
- By the way, the conference will be held in Las Vegas, the road, the hotel and entertainment at the expense of the company.
Step number 2 (if both teams are ready to support the scripts). Just choose someone's alone - on a coin flip, for example. This is also a principle. But by the same token, he would have shown that not only proactivity is important, but also the speed of decision making and the fact that work and speed of getting results are more important than fights about who counts for what.
Step number 3. Announce that both teams will receive the test.
Step number 4. Discuss with the teams how to make such collisions no longer occur.
It seems to us that these four steps could a) save time on decision making b) make the decision more sustainable (those responsible for the scripts would support the code written by them) showed the principle of decision making in order to minimize mutual offenses and sediment from the situation.
If there is something to supplement the analysis of this situation, or to argue with arguments, we will be glad to see your opinion in the comments. If you had a similar situation at work - share your story, together we will supplement the case and the base of its decisions.
PS We are now launching the case club of our School of Managers, where such cases (both ours and from your practice) will be able to discuss the entire case club community. Plus parses, plus the necessary video materials, etc.
If you are interested in joining, we will be glad to see you there (this is a paid project, inexpensive, but paid):
Case Club "System People"
And this week we are thinking of opening such a branch of a case club on Habré. If the idea turns out to be interesting, then we will try to make this initiative constant on Habré.
PS In the next article we will talk about the principles of making sustainable management decisions - what to look for, what to analyze. And how to behave so that the wolves were full and all the others are intact (as much as possible, especially when choosing the lesser of evils). A case will be the case when the leadership threatened to dismiss half of the team for not handed over the project.
Source: https://habr.com/ru/post/253262/
All Articles