personal experience and a couple of tips

personal experience and a couple of tips

Hello, Habre! My name is Danylo Starosek, I work as an analyst on the “Unified Frontal Solution” (USS) project at RSGB-Intech. In the previous material, I described the main reasons for the appearance and development of burnout at work, in my opinion. Today I want to share my personal experience in solving these difficulties and overcoming my burnout riders.

Not understanding what needs to be done

Not understanding what needs to be done or what the goal and task is directly facing the analyst. In my case, I had to take the initiative and deal with a considerable amount of documentation on my own, talk to many colleagues, ask about the idea of ​​the project, where it came from, the prerequisites, why it turned out that way. From these small goals, it became clear how to set more global ones: quarterly, half-yearly and annual. The goals of a stage become clearer when all the background is known.

When I understood the purpose of the stage, I began to do my own defragmentation and set myself tasks that I could realistically complete by this deadline. With this understanding, you can make a summary, understand the idea, determine the global goal, put all the pieces of the puzzle into a complete picture and break it down into subtasks.

Hyper responsibility

The next rider is hyper responsibility. In conditions when it is not clear what needs to be done, you do what you are asked, because of which you are torn between many tasks and errands. You go where you are asked or where the task manager drives you. That is, you go in different directions and nowhere do you get any significant results. That’s why you get the idea that you’re not working well, you’re not doing much, you can’t see the results of your work, and deadlines are pushing you. As a result, the thought appears: “I let everyone down.”

Sometimes it is worth stopping a little, taking a breath, looking around and acting more calmly. The whole company does not stand on one person, and responsibility must be shared. For example, wait at least 5 minutes from the moment of receiving a message from colleagues, reception with a short delay in response is a useful prevention. I tried and it turned out really wonderfully that you don’t answer for 5 minutes, and often you get a second message: thank you, I already figured it out myself. I’m certainly not telling anyone to ignore work messages, chats, etc. But it really happens that when you answer everything and everything to every question, delve into the task, then people get used to it and are too lazy to figure it out on their own.

Deadlines

I partially described the next rider in the first paragraph in terms. “What to do” is quite closely related to “when to do”. When I came to the company, the deadlines had already been violated. Analytics and testing were not carried out in the project, but the acceptance tests were supposed to start in two weeks.

The entire temporary shift, unfortunately, remained after six months of work. But positive dynamics are still observed. Previously, no one was concerned about the factors affecting the delay: changes in requirements, long team formation, etc. “There are deadlines, we once set them, they must be fulfilled!” Gradually, it was possible to reach out and achieve the fact that if the requirements change, the terms also change, that is, it is estimated in what time frame it is possible to make this revision. The fulfillment of certain quarterly, for example, or half-yearly goals is also reviewed, and everyone has started quite adequately before that. There is such a thing as a project triangle. I think everyone is familiar with him. It is impossible to do more work without sacrificing quality or time. That’s why the deadlines slowly began to be equalized, and it became very comfortable to work.

Area of ​​responsibility

The next rider is the area of ​​responsibility. The area of ​​responsibility was outlined, one might say, automatically. When you start to understand what needs to be done, you take responsibility only for the work that really needs to be done by you. Without an understanding of the whole picture, there is no understanding of the tasks, everyone around you tells you “what to do” and you do it. If you’ve figured it out, then it’s not so easy to let you go. You clearly understand and can explain that this team should be responsible for this part, because it is they who develop the functionality.

Communication problem

We smoothly move on to the next rider – the problem of communication. In my opinion, the solution to this problem is again tied to the struggle with the first horseman. You begin to understand the project, who is responsible for what, who works how, thanks to which you can agree with the rest of the participants and parallel teams about what needs to be done. We got together, synchronized, agreed and are moving forward together. If there are any issues that we need to solve together, we only meet with the colleagues and teams that are needed to solve the problem.

I will give an example. So, we need to invent some kind of solution. Let’s gather everyone and everything! As a result, everyone gathers at once, meetings last for hours, many people switch off from this conversation and switch to other work, remaining in the conference. Someone is completely uninterested and bored, because these questions do not concern him at all, he just sits and wastes time. It is much more effective to meet in small teams for 5-10 minutes. You spend less of your time = company money, and the conversion to usefulness of such meetings is much higher. I would also like to note here that my specific progress is that earlier in our team, I had no idea how to make a planer in half an hour. But after working out the problem, they learned to invest in 5–15 minutes.

No result is visible

You can’t see the result and you don’t feel the benefit – another, no less nasty rider of burnout. Here I would like to emphasize the importance of conducting a quality retrospective at the end of the sprint. A good retrospect allows you to remember your merits: what you did and what turned out great, what was not so great. And then you really feel the result. You can close only one task instead of ten in two weeks, and you think: how bad is everything, why did I do something for two weeks, why such a weak result?!

In retrospect, you realize that in reality there were much more tasks. When you prepare for a retrospective, you run through each task, remember what you did, what result you achieved, and understand the value of your work. You realize that it was not done just like that. The task may not be closed, because it was initially estimated too optimistically, but in reality it turned out to be much more time-consuming. And there is nothing bad or terrible in this. It is impossible to predict everything at once, especially when working with a heavy and new system. Accordingly, I recommend that everyone conduct mandatory retrospectives and thoroughly prepare for them: review their tasks, results, what happened and how rich and fruitful the work was.

Run ahead of the locomotive

The final item on my list of reasons for burnout is quite trivial – running in front of a locomotive. This is when you can get ahead a little, and parallel teams participating in the project lag behind. Or you within the team have already done everything necessary, but the team is slowing down for some reason. You get upset, well, let’s hurry up!

And here I developed two approaches for myself. The first is to dive a little deeper into the work of developers, testers, offer help to colleagues and generally be interested in the process. Do not come with the words “what are you doing here”, but really understand why, for example, nuances may arise. The second, more organizational, is the early construction of a plan for the team as a whole, drawing up certain steps and distributing tasks. That is, when we take on the next task, you will already know a lot about it, orientate the whole team and help to work faster and more efficiently.

In conclusion, I can say that for me, all of the above was really useful and very effective. In my current state, I want to work, enjoy the tasks and move the project to a successful conclusion. With the use of the techniques described above, pleasant results began to appear, the climate in the team and in the project in general improved, and the deadlines became more adequate.

Thanks to everyone who read. As last time, please share your methods of combating burnout in the comments, and you can also mention the reasons.

Related posts