Breaking the burnout cycle in (efficient) engineering teams
Burnout has long been pervasive in the tech industry, and has always been important for us to talk about, but if you’re a line manager, you probably don’t need much convincing. Those of us who are drawn to line management tend to care deeply about the well-being of the people who report to us. Being an engineering manager means finding success through others. We can see first-hand that our teams are most successful when everyone’s needs are met.
Yet senior leaders often have a really hard time seeing engineers as humans with needs, and this can increase the risk of burnout. Senior leadership is looking at the big picture, and as they move further away from line management, they can sometimes lose the connection between achieving results and supporting the people who create them. Line managers feel this disconnect the most. We understand the needs of the individuals on the team and the importance of supporting them, but have difficulty convincing senior leadership that praising the “hero” engineer or encouraging a team to overwork to hit a deadline is not the way. Early on in my management career, I once thought that the VPs above me just needed to be informed about the dangers of hero culture and overwork, so I sent them academic articles thinking they just needed help to understand – this approach was, not surprisingly, rather ineffective.
At the moment I’m writing this, in 2023, this tension has reached a breaking point. The pressure for teams to be efficient and on managers to prove it is greater than ever. Today our teams are smaller, and being pushed to deliver faster. Another manager I know recently heard from a senior leader that “we don’t have time to invest in people and process right now.” Senior leaders are concerned about prioritization and efficiency, and are forced to focus on the short-term over longer-term strategy. They can mistake work related to people and process as separate from, and possibly in conflict with, business goals. Yet feelings of overwork, a lack of support, and the threatening of individual core needs are much more common problems in uncertain times, and all can contribute to an increased risk of burnout. I believe that if we want to create efficient teams, we must dial up our own efforts to recognize burnout, react to it quickly, and to create space in our teams to minimize the risk of burnout occurring – because a burned out team is anything but efficient.
Recognizing and supporting individuals with burnout
In the ICD-11 for Mortality and Morbidity Statistics, the World Health Organization defines burnout as “a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed,” with three dimensions:
“Feelings of energy depletion or exhaustion”
“Increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job”
“A sense of ineffectiveness and lack of accomplishment”
If you’re feeling like this may describe yourself, you’re not alone. A study by Yerbo on The State of Burnout in Tech showed that 42.1% of tech employees are working under a high risk of burnout, based on self-reported measurements of burnout dimensions.
It’s particularly important to pay attention to this today, because an individual who is at high risk of burnout can dramatically impact the efficiency of a team:
Their exhaustion or mental distance can lead to less collaboration and teamwork, making it more difficult to spread knowledge across a team.
Their work can be inconsistent, impacting predictability.
Other team members may grow resentful if someone is disconnected, and not contributing as much as the rest of the team.
Their negativity can permeate team interactions, starting to bring the entire team down.
The risk of attrition is high, which could cause more strain on a team. In the same Yerbo study referenced above, 42% of tech workers with high burnout risk reported that they wanted to leave their company within the next 6 months.
As managers, we can’t diagnose burnout – if you’re concerned that someone is experiencing burnout, it’s important to consult with HR/your people partner for guidance, as there may be benefits or medical supports available, or legal implications to consider. But regardless of someone meets the full criteria for burnout, we can still support them based on what we observe.
Burnout can look different for everyone and is a spectrum – it might start with one of the three core areas and build over time, or be stronger on one or two things for someone. In my experience helping direct reports experiencing signs of burnout, I’ve found that there are two primary ways that people react when they’re burning out – by over-engaging, or disengaging.
The Over-Engager
This engineer is always giving 110%, and will say yes to anything, even if their plate is already overflowing. You can usually find them on Slack late into the night helping others, and often jumping in on incidents just to be helpful. They’ll work late into the night even when there isn’t a looming deadline. During the work day, the Over-Engager is always multitasking, jumping onto any question that comes over Slack within a few minutes – often before anyone else on the team has even seen it. When they are working with the team, they usually try to be helpful, but as things progress they can struggle to collaborate and compromise. They come into their 1:1s feeling exhausted and increasingly negative about the state of the company. Despite getting a high volume of work done, they feel like they’re not accomplishing anything during the work day. They struggle to take time off, always feeling like the work will just be waiting for them when they get back.
To help an over-engager, the best tool we have as managers is the 1:1. Be sure to bring your observations up early, and make it a coaching conversation – ask them open-ended questions, listen, and let them take the lead. You might say:
“I’ve noticed you’ve been working a lot of extra hours lately, and expressing frustration around our work in our team meetings. Tell me more about how you’ve been feeling lately.”
“What’s keeping you up at night?”
“What’s one thing that could make things slightly better?
It’s important to not jump to solutions when you may not understand the problem. Listen carefully to what the individual has to say, and help the individual identify their own needs.
That said, sometimes it can be difficult for an individual experiencing signs of burnout to be able to think of how things can be better. Here are some tools for your toolbox based on the burnout dimensions:
If the individual is experiencing high exhaustion:
Help make space for them to take time off. A vacation will not cure burnout, but it will give the individual the space to rest and potentially reframe how they approach their work with a clear mind.
Take things off their plate. For an over-engager, this can sometimes feel like a punishment, so be sure to emphasize how it’s providing space for them to do their best work on the most important things.
Give them positive feedback when you notice they’re helping others on the team, rather than being the “hero” that does all the work. We get what we recognize, so it’s important to encourage the over-engager to be a force multiplier.
Set clear expectations about response time. When over-engagers are responding to questions asked of the team quickly, it may be because their internal acceptable response time is misaligned with yours or the rest of the team’s. If it’s okay for a Slack question for sit for a few hours, make that clear with the team, and document the expectations for reference.
Encourage them to set work-hour boundaries and make it clear to the rest of the team. This is most relevant to remote employees, especially ones working on teams that span time zones. Sometimes well-intentioned team members can forget that someone works on a different schedule, especially if that person still ends up responding off-hours.
If the individual is experiencing cynicism/negativity:
Have a conversation with them about their career goals and values, and help show the ties between those goals and values and the work that they’re doing. When everything feels like it’s going wrong, it can be helpful to make a connection to something that’s valuable to them.
Listen to their concerns without judgment or dismissal. When someone is constantly negative, they may be feeling like everything they say isn’t being heard by others. While you don’t have to agree with all of what they’re feeling, just acknowledging that they’re feeling it can go a very long way, and lead to more productive discussions on how things could get better.
If the individual is feeling ineffective:
Help them with the prioritization of their work. Multi-tasking often means that the more impactful work ends up taking longer, as it’s interrupted by less critical things. Help them see the value of the more impactful work, and to feel good about setting other work aside.
Help them see all the work that they are accomplishing. When someone is helping with smaller questions, they may not take the time to acknowledge that work. It may be helpful for them to try documenting everything they help with over the course of a few days, even small, so they can see it in writing.
Approaching senior leadership about the over-engager
Because senior leaders are currently feeling pressure around achieving short-term results, telling them that one of your hardest-working engineers needs to take a long vacation is not going to go over well. To make sure that you have buy-in to support an over-engager, it’s important to tie things back to business goals. Do you have data that can show the negative impacts of this person’s behavior on the company or team? Is their velocity dropping, or perhaps staying the same, but the person is spending more hours outside of core working time to get the same work done? Can you speak to the immediate risks to the business if the person doesn’t get the time off? Can you work with the team to minimize the impact of that engineer stepping away on the team’s goals? Later in this article I have some thoughts on building resiliency within the team that may help with creating space.
The Disengager
The Disengager seems to need more sick time than they used to, and may leave halfway through the day due to headaches or exhaustion. They can be late for meetings fairly regularly, keep their camera off more than others in virtual meetings, and is participating in meetings less. They are less responsive to messages than their peers and less available for pairing. In their 1:1s, they may be feeling highly ineffective and be very apologetic about it, but be unsure what to do to improve.
This archetype can be much harder to notice or acknowledge as burnout. It’s much more subtle, and can sometimes be dismissed as “quiet quitting” or just an underperforming employee. But they are still showing signs of burnout, just reacting differently than an over-engager, and if we can get to the root of their stress, we can usually help their performance improve.
Just like helping an over-engager, leveraging your 1:1, discussing your concerns openly, and having a coaching conversation can help a disengager move forward. But for a disengager specifically, we need to be careful about how we deliver feedback tied to underperformance. If the individual is already feeling ineffective, focusing on the underperformance itself rather than the underlying causes may only increase their feelings and make it more difficult to recover. Coming from a place of believing in their capabilities, being curious, and expressing the desire to help unblock them, rather than focusing just on the underperformance, may help them feel more empowered and capable.
Here are some additional tools that can help a disengager:
If the individual is experiencing exhaustion:
Make sure they are focused on one, clearly-scoped thing at a time. A disengager can find themselves stuck in rabbit holes, which can be draining for them.
If the individual is experiencing cynicism/mental distance:
Encourage time to connect as a team. Especially with remote teams, collaboration can feel limited to the work at hand. Ensuring the team has some space to connect with each other without a specific work goal can help the team feel more connected.
Chat with others on the team about checking in with this engineer more frequently. It’s common for others on the team to start expressing frustration with a disengager, but they’ll often expect the person will reach out when they need help. Proactively checking in can help a disengager feel more supported and provide more opportunities for collaborative work.
If the individual is feeling ineffective:
Help them with the prioritization of their work. A disengager may be prioritizing the wrong things unknowingly.
Ensure the team has high ticket quality, and help to enforce a definition of ready. When work isn’t clearly understood, it increases the likelihood of a Disengager spinning around in circles. They may be too disengaged from the team to speak up when things are unclear.
Make sure there’s dedicated space to learn. A disengager may feel like they’re lacking knowledge compared to others on the team. One of my teams started doing “code spelunking” sessions to help engage everyone on the team to dig in and understand some legacy code together, which encouraged collaborative discovery and engagement.
Approaching senior leadership about the disengager
A senior leader who is focused on efficiency may see a disengager as a threat to the team, or a weak link. Here, focus on your plans for how you’re going to measure improvement. I like meeting with these engineers more frequently for check-ins, and helping them set objective weekly goals that are in writing. These goals often start simple, to help them get some wins, and then build.
Making our teams more resilient to burnout
Supporting developer well-being can increase overall team resiliency. I’ve seen the most success by focusing on the BICEPS core needs:
Belonging: community, connection
Improvement: progress, growth, helping others
Choice: flexibility, autonomy, decision-making
Equality: fairness
Predictability: resources, time, direction
Significance: sense of purpose
This framework was developed by Paloma Medina, and her website offers great resources on how to use it for coaching and for team check-ins. The framework makes it easier for individuals to discuss their needs openly so they can better support each other.
We must keep these core needs in mind while dealing with the pressure for increased efficiency. It’s on us as leaders to manage this pressure and to ensure our teams can deliver. We keep hearing about “doing more with less,” but it’s important to recognize that efficiency isn’t doing the same amount of work with fewer people – it’s about maximal impact for minimal effort. If a team is cut 20%, but they’re spending the same number of developer hours each week getting things done, that’s not efficient, and it increases the risk of those team members burning out.
So to become more efficient, we need to focus on creating the most impact for the capacity we have. This can also help reduce burnout risk – getting the most impactful work done, and connecting it back to the team and company vision, can help the entire team feel more effective.
Focusing on team predictability
I believe seeking and achieving team predictability – understanding the capacity of work for the team over a period of time – is the most important thing we can focus on outside of core needs to increase team resiliency. Once we have data around the team’s capacity, it becomes a finite data point. Our prioritization conversations then shift to how we can maximize impact given that capacity. This can lead us to further simplify MVPs, reprioritize less-impactful work to make space, and it prevents excess pressure on the team to hit an unrealistic deadline, because we set those deadlines with data.
Predictability helps minimize burnout risk by setting reasonable expectations and enabling conversations that prioritize impactful work. Prioritizing impactful work, and being able to hit deadlines consistently, creates efficient teams. In this way, we address the concerns and priorities of senior leadership without sacrificing our teams.
To help our teams become more predictable, we need to track work over time. My experience has been with Scrum teams, so I track story points over sprints, and factor in vacations and holidays by tracking average story points per engineer day per sprint. An engineer day, in this case, is one engineer working a full work day – so a 10-day sprint with 5 engineers would be 50 engineer days before accounting for holidays and vacations.
Story points can be a polarizing topic, and I’ve worked with many teams who have started off skeptical about assigning what can feel like an arbitrary number to a task, but the process of discussing and voting on tickets helps encourage conversations to better understand work across the whole team. Ensuring the work is well broken-down and understood can improve efficiency and increase overall team velocity over time. At the end of a sprint, it can also be helpful to discuss how the team did against the capacity prediction, so they can learn from them. When one of my teams recently fell well short of the predicted sprint velocity, that data point helped the team think more critically in their retrospective about the factors that impacted them getting less work done, and come up with ideas to improve.
We also need to address disruptions or escalations that may get in the way. In software engineering, work can be nearly impossible to reliably predict, and so we always need to leave space to handle the unexpected. If your team works in sprints, planning to 80% of the team’s capacity can be a good baseline, adjusting as needed based on how much uncertainty there is in the team’s work. This leaves space for escalations, unexpected absences, and mispointed work.
When there are disruptions or escalations, measuring them and making them visible can help make clear how much it impacts the team’s progress. Toil or maintenance work usually doesn’t decrease when team size decreases, so if your team is impacted by layoffs or code freezes, this can help identify when the work may be taking up too much of the team’s time. Having solid data around escalation work can help prioritize work to reduce toil.
When setting timelines for project completion, we can use our predicted capacity as a guideline, determining the number of sprints it will take when planning to 80% (or your percentage of choice), but I find it helpful to provide an additional buffer for the unexpected, where that buffer length is set based on the overall risk and complexity of the project.
If we set realistic expectations around when work will be completed, with a buffer for the unexpected, we’ve allowed the space for teams to do their best work, and also created space for an unplanned absence without needing to impact business goals.
And don’t forget yourself
Engineering managers shoulder a lot of the burden of our teams, increasing our own risk of burnout – and just like the structure of this article, we tend to put ourselves last. But in order to support our teams, we also have to support ourselves.
Here are some quick strategies that may help:
Find the things that recharge your capacity, and make space for them. They may be work-related, or not. Block the time out on your calendar for this. Recharging tasks often don’t feel like “work” but they are – they’re essential for giving you more capacity and mental clarity.
Mute your Slack notifications off-hours. This is especially important if you’re on a team with multiple time zones. While it’s important for a manager to know what’s going on with the team, that doesn’t mean you need to routinely sacrifice your personal time to do it. Your direct reports can send you a DM and bypass snoozing if it’s truly important enough that you need to be present.
Think about efficiency for yourself. Managers often take on a lot of work and treat all of it as essential, but think about prioritizing the work that will be most impactful right now. Determine what can wait, and consider delegating work to create growth opportunities for others.
Connect with your “first team” – your peer leaders. They can be a great listening ear, and they might be able to help take some things off your plate, or help you brainstorm ways to handle your own work more efficiently. If you don’t have a great support network at work, you may find some great leaders at conferences, meetups, or in tech Slack groups. I still connect quarterly with my peer group from a leadership training course I took 6 years ago, and find every conversation valuable.
So, to summarize:
Burnout is one of the biggest risks to creating more efficient teams, and it’s on us to address it.
Burnout presents itself in different ways, and can involve over-engaging or under-engaging.
When we see any concerning signs that someone may be experiencing burnout or be at high risk of burnout, it’s important to bring it up early in 1:1s, create a plan together, and address the concerns of senior leadership by tying plans back to business goals and risks.
To create more resilient teams, we can support developer well-being through regular conversations and check-ins, and focus on achieving team predictability to turn capacity into a finite data point. This helps facilitate conversations around maximizing the impact of the team’s capacity – doing more with the resources we have – and allows us to set reasonable expectations for the team to protect the team from burnout.
We can protect ourselves from burnout by prioritizing the most impactful work, including the time we need to recharge our capacity, and by leaning on our peers.
Additional resources:
Yerbo’s burnout index – this is free to take on your own, and can measure your burnout risk
Big Feelings, by Liz Fosslien and Mollie West Duffy
