Two worlds or "engineers have something to say." About the various types of complex tasks and processes associated with them

    I think the heads of the IT departments will agree with me that sometimes it seems that we are on the border of two worlds living according to different laws, in different temporal rhythms, and we have to live in both these worlds. And if we broadcast the “way of life” from top to bottom, from senior managers to engineers, by virtue of our official duties, we perform it regularly, but in the opposite direction - alas ...

    Therefore, this post about what I, as an engineer, want to say our dear managers and those who consider their “way of life” the only true. :)

    Planning, Gantt charts, “following the process,” discipline, deadline, schedule, “I don’t explain the same thing twice,” “I don’t have time, it means I’ve planned badly” ... - familiar things? These are the entities and methods of the “world of managers”. It is clear that somewhere more, somewhere less and generally simplification, but it is not about this world. He is certainly important. His methods work great in many things. But there is a huge layer of tasks where none of this works, but something completely different, sometimes the opposite, works.

    I will explain my thought.

    All complex tasks can be divided into two classes. I will call them English complex and difficult. From the names it is already more or less clear what this is about, but I will formulate it.

    Complex task is a task consisting of many elementary subtasks. Elementary in the sense that the result is known, methods of solving are known, the amount of resources they require and the time to complete them. The complexity of the complex task lies in the fact that it requires, for example, the participation of various people, specialists, teams and their actions must be coordinated, but each specific action is completely understandable and predictable. A good example is building a house. And here the receptions of the “world of managers” work perfectly.

    But when we talk about an difficult task, this is a task with an uncertain result, and this uncertainty can be to the point that it is unclear whether there is a solution, and if there is, what it is, how much time and resources this task will take. This is a study. In this case, it is not about creating a fusion reactor, but about the daily in the “world of the engineer”.

    New software, new feature, new bug, setting up new equipment, building new architecture, testing new solutions, creating a new product ... It is not necessary that no one knows this. It is enough that it is not known to the team and it is not so easy to find the documentation.

    Of course, the “world of the engineer” consists not only of this, there are complex components here, but this is an essential part of it, or you are not exactly an engineer.

    And in this world, completely different processes work. And it is important to understand. Here are some examples of what methods work when solving difficult problems.

    • the engineer needs to dive into the task. He can not be distracted every 15 minutes. Sometimes, a dive can be so all-consuming that it can not sleep or sleep badly, “suffer” the task for several days or weeks or months. This is an important quality of a strong engineer. He cannot calm down until he decides. He needs to be given time, given the opportunity to concentrate and, possibly, exclude for a while from various periodic processes.
    • in these conditions it is strange to demand from an engineer that he strictly live according to a schedule. And this is understood at the research institutes (at least where I worked), they understand this, for example, at the Physical and Technical Institute - both there and there is a free visit.
    • it is clear that the word “discipline” in solving problems of this type here already has a different meaning. This is not even a discipline, but rather a passion. The creative process, brainstorming, discussion, interest in the result - this is the glue that replaces discipline in solving this type of problems.
    • it is clear that all time dependencies here are also significantly weakened, it is difficult to insert a difficult task into a strictly regulated time process
    • not how smoothly (with observance of all conventions and procedures) the task is performed, but simply the fact of solving the problem is encouraged. Words like “you stayed for 2 days” should not be used here. If deadlines are important, then you just need to decide at what point to stop and not spend more resources.
    • You can not judge a person for the fact that he could not solve the problem. Even a very strong specialist can go the other way and he can spend a lot of extra time. In many ways, the solution of such problems is a search of options, and not the fact that you quickly choose the right one.
    • If an engineer is stuck, you cannot leave him alone - you need help from either the leader or the whole team.

    A completely different world, right?

    Does this mean that you can’t plan at all? No, it does not mean. Usually, it is possible to estimate the probability of accomplishment and time, but this is only a probability and only an estimate.

    Does this mean that anarchy should reign in the department? No, it does not mean. In the department, of course, the processes of complex tasks that are in the department and in which the department participates should be observed. And it is the task of the leader to be able to combine these two worlds.

    In order to skillfully solve difficult problems, serious skills are needed. Usually, this is an innate ability and love for such tasks, plus perennial (usually from childhood) training (problem solving - mathematics, programming, “picking” in the computer ...). And I believe that only an engineer with the skills to solve difficult problems can be a strong engineer. And during the interview in our department, we looked for just such.

    The ability to solve complex tasks is more accessible. Here, too, the tendency of character is important, but if this tendency is there, then mastering skills is not so difficult.

    You can be quite a successful manager at your hierarchy and not having the skills to solve difficult problems. There are many such positions. But the real leader in the IT world, I think, will be difficult.

    That's why.

    • such a manager often does not understand, and that’s why he doesn’t appreciate people who are able to solve difficult problems. So, he will not have strong engineers.
    • the manager certainly has to solve difficult problems in the general case. For example, be defined with goals, or create working processes. This is a difficult task. The trouble is that the manager may think that this is simple, due to the fact that he does not see the depth of the problem and creates goals and processes on the fly, but upon detailed examination they do not work.

    A strong manager is a rare combination of these two worlds. Usually, people either go to one or the other.

    If the world of difficult tasks is closed for you, then I would advise you to learn how to love and appreciate a team from another world and this world will thank you.

    Also popular now: