Eva Belyaeva, Security Vision
Introduction
We have already told you how difficult it is to make friends with developers and AppSec, security guards and colleagues from IT. This time, let's look at what difficulties can arise within a company when people with different approaches to work interact: strategic and operational.
To simplify, we will reduce the analysis to the analysis of the main conflict within any project activity – between those who set tasks and those who implement them. Simply put, between management and subordinates.
Such things happen in companies of any orientation and size, and judging by what colleagues from other organizations tell me, the situation is systemic.
Why is this a problem
Very often, when setting a task and discussing the result, there is a discrepancy between what is desired and what is actual, and both sides of the dialogue cannot hear and understand each other.
Perhaps if one of the opposing sides can put himself in the other's place, then the intensity and degree of negativity will decrease slightly, and it will be possible to better understand the interlocutor and adjust his work in a more productive way.
After all, when we talk about strategy, we mean far–reaching plans, promises and money. Global goals, without which the company cannot just develop and grow, but in general, exist and maintain staff.
The operating system is somewhere lower, where a seemingly simple task becomes overgrown with the tinsel of smaller tasks and decomposes into smaller subtasks, each of which can stall the entire process.
Let's look at examples of how such situations arise and what can be done.
Work conflicts
If you have ever attended a meeting with acceptance and delivery of work, you have definitely come across what happens after: subordinates, in case of failure, leave upset and continue to wind themselves up in the smoking room and in the kitchens.: How come we spent hours, weeks, and days overworking, exhausted, and all for nothing? At the same time, at the meeting itself, the management openly expressed their attitude to the problem: you had the main task, you spent a lot of time and for some reason you did two others instead, what's wrong with you?
As a result, everyone suffers: those who waited for the agreements to be fulfilled on time, wonder what went wrong and why these performers fail their tasks over and over again, while those on the other side burn out and either give up trying, or put more and more effort into it. where, in their opinion, they are most needed (but, unfortunately, not where they are expected to go).
Yes, all problems most often arise from a lack of communication. But the fact is that not everything can be said every time; sometimes people rely on the so-called implied domain: what by default should already be accepted by both sides. For example, a supervisor thinks that the following is obvious: if he has assigned a special priority to a task, it should be put first and the contractor should promptly report any problems. The employee has a different idea: for example, in no case should you make it clear to the top that something is going wrong.
Despite my position, I often find myself inside the same routine and operating system – when you and your team are trying, but up there they don't understand why it's so slow or why it's so bad. But due to the specifics of the job, it is often possible to look at the situation from the outside and understand where you are wrong. Sometimes it turns out to see these moments of our own failure and broadcast it to the team, bringing it back to reality: we really screwed up and that's why we are misunderstood. Let's take a closer look at such misconceptions.
Common mistakes
The problems of performers can be divided into two main vectors: when they overdid it and when they underestimated it. Often, a conflict develops when the behavior was built on two of them at once.
For example, a performer has a big and difficult task. Yes, he had just been told that this task had the highest priority. At the same time, there are three more tasks in his backlog for this sprint, but simpler and with a lower priority. How does the problem start? The performer starts with a big task and realizes that he is at a dead end. For some reason, he is ashamed to say this, but responsibility does not allow him to sit idly by. What does the supervisor think this performer should do by default? Of course, escalate the problem higher and signal that he needs help. But the performer is afraid to let down the management, he worries about his position in the company... and so he takes on three other tasks in order to get at least some result. As a result, the performer is calm inside himself: although he did not complete the first task, he is still competent and was able to complete as many as three others in such a short time! And he doesn't understand why people are unhappy with him. Yes, the task was important and he was told about it, but aren't they all important?
Another problem may arise when the performer really focuses on the main task, but to solve it he needs to cope with a dozen side tasks: for example, request the necessary access or debug one place in the code that cannot pass unit tests. Yes, he usually spent less time on such tasks, but now something went wrong. It can be anything, and it's not always a problem with the competence of a particular performer – perhaps the task was not properly structured or its real scope was not taken into account when setting it. It may also be that the performance of this particular task clings to several previous ones, and if they were poorly done, then you will have to spend time refactoring everything there, and only then return to reality. What happens when you turn it in? The manager will hear that "the task is not ready again," and for him it is absolutely not transparent and not completely clear – they promised to complete the task, everyone agreed on the deadlines, but at best I will present him with half, and even that is not working. And a lot of time was spent, and for what? Not even for other tasks. At the same time, the performers are exhausted, overloaded, and over and over again they discuss among themselves and cannot understand why they are not understood. Why can't they see their load? And they continue to demand more and more from them, not seeing how hard it is for them.
Well, the third type of conflict is when the position of "do well" begins to argue with the position of "just do it." Let's assume that both previous mistakes were made: at first, less important tasks were done instead of the main task, and when the big task was started, it turned out that everything was not so simple, and instead of a week, it stretched over two months, with overwork. The head, for his part, changes the introductory ones: you do not need to have time to complete the task in its original scope and formulation, the deadlines will soon burn out completely, and you need to close the task somehow. The performer, who is used to rigid and detailed acceptance, is perplexed and sees some kind of trick in this: he thinks that if he does not do the task perfectly, it will not count, the new statement can be ignored and continue to do the old way. After all, he wants to do his job efficiently, even to the detriment of deadlines, because he considered it more important.: How can we ship something of insufficient quality? The conflict is growing. The management softens the requirements, but still does not get results. The performer is exhausted, but he can not deliver his work in any way. In the end, everyone is unhappy.
We facilitate and communicate
As can be understood from the examples, often a "bad" or "wrong" result, paradoxically, can be caused by a desire to do the best. And if you get into the operating system and look at tasks that way, then you can even agree with this.
But if you look a little higher, it becomes clear that this activity did not take into account the global goals and even the roadmap of the company: without a strategy, it is not clear why this task is important, and this one is not very important. Why can this part of the time checks be neglected, why would some task not need to be processed at all if you didn't do something "wrong"?
Increasingly, when we see such conflicts at the start, before they flare up to a fire, we try to convey the importance and exclusivity of the task as clearly as possible; at each stage we try to help those who are afraid or shy – and help to monitor the situation, to find out if help is needed and if there is a problem that we They didn't take it into account. Moreover, it is interesting that it is not necessarily the young and inexperienced who are afraid to talk about the problem – those whose results could previously be unconditionally relied upon and know that a person is reliable and consistent can behave in this way.
It works both ways – if you don't tell the management exactly why it was hard and difficult, they won't understand it. In our company, every employee, to a greater or lesser extent, still works with his hands, despite the position. This allows you to understand for yourself why the process works the way it does, and what went wrong with the subordinate – you yourself step on the same rake or see flaws in communication or task setting. This experience provides an opportunity to speak the same language and add a little practice to the strategy.
Conclusions
There are situations at work when we unknowingly set each other up for the best of intentions. The first step to avoiding this is to imagine ourselves in the other person's shoes and see what the real purpose of our tasks is. The second step is to make the interlocutor understand the subtleties of his work and motivation as transparently as possible.
If you talk about problems as soon as they arise, do not be afraid to report difficulties – over time you will be able to find a common language and become more productive without having to recycle and burn out.