How I Prevent Burnout in Software Teams

Burnout. It sucks the life out of our people, and in turn, our projects.

I’ve learned hard lessons about how insidious it can be. So I want to share the strategies to prevent burnout and improve productivity that have made a difference in my teams.

Thought 1: Work-life balance is more than just an equation

It’s fair to say that the term "work-life balance" has been heavily scrutinised over the last couple of decades, often criticised for suggesting a binary choice. 

While the emerging perspective – that there is value in maintaining a healthy divide between professional and personal life – is certainly valid, it is not a one-size-fits-all solution.

Here's my take on it. 

I think that leaders and employers, separation of work and life should be the default, but not enforced.

This is an inclusion issue as much as anything else. It's about acknowledging life’s complexities – parents with young kids at home, those caring for a loved one, and those caring for their mental health. 

Conversely, some people thrive in the fluidity between their professional and personal lives, viewing both as integral parts of their existence.

Neither approach is inherently superior, and neither should be disproportionately rewarded or penalised. 

If we've done our job in selecting the right individuals for our team, we should have faith in their judgment to decide what's best for them. 

When our team members feel understood and supported in their unique work-life approach. 

Which leads me to…

The case for open-ended working hours

The 9-5 routine assumes peak workplace productivity throughout the day.

But we’re not machines, and our natural rhythms of productivity can be as diverse as our personalities. 

Some among us are morning folks, hitting peak productivity with the first rays of the sun, while others find their stride in the tranquillity of the night. So why are we sticking to a one-size-fits-all work schedule?

The Results-Oriented Work Environment – ROWE – can work. 

It’s different from flexible working. It throws the clock out of the window and empowers people to manage their own time.

And it’s backed by evidence. Ok, it isn’t right for every type of team out there. 

But for an Agile software team? I think it’s a near-perfect use case.

Agile methodologies inherently embrace change and value individuals and interactions over development processes. And, importantly, they focus on delivering software and value. That aligns perfectly with ROWE. And Agile teams – consisting of diverse roles with different tasks and productivity cycles – are well-accommodated by ROWE, too.

Employees in ROWE workplaces have decreased work-life conflict, reduced turnover, and increased job satisfaction.

By acknowledging our team members as unique individuals and not productivity machines, we're cultivating an environment that mitigates burnout. More than that, it promotes balance, happiness, and exceptional output. Because ultimately, it's not about how many hours you're at work, but the quality of work you deliver.

Making ROWE work

ROWE comes with risks. Knowing what they are will help you mitigate them.

1. Collaboration challenges – Coordination becomes more burdensome when people work different hours in different ways. Use asynchronous collaboration tools such as daily standup tools and AI agents to keep people on the same page. Consider establishing “core hours” where people are available to meet or collaborate. 

2. Maintaining accountability. Less structure means a risk some team members may not manage their time efficiently. Set clear expectations, measurable goals and frequent feedback. Base these in project management tools for visibility, and keep everyone accountable.

3. Potential for overwork. Sometimes, team members put undue pressure on themselves to deliver, which can, in turn, lead to burnout. Foster a culture of balance by encouraging people to set and respect their own boundaries, and discourage overwork. Resist the temptation to give credit to those that work more.

Thought 2: The communication drain

Software development can present insidious communication and collaboration challenges, particularly in large, multifaceted, or cross-functional teams.

These persistent obstacles can drain engineers, squandering valuable time, and in bad cases, sow discord.

While Agile methodologies are designed to enhance team collaboration, they can sometimes intensify these issues. 

The truth is that good collaboration in complex situations isn’t in human nature. That’s not because some of us fall short at something. It’s that no human is physically capable of remembering every company and team goal, tracking every activity that happens and simultaneously being aware of every back-and-forth, risk and opportunity.

But there are things we can do to mitigate it.

Informal communication channels are underrated

Sure, stand-ups, sprint planning, and retrospectives are essential to align the team towards shared objectives.

If you’re still trying to nail your daily standup, there’s a guide here – or for sprint planning, go here.

But promoting spontaneous conversations, both work and non-work related, gets people on the same wavelength. Casual chats about new technologies, swift brainstorming sessions on an elusive bug, or a non-work-related catch-up enhance team relationships.

Having mutual understanding makes you more likely to have an effective, burnout-free team.

Psychological safety

I advocate for decision-making autonomy. It trims communication and boosts involvement and ownership. It’s an essential ingredient for happy, fulfilled employees.

We need psychological safety to enable a team to take calculated risks, learn and innovate.

Here’s how I think about psychologically safe environments:

• “Failure” is fine. Where it makes sense, you can redefine outcomes not as successes or failures, but as experiments with hypotheses to prove or disprove. Treat every outcome or conclusion as valuable.
• Reward courage. Appreciate those who make big calls, take risks, challenge the status quo, or bring up difficult issues.
• Demonstrate vulnerability. Others feel safe to do the same when leaders show their fallibility and share their learning process. 

Leverage communication tools

Collaboration in complex software development teams comes with a certain amount of built-in pain – even if it’s just trying to keep up with what’s happening. 

There’s sometimes a natural resistance to change around tools, but many engineering leaders I know swear by them. Engineers generally love them, and it forces teams only to have meetings about the things that matter.

They’re also a big win for distributed and remote teams.

• Daily standup tools. Instead of spending 30 minutes covering mostly trivial ground, contribute asynchronously, and have more focussed meetings about any crucial points.

Tool ideas: Here’s a great list of the best, depending on your team.

• Retro tools. These can be async too. Spend time only on the most salient ideas.

Tool ideas: Try EasyRetro or Miro Retrospectives

• Meeting summarisation. There’s no reason to still be rewatching whole meetings.

Tool ideas: Grain for meeting recording, segmentation and transcription. Otter for AI summarisation.

Human collaboration has a built-in weakness. It’s not possible to execute at work and keep up with what happens. 

And I believe this problem now has a solution – Stepsize AI. I’m building it with my team at Stepsize.

• AI-driven collaboration. Stepsize AI is the AI collaboration companion that surfaces what matters, effortlessly.

Stepsize AI surfaces the activity and insights from all the tools your team uses to collaborate, including Slack, GitHub, Jira and more.

Its architecture means it can form long-term memories by observing and reflecting on activities from all your tools. It uses this to provide precise, insightful summaries and answers to any question.

Thought 3: A real learning culture

Pretty much every organisation says they promote continuous learning. In my experience, very few actually do.

For example, they might have half a day of learning hours each week. Maybe it’s called Innovation Time or Upskilling Time. In practice, practically none of their engineers use it.

Why? Simply, pressure to deliver is incompatible with it. 

As a leader, you must guard these learning hours zealously. 

• Protect learning time. Make learning time regular, and protect your team from unnecessary meetings during this time. Assure them they won’t be penalised for not working on their projects. These hours are non-negotiable for all stakeholders.
• Lead by example. Show your team you’re not just advocating for continuous learning, but show you’re a learner yourself. Share what you’re learning, and why. Your team is more likely to mirror your attitude.
• Promote peer-to-peer learning. We have Slack channels dedicated just for people to share what they’ve learned, and for sharing articles, podcasts or whatever it might be on topics relevant to others.
• Accountability. Teams often formalise this as a Personal Development Plan. You can call it what you want – what matters is that you’re invested in your team’s learning and helping them explore and commit to learning goals.

Putting it together

These are not simple changes to implement. They require a shift in perspective and a willingness to buck a few norms.

But they’re worth it, every day of the year.

I can’t overstate the importance of the role of tools and technologies in assisting with these issues. Collaboration tools and AI-driven solutions can make a massive difference in how we collaborate. 

We're building Stepsize AI, the AI companion for your software projects.

Stepsize AI simplifies collaboration by giving you consolidated, meaningful insights into everything happening across your projects.

It offers powerful insights, actionable suggestions, and immediate answers to pressing questions; all pulled from the context around your projects from Jira, GitHub, and Slack.

I’d love for you to let me know how Stepsize AI shapes collaboration on your team. You can try it out here.