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.


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.


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)


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. 


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.


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.


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)


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

Managing portfolio with roadmaps and teams

If you are working with teams, assign products or project to them and want to structure your planning process on a higher level, you might consider using a roadmap for your portfolio level (I use the term product equal to project).

To give product portfolio a sound basis you might use a roadmap to visualise the load factor of your teams. Just give every team its own lane and assign the planned products to the teams.

If you are doing this for the first time, you might wonder on how much products in parallel your teams are working. It is reasonable to think about the reduction of product multitasking to increase productivity.

For those products you are not sure if they are worth working on them yet, you have three choices:

  1. Keep them unassigned (unstaffed), but put them on the "should be considered soon for implementation list". Those products should be discussed in a portfolio meeting.
  2. Put them on a parking lot, if you do not want decide soon about the implementation but do not want to forget about them.
  3. Kill them, if you don't want to think about them in the future anymore or if they will never get the priority to get capacity.
This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

Here comes a little more description about the used lanes in the roadmap:

The team lanes

Within the team lanes you assign products to the teams. As long as a team works and is planned on a given product no other product should interfere. I recommend you to set a work in process limit (wip limit) for each team. This should speed you up and reduce waste.


Each product which could not be staffed by a team stays unassigned. Unassigned indicates: you want to work on this product, but do not know how to stuff it yet. In future discussion these products might get development time.

Parking Lot

You've got a product which is interesting enough not to kill it but doesn't have the priority to be developed you put it on the parking lot. These products might be good opportunities but hard to realise in practice.


If you refuse to work on a product, kill it. This means throw it away. Do not bother yourself in the future with concerns or thoughts about this product.

If you decide about your product portfolio, share it. Communicate it and make it visible as much as you can. If you want alignment, people must know about your decisions and for sure you have to defend it against the drift of the daily business. You might provide guidance for people and create policies for them. If you want to read about an example, I recommend to read about "how an issue finds its way into development".

If you are working in a hierarchical organisation, management should support or communicate the decisions. If communication is not aligned chances are hight that your portfolio gets sacked. Or just to stick with Gojko Adzic:

If communication fails, everthing else is just painting the corps.



From the trenches: How an issue finds its way into development

This article covers strategic planning using a project portfolio approach and tactical planning including incident management. It's direct from the trenches of development and explains the involvement and planning between stakeholders and development teams.

To dig into it, we need to distinguish two levels of planning:

  1. The strategic level: priorities and roadmaps are planned here. Teams get allocated concerning these priorities. Usually we allocate one team one project at a time (wip limit equals one).
  2. The tactical level: iteration (sprint) planning is done here and we deal with urgent issues from projects which are not allocated (lower priorities). Iterations follow goals of the project which is currently in progress.

As said: we are working under the constraint of "avoid multi-tasking", so each teams only works on one product/project at a time (iteration/sprint).

Stakeholders of an allocated project are are fine, because they are on the development track. If the project is not allocated, stakeholders only have chance of capacity if the issues do not clash with the overall priorities from management. The best thing a stakeholder can do is to plan the issues two weeks ahead of each sprint, so that there is time to break down the requests to get them into the sprint planning during the tactical planning and align them with the overall goals and priorities.

Strategic level

Planning on strategic level means managing priorities on product or project level. This is done with the management and Product Owner team. The result of this planning is an allocation of each an product/project to a team over a given period of time. Other projects keep unassinged and others might be suspended on a waiting list (parking lot) or killed (won't ever be done). 

We use a roadmap for planning and communicating the plan.

The allocation implies the priority. Allocated projects are those ones under development or planned for development. Unassigned are those ones which will be discussed next time and are more likely to get development time, parking lot means that this project is out of development scope and killed projects are entirely removed from priorizaton process.

The strategic planning is an reoccurring meeting - at least every six weeks. 

Tactical level

Tactical planning is about which issues should be done in wich sprint and dealing with change and other (external) effects. This is where reality hits. Yes, there might be requests from not allocated projects like bugs or small improvements. Its the duty of the Product Owner to deal with this requests and not to violate the given priorities from management. Usually most requests are urgent, but not very important, so it is possible to defer those to avoid time slippage of the important project priorities. 

Planning and timing

During development we are working with sprints, which are iterations of two weeks. The scope of those two weeks is mainly fixed because we are focusing a goal. The planning of all issues happens during the first day of the sprint. So if a stakeholder is late with communicating his requests, chances are low that your issue will get important enough to switch scope with an already planned issue.

To avoid that and increase the chance to get those issues planned is easy: be on time. This means stakeholder need to communicate their issues at least one week before each sprint (depending on size of the issue), so that the team is able to refine the issues (break it down, get it ready, get it understood).


  1. The only person who is ordering the list of issues for the sprint is the Product Owner.
  2. As a stakeholder to get your issues on the planning list, the only counterpart is the Product Owner.
  3. Talking to development team members is about clarification, not planning. Stakeholders should not waste their time trying to sneak into a sprint. This only creates waste and delay.


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.


What Scrum really means... what it feels like...

If you like to know, just start with the definition of Scrum:

A scrum (short for scrummage) is a method of restarting play in rugby football.

This is how Scrum looks alike. Picture is called "Frascati Rugby" by f/orme taken from Flikr is licensed under CC BY 2.0

And that is what is all about. If you are able to quickly restart the product development game at anytime with all your team members - then you are doing a scrummage. Anytime in rugby means:

Scrum is utilised either after an accidental infringement or when the ball has gone out of play.

Feeling Scrum

In product development there is usually a lot of accidental stuff going on and sometimes even combined with "ball has gone out of play". But that's also the place where the magic happens. I've seen it last time with my new team: It was Monday, the day before delivery and we had still two stories to close. We were getting a little bit uneasy because we found some bugs and learnings to improve the product. So we needed to decide whether or not to include the learnings this sprint or postpone them. Furthermore we needed to pit against the open tasks and bugs. So we needed to get the ball back in the game and it felt like Scrum: Side by side, depending on each other, talking, shouting, passing the ball, passing the lead - and then we finally scored. There was trouble, yes - but also a lot of energy. Simply put: Feeling good and proud about what and how we accomplished it.


What's your organisational default? Stay or leave?

There is a joke I'd like to tell:

>> CTO and CFO are talking about their staff.

CFO: "Imagine, if we educate them and they leave."

CTO: "Imagine, if we do not educate them and they stay." <<


I like that one, because it easily shows a big conflict in organizations.

Whenever I am thinking about this joke I am asking myself: What is the default in the organisation? Do people stay or leave? And furthermore:

Why do good people leave?

Usually good people leave, if you do not educate them or if they don't work in an educated environment. Both is interdependent and depends on each other. Both is closely connected to intrinsic motivators like status, certainty, autonomy, relatedness and fairness (scarf).

Educated people

If you educate people you raise their status, because people are feeling good in self-development. On the other hand, if the skill of those people is at the mercy of a jackass who has no idea, but gives instructions, people are feeling threatened. They feel less important which is a drop in their status.

Take this example and inspect from the perspective of fairness and autonomy. I guess you will easily find more social threats and opportunities. Reflect about your organisation: How do we educate people, so that they would like to stay?  

Educated environment

An educated environment gives people certainty and autonomy. Both is a reward for people which increases ability of complex problem solving and minimises social threat. An educated environment gives power to the people and power usually is information. Information produces certainty and enables autonomy.

It increases certainty, because people are able to predict behaviour of others, which minimises social threat. Moreover people are more certain about their near future. To be able to predict the near future is very important, because our brain is forecasting all the time. In an unstable environment we loose too much capacity in relation to this function. It is simple: People are overwhelmed with concerns in an uncertain environment - they don't like to feel insecure, don't you?

Frascati Rugby by f/orme taken from Flikr is licensed under CC BY 2.0

Frascati Rugby by f/orme taken from Flikr is licensed under CC BY 2.0

If you grant autonomy you have to buy it with information and trust. You will earn cheap decision making and self-confident people. Think about the last jackass who made your decision. Did mean a threat to you? Did your inner voice say: Once again and I will... quit? Overruled people will never be responsible nor will they stay for long. 

To me, relatedness is another aspect of an educated environment. People like to work with others they know. They like most working with people they like, but working with strangers is perceived as a threat. Mixing people frequently around and assigning them to new "teams" is a threat to people. Again, they do not feel safe and get annoyed and angry.

Constantly loosing connections is an high attractor to change the workplace because of a drop in relatedness, fairness, autonomy and status.

My perspective

I think there is a lot of benefit if in self-reflection about threat, social interaction concerning education and environment. But to me real value lies in an educated environment, because everybody is searching for that kind of environment. But it is rarely out there.

The biggest struggle is how to create it. First steps might be an economic framework for teams, a clear set of rules and regulations concerning decision making and a shift of decision making from management to people. Information should be no longer a currency of a few, it should be the budget of the whole organisation shared between each other. Management should provide as much information as possible to enable decision making. People should get feedback about their decisions, there should be open discussions without status threat. Transparency could be used as a tool to share information.

While everybody is searching for an environment where safety and relatedness isn't "words on the wall", you could step forward to create it. Be humble, be brave! 


Title picture "Church Knights Templar in Chwarszczany (Quartschen), Poland" by Jan Jerszyński (Own work) is licensed under CC-BY-SA-2.5, via Wikimedia Commons


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 :-)


Surfing on the learning wave

Surfing in projects

If you inspect something you will learn about it. Your learning will lead to new insights that will lead to action. Action needs to be inspected and new insights will rise new learnings and further paths to inspect. Sounds like infinite play of waves against the shores and sure it is.

If we take for granted, that we'll learn on the way while we inspect something - when we analyse something - then we cannot deny and have to admit, that the learning is something that changes reality. So staring at reality and learning about it rises the need to deal with change.

Analysing too much, before taking action on it, creates waste. It is not only the waste of missing feedback, to a greater degree I think it is the waste of not catching the insight and the learning. Not preserving the change seems like wasting the investigation at all.

Back down the big analysis change wave

Let's have look at the most project management techniques: Usually we plan, when we have the least knowledge of a project ever. There is huge front-up planning at the start of each project, so we analyse a lot. Makes sense? Yes maybe, but do we really preserve the learning we've created? Do we fully accept that we changed our view about the thing we investigated? Not sure, in most times I would say yes - if the chunk of change is small enough.

As I said: While we analyse we change our view at a lot of things. So with each analysis we need to manage more change. Again: the more we analyse, the more we have to manage change. So far the creation of a big plan, without handling the wave of change created by the analysis, leaves the learning and preservation of insights behind. Instead of making big plans which drown us, we should focus on small batches to analyse where we can cope with the change we've created. So we need to find a batch size so small, that we can cope with the change we created.

Making the drop

You are shouting "Coming down" when you are the first to drop into the change wave? Only few surfers are brave and skilled enough to survive the big waves. So why not surf on the waves big enough you are able to deal with. Even when there are always a lot of change waves following, as soon as the ocean bed flattens out:

A guy who is making the drop in a nice wave. Every investigation reveals insights, and those insights lead to a wave of change. Don't let the wave grow too big to withstand it.

At the moment we hand over our experience, means sending out our deliveries to customers and users, we create more change. Now change might increase more than linear, according to the batch size of done work and people involved. If we take feedback outside of the team into account, then there might be a good reason to move to an even small batch size of analysis to cope with this wave of insights and demands again. 

Making the drop - again

Now, how can we really make the drop - again and again? To me one answer is to work in small timeboxes, where each timebox represents a small batch size of delivery and a deadline. Furthermore I would arrange a framework around it, which is able to inspect and adapt. This framework should be able to deal with experiments and feedback: something like a plan-do-check-act cycle. Fortunately here is already something out there and they call it Scrum. Wanna try it?


PS: Socrates said: “understanding a question is half an answer”.  .. and I want to append: "the second half of answer will change the question".

The french parade - a highway road work flow system

I was impressed. Driving home from our vacation in beautiful France back to Germany I've seen something totally new to me: I saw the french highway flow system, a fast moving end-to-end road work, rebuilding one driving lane from start to end in under 8 km. Incredible, awesome and totally efficient. 

A parade in denmark. Photographed in © 2004 by Tomasz Sienicki CC-BY-2.5, via Wikimedia Commons

In Germany I am accustomed to long lasting road work. Germans process road work in large batches, process the big batches layer for layer - a big waste of time and we as a users we wait extra long unit the blockade is gone. Terrible annoying.

The french road work system I've seen was so different! They did not produce much waste. They rushed through the driving lane like a parade in full motion. In front there were the guys who secured the road - to me they looked like the jugglers in front of the parade, shouting loudly: "Here we come!". Right behind them followed a small group of artists, preparing the road for the big orchestra. The big orchestra made an ground-breaking sound, so guttural that the highway next to them was shaken and torn in peaces. After the big machines came the first dancers, swinging the dirt away. Right after the dancers followed the local craftsman guild, demonstrating how easily a new road surface is created. Within the last few kilometres one group marked the new lane markers and painted them. Then the jugglers again singing: "Bye bye" and the road work was over... sitting in the car and thinking about the economic impact of using a workflow system on a highway instead of wasting time, money and good feeling with big batches.


Trust me and I do my very best

Some time ago at a customer site

... we had the discussion if developers should be allowed to install software on their own. Usually my opinion is that a developer should have no need to put operations under siege for just a few software installations so we recommended to let the developers install the software on their own choice and demand.

This is an engraving of Hercules performing one of his labors as he forces a bull to the ground. By B. Picart [Public domain], via Wikimedia Commons - if you depend on me I will try to pull the bull to the ground.

You might say: "What the hell are you talking about, development with admin rights is precondition to productive software development" - no discussion I think you are right, but this is not what I want to talk about, so let the story move on...

We've been very close to give developers the resources they need, but unfortunately our suggestion was skipped by the boss. The reason was the following: "We should not let people deal with software installations, they might install something wrong and I don't want to make people responsible for their possible faults. So let's take care of it, that nobody does anything wrong." 

I was disappointed, and so were all developers I've talked to. With no trust they could not do anything right and moreover they could not install the tools they need for productive work. It was just keep the standard, do not improve. No trust, no choice...

A few days ago at my workplace

...we had a important meeting ahead of us and my boss said: "I count on you, concerning this topic I have no clue and you are my backup." To me this meant: "Hey guy I put my trust in you and I need your help - he made clear: I depend on your competence." - so I did my very best not to disappoint him and tried to deliver the best I can. I did this because he trusted me, because he laid his reputation in my hands, so I did my best to reward him. Thankfully all went well and right after the meeting he clapped me on my back and said: "Well done, good job!" - We both were proud about what we achieved and it felt great.