Illustrations by Maria Rybak
Recommendations of the team member, project manager, Scrum master.
This article was created together with , at JMind, and at JMind.
The way we treat our employees, our words, and even our intonations all affect people's efficiency and their desire to work with us. According to a study by , stress in the workplace leads to an increase in voluntary staff turnover by almost 50%. It is often not caused by working conditions or complex tasks, but by interaction with the management.
At the university, during courses and training, we are often told what and how we should do in a particular position, and how to act in a given situation. But they rarely say what not to do in terms of human relationships.
And this is what we want to talk about with colleagues from , part of the holding, in this article: what not to do or tell your team if you want to create a healthy atmosphere in the workplace.
We work in different positions: CPO, Scrum-master, team lead. Our tips and stories complement each other and will be useful for all managers — from leads to CTOs and those who plan to take these positions. We look forward to your experience in the comments.
Tips for Project Manager
Don't tell a person how to do his/her job
Any specialist, including a developer, is hired for his knowledge and skills. Your key task is to establish interaction between people with different skills and stay on another level of abstraction. Don't teach each of them what hard skills should be used and how, because their skills are probably better pumped than yours in this particular task. A task completed on time — that’s what should be in the first place.
If you know some subtle tricks in writing a piece of code or a better library and it can help a colleague, share the knowledge as recommendations, but not as instructions. And even better — in the form of the question: "what do you think about using this?"
Don’t try to assess the complexity of the task before you hear the developer’s opinion
Even the developer can underestimate or overestimate the complexity and time required for the task — and he/she certainly has a deeper understanding of his/her capabilities. No manager can know all the competencies of his team, especially if the team is cross-functional.
Therefore, even if it seems that you know better, listen to the opinion of those who will be directly involved in the task, and then you can set an estimation.
Do not take all the credit and do not blame the subordinates for mistakes
The leadership position requires the opposite. In case of success, it is important to emphasize that this is thanks to the team and everyone made their impact to get great results. If something goes wrong, take maximum responsibility for it, so you understand how to more effectively organize the process in the future.
Do not punish for mistakes, especially even if it’s the first time
We at JMind and other TECHIIA teams even have an unspoken rule: do not pay attention to the first mistake in the task. There are no experiments without mistakes and great performance without experiments. We would rather praise for the courage and draw productive conclusions rather than point the finger at instructions.
Another thing is when an employee makes mistakes systematically and not because he/she tries something new. But even in this case, do not start blaming. Employee’s error is closely related to manager’s error. Find out if this particular person can handle this task or if he/she has enough resources. Whether you and your colleague equally understand the task and whether it is clear for both of you. Always remember: be sure to specify all points in the technical assignment.
Also, I recommend not to omit the big picture (helicopter view) and the reasons for making certain decisions — even those that seem insignificant to perform the task. Set an example — justify your decisions. This will help minimize mistakes and improve interaction inside the team.
And do not inflate the situation, do not bring all the negative. It is necessary to show the team that there is a way out even from a difficult situation.
Tips for the Scrum Master
In any position when working with a team, the same topics are relevant: the organization of processes, the atmosphere in the workplace, the feedback, and how it should be given. I am guided by the Scrum principle, but these tips are relevant for any methodology.
Never punish your colleague in front of everyone
In case of an incident, do not look for a wrongdoer. Fix the problem first. It is better to analyze mistakes with those who are responsible for them when mistakes are fixed.
Hold the negative feedback till a face-to-face conversation. Even if the emotions are booming. Public flogging kills professional creativity and divides the team for "victims", "rescuers", "persecutors". Do not build the foundation for toxicity.
An emotional negative feedback, either face-to-face or in front of everyone, is a no-no. If the employee is aware of his/her mistake, your raised tone will only drive him/her into more stress and stop from making a healthy professional conclusion. And no one would be eager to have any kind of conversation with you, because of that you can easily switch to personality.
As for kudos, the general meeting is the best place for them. Everyone would be glad, especially those who have objectively invested in the team's achievements. Do not flatter, just list the facts and sincerely say thanks for the contribution. This creates healthy competition — provided that you have sufficient authority as a leader.
We are all humans, do not forget about it
The developer is not only the working hands but also the individual with his/her own interests, problems, and circumstances. They can affect performance in different ways at a particular time. Sometimes it can be helpful to inquire about things outside of work to redistribute the workload, ask HR for help, and support the person.
Don’t micromanage
Hypercontrol and too much intervention lead to two troubles. The first is that your colleague will most likely only be annoyed by your constant control. Because of this, he/she will give you a crude solution so that you can detach later. It is also unlikely to improve your relationship.
And the second problem is that when constantly getting into the little things, you risk taking away the developers’ responsibility for the quality of work and drowning in routine and operation. The team will stop creating solutions on its own, everyone will follow your instructions.
Do not think that the motives of your behavior are clear to everyone. Always justify your position and decisions
One day after the next Backlog Refinement, the team unanimously said that the task is clear and N story points are needed for development. It wasn't until later that it became clear that the Product Owner and the team understand the terms differently. The tasks were implemented as they were understood, and this turned out to be not at all what was meant in the conditions.
It is essential to lay out every detail. We may spend a few extra minutes, but as a result, we will save days or even weeks.
And always, always remember your promises!
Tips for the Team Lead
Do not label employees as superheroes
Be ready to help each and every one of them. Sometimes even experienced people face difficulties that seem impossible or time-consuming. In some situations, synergy and mutual support have a positive effect on the performance of individual colleagues and the team as a whole.
We had such a case. One of the colleagues worked on the task much longer than usual, I wondered whether everything was ok, and he said “yes”. This went on for some time until he told me that we had a problem.
I had to dive into the situation. After studying the problem a bit, I concluded that I do not know the solution. But it seemed very close. I tried to be constructive, I learned what attempts and approaches have already been used. We had a pair programming session where we found a solution in a short time. He and I both did a great job. And what was more important, I helped him to relieve the anxiety that he does not have time to complete the task.
Don't be too critical and don’t over-praise
Constant constructive dialogue gives a clear understanding of the basic needs and mood of employees.
Recently, one of my colleagues offered to implement some innovation in the project. Unfortunately, he did not consult and instead of consultation, he came to us with a specific implementation. To most team members, it seemed excessive and untimely. They suggested postponing its use or trying to find a more elegant solution.
Instead of taking the team's decision as a basis and consolidating it, I decided to support my colleague and try to motivate him to find a better solution. But he made the wrong choice. The discussion turned into a heated argument, we spent much more time than the situation required. As a result, a slightly disappointed initiator and annoyed colleagues.
In controversial situations, it is better to resort to a reasoned opinion of the team. And suggestions and improvements should be discussed first, noting the initiative. And only after that, it can be implemented, taking into account comments.
Avoid the increase of personal and work conflicts. But they should not be ignored either
In disputes, good decisions are born, but in-person disputes are time bombs that can break the team. Pay attention to cases when the discussion goes beyond professional boundaries and loses its constructiveness. Take a retrospective of disputes and create a clear mechanism for resolving such issues.
As a preventative measure, collect, analyze and pass feedback from the team on time. It is important to keep in mind that not everyone is ready to personally express their opinion about colleagues. Especially when working online, when it is difficult for people to build relationships and directly express opinions about other employees. Here your task is to be a facilitator and build bridges of trust.
Do you have any other tips to add to our list? What cases made you have your own Dos and Don'ts?
Articles and materials on the topic:
- Jurgen Appelo —
- Patrick Lencioni — .
- Igor Mann —
- Daniel Pink —
Original article on: .
