Team burnout: risk created by leadership

Fengler discusses six factors of risk concerning team burnout: Leadership, institution, team, person, private life and target group. In this article I will focus on aspects for leadership, which push teams into team burnout.

Leadership

Leaders and superiors create a big slice of the personal or team burnout cake, because they frame the context of how people work within their organisations.

Fengler names crucial features of leadership, which push teams and team members in despair: missing knowledge, weak implementation, conflict avoidance, unpredictability, control freak, boundary crossing, excessive demand, oppression of improvement initiatives, contempt for mankind as well as clique. 

Weak leadership

"Burnout" by driver Photographer, Creative Commons 2.0, Flickr

"Burnout" by driver Photographer, Creative Commons 2.0, Flickr

Constant hesitation of leadership influences teams strongly. Regarding a team this might result in intolerably waiting for improvement or decisions. Work cannot be finished or started. Sometimes even already declared decisions which are withdrawn or suspended and lead to waste.

Too often the team is missing support concerning important topics. Teams are not represented and nobody is available to defend team interest on an organisation level.

People feel manipulated and not taken seriously by appeasement. In the end it is the lack of perseverance, which demotivates teams and hinders their progress.

Furthermore sometimes leadership lacks courage to come to an unpopular decision, often because of conflict avoidance. If those kind of decisions are coupled to improvement initiatives, this leads to mediocrity. Teams and organisation get stuck unable to improve and the ethos of work degenerates further.

Overwhelmed self-organisation

"Team should decide" - no matter if competency is available or if the team is interested in the decision. No one cares if the team conflicts on the decision and tears itself into pieces.

Sometimes leadership is unable to deal with conflicts or missing will to take the decision. Then they pass responsibility to the team using the Trojan Horse self-organisation. Sometimes they even name it an act of virtue.

Especially if you work with agile methods and overwhelmed management, management delegates decisions into the team. The delegation of leadership or conflicting decisions often leads to chaos (even sometimes in very mature teams). Such kind of decisions might stress the team on a constant pace.

Sometimes missing competency is driving teams into mental overload. Sometimes majorities change within a team and decisions are challenged frequently. A lot of teams struggle with with a wrong decision and need help with an intervention. Worst case: a team takes a decision and gets overruled by leadership. 

In a perfect world, every team is able to handle every decision they get asked. In real world it's a long dusty road and a lot of team members like to be heard, but just want to make decisions concerning their own profile. For sure teams can learn to handle decisions, even wrong ones. Help them reflect on a regular base e. g. with retrospectives. Be sure it will take some time to earn maturity and endurance to questions theirselves and adjust.

SVNWNK

Source (German only): Fengler 2015: Jörg Fengler, Klett-Cotta Verlag, Ausgebrannte Teams

When teams burn out

Is it possible that whole teams burn out? If you are following publications of psychology: yes, it is. Team burnout is characterised by the dimensions of the individual burnout (exhaustion, decreasing performance, estrangement) and within a team the loss of social cohesion.

Here are some characteristics concerning team burnout (based on Fengler 2015):

  1. Indetermination
  2. Consent without results
  3. Joy about failure
  4. Testiness 
  5. Hostility against other sub systems
  6. Refusal of reflection

Those characteristics are just an extract. Each of them does not reveal per se a team burnout. If appear in combination they might indicate a big risk of team burnout. So take care if some of them exist.

I often saw those characteristics, especially during a change of the way of work (e. g. an agile transition). If you are working with a new team it is usually easy to spot strange behaviour. Most often the characteristics were already in place, during the change they were revealed, reinforced or weakened.

In this post, to stay with the agile example, I will relate to scrum examples.

"Burnout 1",  Dave Wild (Creative Commons 2.0)

"Burnout 1",  Dave Wild (Creative Commons 2.0)

Indetermination

Tuesday, 11:27 a. m., retrospective: The team is discussing a pain point. Despite the pain the team cannot conclude consequences from it. There is no chance towards agreement. The issue silts up and does not get solved.

Consent without results

During the sprint: The team struggles with a well known issue, which the team already decided to fix. The issue and steps to solve it have been discussed and decided in a former retrospective. But no one takes a step ahead to fix it.

It's like the team behaves disconnected from its own reality, unable to maintain its own performance. A gap emerges between the team decision and the long-yearned-for adjustment. Those adjustments are forgotten, dissolve in apathy.

Joy about failure

During the sprint: A server crash, fall of number of bookings, important supply is missing - name it as you want - and the team is delighted. Sarcasm spreads. You hear "did you see how competent XY did this great work" or "if it is offline, at least nobody is able to argue about the usability - that's progress".

If the working atmosphere is soaked by poison, leadership should act. 

Testiness

During the sprint: Thin-skinned, tension, vulnerbility - during a day team members hit the ceiling because of little things. The relationships between the team members are under constant pressure and worn down. The sense of belonging is hurt. Outside of the team room the enemy is everywhere expected. 

Personal contact shuts down. A testy silence spreads. Everybody is afraid of to start a talk. Collaboration sinks faster than a stone. In consequence work gets only partially done or slows down.

Hostility against other sub systems

Friday, 10:28 a. m., daily scrum: One team member is complaining about the poor collaboration of the other department, which are responsible for the operation of the application. Despite of several requests response is missing. The other team members also let of steam. A surprisingly heavy criticism gets uttered. The group identity and cohesion of the organisation gets lost. No wonder that especially component teams, which rely on collaboration, are hostile to each other.

Those refusal between departments is very common. Just to name the classic conflict between development and sales:

  • Development: "they know nothing but sell it"
  • Sales: "they cannot develop something in budget which works"

In case of a dysfunction look out for "win/loose" relationships.

Refusal of reflection

Wednesday, 01:43 p. m., retrospective: A pain point gets addressed. It's something about organisational scope which cannot be fixed by the team but puts it under pressure. From the observing position of a ScrumMaster it is quite clear: there is a problem. On the other hand the team insists that everything is normal, they deny the problem.

The elephant is in the room, still growing and the team decides to ignore and hack the problem as part of their job. It looks like everybody's got one hand tied to his back and nobody cares. In the end the team might loose its ties to the organisation and is no longer capable to get involved with the problem.

Finally

Estrangement destroys the binding towards the own organisation. Emotional retreat is consequence and health is affected negatively. If anger, resentment, fear, contempt or disgust replaces the joy of work then exhaustion and decreased performance might naturally follow, too.

Often people and their relationships are the only glue left that sticks people to an organisation. If this glue gets lost (cohesion) then everybody starts to work on his own, interaction vanishes. The risk of team burnout increases dramatically. The organisation might break apart.

Way out

You can use retrospectives, if you are facing consent without results, indetermination or refusal of reflection. For example you can support the team to stick with its decided actions. Furthermore you are able to show improvement or missing action. Asking in every retrospective about the improvement and value of each action with a starfish scale inquiry is a good idea.

Reflection

You might evaluate your team concerning those questions or discuss them during a retrospective:

  • How sarcastically is our talk? (seldom, often)
  • Are even small tasks perceived as stress? (seldom, often)
  • The team atmosphere is bad-tempered? (seldom, often)
  • Missing follow up for decided actions? (seldom, often)
  • Conflict between other teams or departments? (seldom, often)

SVNWNK

Source (German only): Fengler 2015: Jörg Fengler, Klett-Cotta Verlag, Ausgebrannte Teams

Sprint Planning with: just in time decisions and negotiation

Some time ago I wrote about the Sprint Planning. I said that it’s the last line of defence of your Sprint. Why did I name it the "last line of defence”? Just because it is the last chance to get things out of the way which are not ready for development or blocked. What if the last line is under attack and there are some requirements you are not sure about to discard or give it a try. That’s the time when negotiation comes into play. You sit together think, talk, and test your ideas to tackle it down. Sometimes you get it and sometimes you won't. If you are still unhappy with the results of your discussion, you need to decide how to proceed...

Negotiation and just in time decisions

One thing to negotiate in a Sprint Planning is scope. Another matter is what function really means and how much function is required to solve the problem.

And sometimes there are even a few more decisions to make and unfortunately we are only at the start und need to decide a little bit later, when we can inspect what we built. I’ve got good experience with this kind of scenario:

You’ve got some kind of requirement and it is not obvious how to solve the problem because there are a few (1-5) tiny decisions which seem equal and cannot be solved by discussion. Cannot be solved by discussion means to me that even if we talk about it we circle around or thoughts or people get distracted during the discussion. At this point we give it a try and set expectations about how the decision should be made later on. In other words we postpone decisions, we decide them just in time.

Maturity and decisions

Sometimes there is the question if only real mature teams are able to do this. I would say rather no or yes. I’ve seen both mature and immature teams succeed and fail. To me it is worth to give it a try und to start with limiting the number of decisions to make and to scale how big this decisions are. Even more important to me is to talk about this decisions, to value them and make it a part of our process or to talk about it what went wrong and what to try differently.

SVNWNK

Set the stage with a starfish reflection

© Nevit Dilmen CC-BY-SA-3.0, via Wikimedia Commons

Use this method to set the stage in your retrospective, if you like to get feedback about the actions started after the last retrospective:

Goal: is to connect to actions of the last retrospective and to reflect about it.

Prepare a Flipchart with a table. Each line represents a topic the team decided to try out in the last sprint. Add further columns to the table:"more of", "keep doing", "less of", "stop doing”. 

Now ask the team for reflection and let the team members vote on each row with dot one dot per improvement.

 
TopicMore ofKeep doingLess ofStop doing
Try out TDD oooooo
Try out one piece flow ooooooo

Use the feedback for a short discussion:

  • Why should we stop doing this?
  • Why is it worth to go further?
  • What is really in for us?
  • What is the effort and value?
  • Are our expectations satisfied?
  • Why do the opinions differ that much?
  • Did anything unexpected happen?

Take 3-5 minutes discussion per action.

Have fun :-)

svnwnk

Debriefing - Closing the space

Goals and Setting

Personally debriefing is about reflection, learning, transfer and sharing experience, for a group it is about conclusions, decisions and action.  After an exercise people might reflect on their own - to support them, debrief your session and summarize what was vital to them, what they want to share or they intend to do next. 

Debriefing takes some time at the end of your session, so reserve 5 to 15 minutes. How long it might take depends on the method you choose, the number of questions you ask and the amount of people who attended your session. 

Questions

What to debrief is about asking questions. Before you start your session select the questions you like to ask. Here are my favorite questions: 

By U.S. Navy photo by Mass Communication Specialist 1st Class Monica Nelson [Public domain], via Wikimedia Commons

  1. What was interesting?
  2. What was fascinating? 
  3. What was surprising? 
  4. When did you feel uncomfortable? 
  5. What did you learn?
  6. What of the learned can you use at your workplace? 
  7. What will you make different in the next 48 hours? 
  8. What happend when...? 
  9. How did it feel when...?
  10. What would have happened if...?

I recommend you take 3-5 questions to ask. Questions should be chosen in context of the exercise. Chose a mixture of emotion, observation and learning. People react different on same questions. People differ in observation, emotion and conclusions might lead to further insights and confusion, which both is good soil for learning.

Methods

How to debrief is about the method you select for debriefing. Usually you should give people a short break. I like to give first individual exercise before people share with the group. These are my favorite methods for debriefing:

a) Open keyword format: ask the questions to the participants and document the answers to the questions on a flip chart. Usually people need to share their experience. A few people talk a lot, you might need to stop them. Watch for silent peoples signs that they want to contribute. You could ask them, so that it is easier for them to share.

b) Closed keyword format: prepare a starfish retrospective flip chart and use your debriefing questions instead of the starfish questions. Let people write down their experience on notes. Give them 1-2 minutes to write it down, maybe you want to limit the number of notes per question to 1 or 2. As soon as finished the first person stands up, sticks the notes to the flip chart and says one sentence about it.

c) Lighting talk: every person gets 1-2 minutes to talk about their experience. Provide the questions before they start and give them a short break before you start to reflect. 

A few words

People might be disappointed if they are unable to share their experiences, so close the topics you've started. Debriefing is all about learning opportunities, so take it serious. 

SVNWNK