In search of an answer to the question of how to make people more responsible ...

    Quite a frequent request from fellow managers, which you hear: how to increase human responsibility?

    It would seem that mankind for thousands of years of its existence should have come to some kind of algorithm for increasing responsibility. And here he is, your coaching chance - spell out this algorithm and change forever the life of a single manager!

    However, life is becoming more and more complicated ... We have to deal with boring clarifications: now how do people work? “Well ... irresponsible.”

    Hmm, it doesn't get any clearer. I want to sarcastically clarify: “I mean, they abandon their wives and children?”, But in reality, you begin to understand.

    Everything seems to be simple. The information sponsor of all habrastats Wikipedia gives a fairly clear definition of responsibility :

    Responsibility is a person’s personal characteristic that describes his ability to thoroughly analyze the situation, predict in advance the consequences (the whole complex of consequences) of his actions or inaction in this situation and make a choice of the form of his actions with a willingness to accept the consequences of the choice as inevitable fait accompli.

    However, I'm afraid I became the second person after the author of this Wikipedia article who read it - why read it, if it is so “intuitively clear” what responsibility is, many managers will tell me?

    As a result, each manager has his own definition for each “intuitive thing.” And for some reason, some managers believe that the people around them should telepathically consider this mess as their own definition and immediately begin to behave “as it should”.

    Let us return, however, to the irresponsible behavior of employees. The most common transcripts of this term that I have come

    across mean: 1. A person does not report problems that he should report. (Either passes by, or tries to decide for himself something that does not need to be solved by himself.)

    2. A person promises to do something, but then does not have time and five times shifts the deadline: "there is just a little left, tomorrow it should be ready."

    These are clearer requests and there is something to recommend.

    Situation No. 1. A person does not report problems that he should report. (Either passes by, or tries to decide for himself something that does not need to be solved by himself.)

    As we already discussed , if a person does not do something, there can be one of 4 reasons for this:
    • Fuzzy goal (doesn't understand why)
    • Can not
    • Can not
    • Does not want

    In a discussion with a person, it would be nice to walk for these reasons and understand what is happening:

    Fuzzy goal:
    Does the person understand that there is no need to go past problems? Or does he conscientiously believe that this is not part of his work?

    Doesn’t know how:
    Can a person understand which problems he must solve himself, which ones do not need to be paid attention to, and which ones need to be escalated? Does a person have all the necessary knowledge to make the right choice?

    As a matter of fact. Was there such a moment in the work when a person worked the way you want? If he was, then he knows how - then what has changed?

    Can not:
    How is it with the load? If the work of three people is now hung on him, it is rather naive to believe. that he will still take two hours from sleep to solve additional problems.

    Does not want:
    If the previous three reasons are closed, then here we come to what he generally wants as a person and the selection of arguments for his conviction .

    Situation No. 2. The person promises to do something, but then does not have time and five times postpones the deadline: "there is just a little left, tomorrow should be ready."

    Without going into the techniques of project planning and task assessment, about which we have already talked about , we will draw the next 2 by 2 matrix:
    image
    On one scale, we have postponed the criticality of tasks, and on the other, clarity. (A separate question is how to measure the comprehensibility of a task; we will move it beyond the scope of this article.)

    Intuitively, we usually choose the following order of tasks:
    image
    While the most obscure tasks introduce the greatest uncertainty in the project timeline. It is from there that one can come up with something that we did not calculate at the planning stage.

    That is, the general recommendation is to go in a counter-intuitive order:
    image
    Starting with the most obscure, but critical tasks. Starting with them at the beginning of the project, we still have a large temporary buffer for responding to changes.

    An example is not from IT. Some time ago, SlavaPankratov and I launched in parallel 20 online training programs in various fields. This happened 3 times a year. A team of 20 experts worked. Our task, among other things, was to collect information from them and create 20 announcements.

    The first time we started with the announcements of our five programs, leaving the most incomprehensible in the end. As a result, sleepless nights before release. And what’s the most annoying - last night you won’t wake the expert with your stupid clarifications anymore.

    Not the first time, but we came to the conclusion that we began to start with the most incomprehensible announcements. This is categorically unpleasant, because it contradicts our nature (first you need to eat a delicious cake, and then a tasteless liver patty - can I not eat it at all?) But in that case we had only a few days to ask all questions to our experts. And lo and behold, by the last night before the release, everything was already ready for a long time.


    The second commonly encountered point is the wrong type of control. To control such tasks, we choose a random (when we recall) or preliminary type of control instead of periodic or phased. In a nutshell, without delving deeply into all types of control:

    Preliminary control is when we check the execution of a task near the end of its term, leaving a temporary margin for correction. (The size of the temporary stock varies, but usually not too large.)

    In this case, in science, the preliminary type of control is used for tasks that the contractor has already successfully done, and when the chances of success are great, but we still want to play it safe.

    In the case of incomprehensible tasks, we use:
    • Periodic type of control (control at regular intervals). A typical example: scrum rallies or daily meetings. Or:
    • Phased type of control , when the work is divided into semantic stages. And we check what happened at each of the semantic stages. Example: 1st stage: prototype, 2nd: implementation of basic functionality, etc.

    Example. For example, after 2 weeks the technical director comes to you for which you need to make a presentation of the architecture of your project. You assign this task to the architect of your project. As usual, he says to “managerial tasks”: “So what is there to do? No question! ”And leaves.

    A preliminary type of control is that you decide to look at the presentation a couple of days before the arrival of the technical director. And just you will have a couple of days to remake everything yourself.

    But if you have ever seen how technical people can draw presentations (and most importantly, you have not seen how your architect draws presentations), you will choose a different type of control:

    Periodic: “Look, the task is critical, they will evaluate us according to it. And you and I have not done such tasks before. So let's meet every couple of days, watch what happens there? ”

    Or

    Step-by-step:“ Look, the task is critical, they will evaluate us according to it. And you and I have not done such tasks before. Let's beat it into stages, for example, the structure of the presentation, then the diagrams, pictures, then the slides themselves? ”

    (An attentive reader will note that we discuss the type and frequency of control immediately. This is done because we may not control all the other tasks of the architect at all - he does them perfectly. And the person could get used to the full confidence that is expressed in him in lack of control, and here the task is new, we will start to run to him every two days, and for the second time he will hate us.)

    To summarize, the problem of lack of responsibility among engineers always requires specification. (Your K.O.) And as soon as they are concretized, then the decision comes by itself.

    PS If you had any of your problems with the responsibility of people and you overcame or did not overcome them (problems), we will be glad to read your experience in the comments.

    PPS In general, on the term “responsibility” there is an excellent presentation by our colleague Sergey Dmitriev, where he discusses the concept of 5 islands of responsibility avoidance:


    Also popular now: