High-performance teams: why the leadership mindset makes the difference!
High-performance teams: why the leadership mindset makes the difference!
Real-life example:
The days of September were over. Also, the days of summer vacation were well behind, but not for Mike. He was a developer in an Agile team, working on a top importance project. It was agreed that he will take some vacation days when all his teammates will return from sunny beaches, in October. Now, finally, his time for some days off arrived.
He was working on an important user story and, not surprisingly, he was really stressed to finish everything before leaving for vacation. Putting a lot of effort, he managed to complete the story late in the evening. No one was in the office anymore. He wrote an email to the team and left for his vacation happy that “he left everything in order”.
The next day, when the team checked the story’s implementation, they noticed that it was crashing many automated testes. They tried to fix the code, but no use. The more they modified, the more tests would crash. After a few hours of frustration and bad feelings, a team member decided to start again the implementation, checking the code that Mike left behind.
It took a few days of hard work until the story was ready to be demonstrated. The manager of the team received many suggestions to have a “hard talk with Mike”: he should never leave things like this. Maybe a punishment “would make him more attentive in the future”. Gladly, the manager understood deeply fundamental attribution error.
Fundamental attribution error
Fundamental attribution error is a term introduced by Lee Ross in 1977 and defines the tendency to exaggerate the role of people’s personality when it comes to their behavior and overlook the influence of the wider context. A simple example: let’s say you have a meeting with someone and the person is late.
Usually, we jump rapidly to the conclusion that the person “does not respect the time of others people”, “s/he is not good at time management”, “s/he is not a serious person”, “s/he does not respect colleagues/customers/partners”, or “s/he does not care about [topic of the discussion]” etc. On the other hand, I don’t know about you, but me, when I am late for a meeting, I always have all these external factors that kept me from being on time: a car accident on the highway, an urgent call from a friend, the previous meeting went overtime, etc.
So, when it comes to situations with a negative impact, there is a tendency to blame others when they are the actors. Still, we blame the context when we are the actors. This explains well the “blame culture” existing in many companies.
The leadership mindset of high-performing teams
Looking at the case above, many people would react by blaming Mike. It starts with the team members, which in my view are leaders also, considering the shared model of leadership in Agile teams (check my blog on Who are the leaders of Agile teams and WHY?). It continues with Mike's manager. Let’s assume that Mike’s manager thinks that the root cause has something to do with Mike’s personality, a problem that needs to be addressed. This scenario continues with two alternatives for the chat with Mike:
Mike takes full responsibility. He understands that he needs to avoid at any cost getting in similar situations. In this state, it becomes so easy to decide that: he will try to avoid high importance tasks, he will not waste more time helping others, he will make sure to overestimate a lot to be certain he has more time.
Mike was at the top of his attentiveness, what can be done more on that? He did the best he could, still, things go wrong. Maybe, he should not care that much...In many cases, this leads to emotional disengagement. Will any of these actions really avoid similar cases in the future in the company? Will this mindset lead to having a high-performing team?
Mike gets into defensive mode, throws the ball of blame to someone else: someone else left the tests on red before him and he did not know that he was causing the problems, the tester of the team refused to stay late in the evening to test things out, it took him so long because another colleague was late in completing a task he depended on, the Product Owner missed something in the acceptance criteria and told him at 18:20, he helped another colleague working on a fatal bug, he had to attend all the top management meetings scheduled for that week, etc.
The fastest way to destroy a team is to start the blame game under the fear of punishment because once started, it is hard to stop it. Having this approach erodes the psychological safety inside teams which is argued to be the main factor of high performing teams and trust in organizations overall (Google study 2015 - "Project Aristotle").
It generates in waves a culture where every time something goes bad, the first reaction of leaders is to search for a scapegoat and release a punishment. The natural consequence is the constant fear of not making any mistake and when bad things happen, on finding quickly someone else to blame or hide it. So many insights on this topic can be found in Simon Sinek’s highly inspiring book: “Leaders Eat Last: Why Some Teams Pull Together and Others Don't(2017)”.
No matter what is written in the company’s stated values, culture is shaped by the way leaders behave, regardless of what they say. Schein states in Organizational Culture and Leadership (1985) that organizational culture is shaped by five behaviors that leaders exhibit, consciously, or unconsciously. One of these 5 critical behaviors is the leaders' reaction to critical incidents or organizational crises which is fast learned by the other members. The way the leaders react is the way “we do things in this company”.
Addressing the team’s context
Teams that understand fundamental attribution error are able to tackle differently these situations and are focused on building the right context, the right system, in which people are well protected and their humanity embraced. It starts with understanding deeply that if it happened to Mike, it could happen to any well-intentioned, engaged team member. The situation becomes a great learning opportunity for the team who can take a step back and ask themselves during Retrospective:
What can we do as a team so that this situation will never happen again in the future?
I witnessed teams coming together and unleashing a wealth of creative solutions which in fact take the team practices to the next level and improve the system:
user stories should be split into smaller ones so that no one works individually on a story for a week or two
code needs a peer review before being committed
all automated tests need to be on green before merging to the main branch
a clearer Definition of Done (DoD) stating that code needs to be tested by someone else in order to consider it Done
the performance of the automated tests needs to be improved so that everyone could run them fast at any moment in time
pair programming more often
when someone leaves for a vacation longer than 5 days, they need to remind the entire team during the Daily Scrum and another team member volunteers to spend at least one hour on any needed handover
task rotation needs to be practiced consciously so that the team can handle urgent problems in case of unexpected days off etc.
Good Scrum Masters are able to facilitate workshops that result in concrete actions to be taken at the team level. The learning process is also an iterative one in the sense that teams are challenged to find better and better solutions: What happens when a team member gets sick and misses work for two days? How about two months? What happens if the tester of the team is that team member?
Addressing the organizational context
If fundamental attribution error is your default reaction, you might catch yourself thinking now: “aha, so it is not Mike’s fault, it is his team’s fault!”. This is called group attribution error, fundamental attribution error extended to groups. Someone who is part of the team can clearly emphasize the context, the external factors that have affected the team in this case.
But someone else, a manager outside the team or a member of a different team, will usually jump quickly to conclusions regarding the team’s attitude: “they don’t care about the customer”, “they are not reliable” or, even worse, “they are not to be trusted”, “they need close control and checking”.
That is why trying to find solutions without the involvement of the team members will result often to wrong alternatives because the context is not understood. Still, it is never easy to be a manager who chooses the “no blame” approach in a company with a deep blaming culture. When, as a manager, your boss wants to know “who?”, explaining your decision can quickly result in the conclusion that the person to blame is you, “not capable to manage your people”.
It could be argued that managers who understand fundamental attribution error are more inclined to hold a Theory Y style (considering that people are internally motivated in their work and put their best efforts) , instead of Theory X style (people are not internally motivated to work, therefore reward and punishment is needed) according to Douglas M. McGregor(1960). Having a Theory X style while reporting to a manager with a Theory Y style becomes an act of great courage and true leadership.
It could be equally argued that this situation happened because the external context of the team was not appropriate:
Maybe this is a company where there is no emphasis on caring for people. People should not be encouraged or even pushed beyond a human limit, like not taking a vacation for many months when working on an important project. There is no need to have a deep managerial experience to know that doing this will open largely the door for bad things to happen.
Maybe the team had huge time pressure. This is so often the case! It may come from a culture that rewards overpromising, management who commits on fixed scope, fixed time, or management who is not considering estimations of the team.
Maybe the servers on which the automated tests are executed are overloaded and because of a cost-cutting strategy decided by top management and despite the team’s efforts, they still take too long to run.
Maybe in this team, the manager assigned individual targets (even the Product Owner) and all the other team members were assigned on different important tasks, without any slack time.
Maybe the culture of the company rewards individual effort only, there are many subtle messages that everyone should do “their part” and helping another colleague commented by managers with “this is not your job”.
Maybe there is no official support in this company for automated testing/code quality actions including refactoring because the decision-makers do not still completely understand the value of it. Or, maybe the Product Owner has constantly taken out of the Sprint Backlogs the technical tasks because “we don’t have right now time for this”.
Methods like the Five WHYs have the power to reveal the root cause if blame is always taken out of the exercise. Still, it is worth reflecting that problems can have multiple root causes, some problems show up in different teams and then solutions need to be taken at the organization level, meaning management involvement is required. Great Scrum Masters/ Agile Coaches/ Agile Managers/Agile practitioners are able to facilitate, observe, understand so that improvement actions are taken also at the organization level.
The key question for psychological safety
These types of situations are able to uncover big holes in the system and provide great opportunities to make the necessary improvements that will eliminate the root causes of the problems. That is why these situations are often called “growing opportunities”.
Not being able to learn from them could be called “learning waste”. When leaders across the company have a deep understanding of fundamental attribution error, they stop the automatic blaming mode during a crisis situation and start focusing on improving the system and learning. This soon becomes evident that there is no need anymore to invest energy into watching your back.
The psychological safety goes up and mistakes are uncovered and fixed quickly. A measurable sign that this is happening can be obtained by asking the survey question (used by Google):
How confident are you that you won’t receive retaliation or criticism if you admit an error or make a mistake?
Confession
I have been Mike. I will never forget that 24th December when too eager to solve a bug, I sent a PL/SQL patch to the client and then ran to my manager saying: “I messed things up”. Gladly, I did not have the credentials to install myself the patch directly into production, which I would have done, and therefore I was able to still enjoy a Happy Christmas! Good system.
I have been the colleague who stayed to help out late in the evening and the colleague who left because someone was waiting home. I have been sometimes the colleague who saved the day and been called an “angel”, but also the one who blamed or jumped to judgments. I have been Mike’s Scrum Master and Mike’s manager. And yes, I know how it feels to see Mike going home after being fired.
All these experiences showed me that it is hardly ever someone’s individual fault: good people, with good intentions, sometimes get in trouble because the system is far from perfect, still, the best we knew to put in place. I also know that the blame game has no winners and that only when the blame tendency disappears, when everyone decides to step out from the blamer role, high performing teams have the context to emerge.
About:
Roxana supports IT Executives to leverage the Agile mindset and the latest management research to achieve Strategic Business Agility. Her fully customized approach includes the right mix of Agile Management Training and Consulting, Executive Coaching, and Mentoring. Read more about the Agile Business Transformation services, focused on Agile Management, Transformational Leadership, and Startup Profitable Growth at MastersWhoCare: Uncovering better ways to lead and serve.
