Self destructive behaviour within a team is probably one of the biggest inhibitors of people and teams reaching their full potential. In a nutshell the main loser is the employer. A bold statement, but fear stops people from trying something new and breeds a culture of uncertainty, causing teams to worry too much about making mistakes. But what happens if the team isn’t even aware they are doing it and how can we break them out of this trend? It is a topic I have pondered recently, in the office I will rarely stick on a pair of headphones, I put this down to my natural tendency to be nosy, as I like to know what is going on at all times. I also love to people watch, just listening to others conversations can help you appreciate why some problems are occurring in a business and also help you propose solutions. Through listening to office conversations, I have noticed a very common theme in teams that are deemed to not be as “high performing” as others and that trait is the use of “negative language". Aside from the more obvious chestnuts such as “I don’t have time to look at this as I am too busy”, “not our teams problem”, “not our priority” and constantly saying “no” which are often associated with teams passing the buck, blame culture or not caring about the business as a whole. I have noticed a general tendency for those teams to use negative language in their daily operations within their team, while "higher performing" teams use it less and it isn't the norm. Is this a coincidence?
What do I mean by negative language? So teams that use negative language generally report that they have “multiple issues” or “problems” when reporting to management or senior management. This is in my mind is overly focusing on the negative aspects of a problem, such language suggests that the team has encountered an absolute blocker and that there are no solutions to the problems or alternate solutions. Or so it would seem, when prompted these individuals or teams normally tend to have solutions or alternatives but they aren’t focusing on this aspect. So why are those teams and people reporting issues in such a negative fashion and why are they generally being very vocal when doing it? Do they not see it lays the foundations for a negative team culture? At times those reporting the issues also seem happy that they have discovered the said issue, even gleeful when they report it. This is the main point that baffled me, are they really happy something is failing? So it made me question a few things....
So let’s look at a scenario, a new joiner joins a company and sees their line manager reporting problems to senior management in a loud and vocal way. This manager is viewed as the benchmark or measuring stick, so it sets a precedence for that teams behaviour, as the manager is viewed as the team's role model. To climb the corporate ladder, the junior or mid level team members view this as the normal way issues should be reported, as their role model behaves this way and one day they want to be in a team lead or in a manager position too. So when junior or mid level engineers discover issues they tend to be happy or gleeful that they can report this up to management, as they see it as adding value and warranting their place in the team. In truth they aren’t happy about finding the issue, although it appears that way to outsiders, instead they are happy about finding issues as it is considered “adding value” to the team by their management. Now this makes more sense....
Lets take a step back and look at the effect of this type of behaviour and why it is actually destructive. Being so vocal about problems in reality makes other team members worry that if they create an issue or do something wrong in the team that it will be loudly reported too. This psychologically causes the team not to take risks and play it safe to avoid the indignation of having a mistake loudly reported to senior management. Immediately a negative mindset has been established in the team that “problems” are reported loudly and always focused on vigorously. This will hardly encourage a team member to experiment or try something new, instead the individuals in the team will be scared of things going wrong and being the cause of an issue. Consequently, It does the polar opposite to what a “DevOps mindset” aims to do, which encourages team members to share their failures or things they have tried. This means issues are covered up in the team or hidden for fear of the embarrassment that failure would bring. It does little to encourage openness, knowledge sharing and transparency. Healthy teams should learn to talk about successes and failures in equal measure as there is a lesson to be learnt from both, some would argue more so when discussing failures.
I am not for a moment suggesting we don’t talk or highlight “issues” or “problems” to management but when explaining to others it would be more productive to focus on “alternate solutions” or “potential solutions” rather than stop at “issues” or “problems” which make them sound insurmountable or something to worry about. Problems are commonplace in technology and should be treated as such, I haven’t met an insurmountable issue yet, there is always a solution to every issue even if some are not initially perfect. It is important for management to illustrate that teams will have issues and problems daily but they need to be dealt with, but do so in a productive and positive way. The use of negative language and apportioning blame to other teams by team leads or managers tends to trickle down to junior members of the team who inherit the same language and behaviour which is very damaging. The use of negative language tends to make teams very negative towards problems, fearing the worst, escalating them quickly with the tendency to panic under pressure. This in turn will cause the escalation of small problems up the management chain rather than remaining positive and calm and solving them without shouting them from the rooftops as this has been seen as a way of “adding value”. It also sometimes makes sister teams doubt the engineering capability of that team as they don’t view them as a team with any answers and a team that reacts badly to problems as this is the image they perpetuate.
Adding value should focus on fixing the problem and solutions rather than reporting it. I once had a manager that said to me that everyone's job is to make your direct manager's job as easy as possible, not more difficult, so escalating problems should be seen as the last resort. In practice escalating every issue up to senior management is not productive, and leads to a similar situation as the boy that cried wolf, as when you have an actual issue that needs dealt with it just seems like more white noise. Dealing with failure is what makes us all better engineers, so without problems or failures we cannot learn or improve so they should be seen as a natural learning experience and not something to fear. I think a lot more can be done by team leads and senior engineers to correct the use of “negative language” or “blame culture” in their team on a daily basis. So for every “problem” replace it with a “numerous potential solutions” and try and keep calm and set an example to your team.
One of the main virtues of a "DevOps mindset" is to operate without fear of failure and this will give workers the freedom to be creative and try new things. It will also make for a better working environment and happier workers which will in turn move your team into the “high performing” space. It will nurture new ideas, knowledge sharing and openness that will slowly help the team improve. Enough is enough, it’s time for a positive change, so the next time you are about to be negative in front of your team please think about the consequences. Instead be calm, try and put yourself in a new graduates position, other teams shoes and see things from a different viewpoint. Only by considering a different viewpoint, can we understand why people are behaving in a particular way. Only when we have a full understanding of that viewpoint and the motivation for the behavior can start to help them change their ways.
No comments:
Post a Comment