I often come across development teams from large companies. But despite the different principles of the device, profiles of activity and technology stacks, everywhere are employees dissatisfied with the current state of things. Particularly distinguished characters do not like everything! But the only real step beyond the conversation that they are capable of is dismissal. True, in most cases this does not come to this - the characters simply constantly complain about the “galleys”.
Have you ever wondered where "legs grow" from here?
Let's start with a story familiar to many ...
Imagine that you are changing jobs again. The reasons for this all can be very different. Perhaps they offered you good money, bribed a gym with a pool, tea with buns or “interesting tasks”.
Having successfully passed all the interviews and technical tests, you get your offer with the treasured six-figure sum. You have already liked your future colleagues at the interview by telling a couple of jokes, and you, overwhelmed with enthusiasm, are waiting for your first working day in a new place and, possibly, in a new position.
The long-awaited day begins with a half-empty open space in one of the classic office centers of your city. Half-empty, it is not because your new colleagues are on vacation or are sick, but simply because you arrived at work on time. After drinking the first cup of free coffee and having a modest amount of cookies, we try to start the working day. We get access, set up a working environment, set ducks, magnetic cubes and wait for our first task.
Nearby we notice another colleague. The list of his actions is similar to ours, perhaps, with the exception of ducks on the table. Apparently also new. Come, get acquainted, shake hands. Our new colleague's name is Larry (an unusual name for our latitudes, but still). Larry is clearly sleepy, does not shine with enthusiasm, but with whom does not happen, right? Perhaps Larry is not feeling very well or other thoughts are bothering him ...
Three months pass. Long, tedious three months trial period. During this time, we managed to gain a little insight into the project and its processes. Larry also passed the probationary period. A couple of times you went to the canteen for lunch, and Larry seemed like a nice guy.
Work on a large enterprise project is always a difficult matter. A numbed stack and mossy processes. At first, understanding the task takes a lot of time and causes phantom pains .... Six months have passed in a new place. All this time we have been solving different, but at the same time, tasks of the same type. They do not cause interest and do not bring pleasure. Such tasks are simply the work that needs to be done. But each time a gag happens in these tasks. The same "rake" is faced by colleagues, which makes their life a little more difficult.
Larry solves similar problems, except in a slightly different area. He carries out his work in good faith, but at the same time, Larry has an unpleasant trait. He loves to poke and certainly mention the “damned galleys”. At the same time, Larry is still a glorious fellow. As a man, he did not become worse and did not open on the other side. However, every time a conversation comes about why Larry calls the current place a “damned galley”, he only complains that he does not like absolutely everything. He can specify the moments, but this must be requested separately. Usually everything ends with a banal “everything." And there is no doubt that he is confident in his words, because once Larry even tried to quit (although there was no particular reason for this).
And yet, why the “galley"?
If you try to figure out what is happening with a colleague, an interesting truth will open. Larry believes that he is not able to influence the workflow. From his point of view, he cannot help himself and others, because he "has no time to think about it." Every day he is busy scooping up the routine; the rest is no longer strong.
Larry is a glorious fellow. The reason for his unwillingness to change the picture around him is simple: he does not want to enter into conflicts. Life taught him that to adapt and to poke is easier than changing everything around. To change the picture for yourself means to come into conflict, to prove your point of view. And Larry is a nice guy. If you prove, argue, change, you cease to be a nice guy for those who previously were happy with everything. “Do you need more than anyone else?” Larry is afraid to hear it. To be a nice guy, Larry sings to himself the song: “It’s not worth bending the workflow under us, it’s better we will bend ourselves.” And he creaks, bending under a changing world. He creaks like an old grumpy old man Plyushkin, who instead of washing the floor in his cluttered the palace is better once again to scold life around.
I do not understand this position. If you do not take extreme and completely inadequate cases (well, anything happens), the question arises: how can you do what you do not like, but never think about how to stop doing it without being fired? After all, in fact, Larry does not interfere with all the work, but its individual details, which can be completely corrected ... if you stop whining.
Everyone can influence work processes. This does not require a special talent or position. Many people think that this is not possible in all teams - for example, working on behalf of a contractor on a project of a large customer, you certainly will not change what is happening. But this is not so. Your leaders are smart people. Improving department processes also benefits them. Yes, of course, all situations are different, but in the vast majority of cases there is a way out of such “process dead ends”. Even during the time that I received my modest experience, I managed to influence the work processes of the department, being just in the mentioned position of the contractor.
Now for the examples!
Since I am engaged in testing, I will give examples from this area.
You can even influence all sorts of little things, and this in itself will improve the perception of work. Suppose you can influence how you write commits or comments, how test documentation is created, and how the testing team interacts with analytics and development teams. First of all, I would recommend paying attention to minimizing the labor costs of routine operations - ways of writing standard documentation, selecting or creating test data, etc.
But do not try to change the whole world in one day. And even more so do not do it alone. If the project is large and modular, then when conducting complex work, it is necessary to request the support of people from third-party subsystems. A typical enterprise is large, branchy, and complex, so trying to figure out your module takes a lot of time. Therefore, you should not try to understand third-party systems as part of weekly work; it is better to ask colleagues for help. In the end, you deliver a single product and should not be at odds with each other.
On the whole, getting in a positive mood is easier than it sounds. It is enough to think what constructive actions will correct the situation. If there is no 100% confidence in them, you can consult with colleagues in person, and then make proposals to your immediate supervisor - face-to-face with a cup of coffee or in retrospect.
By the way, the correct one, i.e. constructive retrospective is one of the main mechanisms for improving processes. It should not be based on emotions and “boiling over” - such a retrospective cannot be effective. Yes, everyone will say that colleagues from another department put sticks in the wheels, understand nothing at all, and all the problems are from them. This will give the team some reboot, but as soon as the next task enters the work, the pain will return and we will be back to the original. Retrospective must be meaningful. Solve specific problems with specific methods. All decisions made retro must be fixed in the rules of the department and take effect from the next day.
It is difficult to say how much I managed to influence the processes at one time, but somehow the situation changed, and it became more comfortable to work. A set of rules and requirements has appeared. There are more clear requirements and differentiation of responsibilities. The work has become more measured and safer at the same time - both with handbrake and with automation. For example, in the latter, we introduced clear requirements for writing code and tests to unify the approach. Thus, it was possible to resolve typical issues that might not be understandable to the team, since we do not have the opportunity to constantly engage in automation.
How to break the “dead end Larry”
Back to our story. Larry is not constructive. He is naughty, aching, getting on the nerves of others, but does not offer real actions to improve processes. All of us are sometimes like Larry, but at such moments it’s better to refresh your head, reboot and think about how to fix the situation. There is always a way out, in addition to dismissal or a radical change in the type of activity. We all want comfort in work and in the team. And if we work constructively and collectively towards improving processes, then all this is achievable.
Periodically, I am in the place of Larry. Perhaps I do not understand what I am doing or why. Or the task develops in such a strange way that the more I plunge into it, the more frustration. The “Miologingen's monologue” from the Matrix comes to the rescue. "Cause and investigation…". The cause of zapara is not a task. The reason is the workflow. A change of place will not help in changing the process, because in interviews it is very difficult to understand the essence of work processes. It is worth trying to work with colleagues and working together to improve the situation for all of you. You are all interested in this.
Have you managed to change processes for the better?
Author: Dmitry Masters
PS We publish our articles on several sites of the Runet. Subscribe to our pages in VK
to learn about all our publications and other Maxilect news.