About making sustainable decisions or a case club on Habré

    Three years ago, by the will of fate, I ended up in one Volga 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 had never encountered before - neither before nor after.

    Adults are known to learn from specific experiences. Actually, education theorist David Kolb on this subject even came up with a cycle named after himself, which underlies many seminars and trainings. Therefore, in a standard coaching case there are several dozen exercises and cases, the main purpose of which is to make sure that the students did not succeed or did not succeed. This is not done with the aim of mocking the audience (although some trainers do not miss this opportunity), but the main goal is to launch reflection and come to the necessary concepts and models together, in order to later test and fix them in practice.

    So, at that training in the Volga city there was one student 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 time to time to propose the right, sustainable solutions to difficult situations. The current managers sitting nearby were mistaken as they should, and Nikita decided everything - the solver.

    By the end of the first day, I was already burning with impatience to find out what was happening! Maybe the person worked for a long time as a CEO and then returned to the engineers? Well, it doesn’t happen - it is impossible without experience to solve complex management tasks.

    As it turned out during the evening beer, Nikita has long been playing World of Warcraft (I can confuse it, since it’s not a specialist in games, in my opinion, it was still Warcraft). Moreover, it plays on servers where people come together in large teams. It turned out that Nikita has been leading a very large group of players for a long time. Persuades to unite in some groups, solves conflicts, makes decisions, etc. Since this has been going on for many years, the person simply developed the practice of making managerial decisions - not at work, but in the game.

    I was cruelly disappointed. I almost opened the pill, how to become an experienced manager, and you have again many years of practice, again you have to work. On the other hand, this story once again confirmed the thought of Captain Evidence that cats can learn. 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 some real-life stories faced by real managers. Each of them made a decision, someone right, someone not. Now we will have the opportunity to get into their skin, tighten 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 - at the end there is a question. Take a break to think. I wonder what and how you would do in this situation. And then check the decision in the second half of the article. (If you don’t want to train your brains, you can immediately go to the second half of the article). If the decision seems controversial to you - write in the comments. It will be great if we finalize these decisions.

    Go!

    Case "Choose our solution!"

    Once in a major 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 for performance.

    As a result, at the next meeting there was something like this dialogue:
    - Colleagues, we sat here and wrote scripts to run benchmarks!
    - Oh, and we wrote such scripts!

    The head testing manager (let's call him Sergey) immediately got a headache, whose scripts to choose, so as not to offend anyone. In fact, the scripts did the same thing. But since proactivity and benefit were taken into account in the upcoming certification, both teams wanted to get a plus in the column “Proactively completed tasks”.

    Well, Sergey said, let's compare the scripts. How to compare? Need metrics. Teams started discussing metrics and comparing scripts. And in two days they did not advance on this issue. It turned out that in the metrics of team A their scripts win, in the metrics of team B they win.

    Exactly what happened when the rules begin to be invented after the game. You want you to win by the newly invented rules. 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 keep them together (to grow together, that is). Here it should be noted that the scripts of team A were written in Perl, the scripts of team B in Shell scripts. Crossing a snake with a hedgehog was entrusted to two engineers from each team. The poor people spent a day on the phone so that the reduced porcupine began to work.

    What happened next. Then the scripts passed on 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”).

    As a result: several days of work of engineers and managers are lost, and de facto one of the two options is still selected.

    Question: what was necessary to do to the testing leader Sergey at the moment when the teams brought him the scripts written?

    (DON'T LOOK BEFORE YOU DO NOT IDENTIFY YOUR DECISION)

    Case No. 1. Decision.

    At one time, I caught the eye of an excellent book by Robert Townsend “Break the system! The cure for managerial heartburn. " Avis legendary CEO shared his experiences in brief notes. Which is quite convenient when there is not enough time for anything - and then I found five minutes in a secluded place, sat down and was imbued with Mr. Townsend's managerial wisdom.

    So in the chapter on decision-making, he wrote: “When two of your employees bring you two solutions to the same problem, choose someone else. In this case, you will get at least one person motivated to implement this decision. ”

    What could the test director Sergey do in this situation? It seems to us that there are four important steps.

    Step number 1. To ask: “Friends, who will support these scripts?”Everyone likes to write interesting programs, not everyone likes to support them. With this question, the manager a) would introduce the principle by which a decision is made and b) would select those who are ready for more so that his decision is made.

    Like the old story, remember? The company director needs to choose whom to send to the conference. Wishing 10 people, the budget is only for two.
    - Who wants to go to the conference?
    - (10 hands)
    - but the results of the conference will need to hold a master class for his team ...
    - (pair of hands is omitted)
    - And the conference will be held on the weekend ...
    - (A couple of people fell off)
    - And then it will be necessary to work on weekdays ...
    - ...
    - And the company will pay only half ...
    - (Two hands remain)
    - Yes, by the way, the conference will be held in Las Vegas, the road, hotel and entertainment at the expense of the company.

    Step # 2 (if both teams are ready to support scripts). Just picking someone alone - tossing a coin, for example. This is also a principle. But by doing so, he would have shown that not only proactivity is important, but also the speed of decision-making and that the work and speed of obtaining results is more important than a showdown about who will be counted.

    Step number 3. Announce that both teams will receive the classification test.

    Step number 4. Discuss with the teams how to make sure that such collisions no longer arise.

    It seems to us that these four steps could a) save time for making a decision b) make the decision more stable (those responsible for the scripts would support the code they wrote c) show the principle of decision making in order to minimize mutual insults and precipitation from the situation.

    If there is something to supplement the analysis of this situation, or objectively argue, we will be glad to see your opinion in the comments. If you had a similar situation at work - share the story, together we will supplement the case and the base of its solutions.

    PS We are now launching the case club of our School of Managers, where such cases (both ours and from your practice) can be discussed by the entire case club community. Plus analysis, 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 a branch of a case club on Habr. If the idea appears interesting, then we will try to make this initiative on Habré constant.

    PS In the next article we are thinking about talking about the principles of making sustainable management decisions - what to look at, what to analyze. And how to behave in such a way that the wolves are well fed and everyone else is safe (as much as possible, especially when choosing the lesser of evils). And the case will be the case when the leadership threatened to dismiss a half-team for not giving up the project.

    Also popular now: