“It’s not enough to be busy; so are the ants. The question is: What are we busy about?” — Henry David Thoreau
If burnout was a natural byproduct of working too much (or too hard, or for too many hours), we’d see every founder/C-level suffering from it. And yet… they’re generally doing just fine; ICs and middle managers, on the other hand, are usually taking the biggest hit.
Preventing burnout from happening on our teams means that first we need to identify the real causes of it, otherwise we’re just sending people to long vacations hoping the problem fixes itself. (It won’t.)
Each case is different (of course), but from what I’ve seen with engineering teams over time, burnout usually isn’t about work’s volume—it’s about a lack of purpose or agency.
If an engineer can’t see how their hard work supports the company’s objectives, helps real users, or improves their own skill set, every hour feels heavier—pointless, even. And when people feel they have no input into what they do, that their tasks are simply “assigned” to them rather than chosen, any form of intrinsic motivation goes to the toilet.
Let me be clear: working too hard/for too long can obviously lead to burnout, but again, more often than not the entire story doesn’t end there. In many cases, burnout emerges when smart, passionate individuals find themselves working on tasks that feel meaningless or misaligned with their strengths and interests. They might be coding late into the night, but the real energy drain is when they ask themselves: Why am I doing this?
“Ok, I’m sold. What can I do about it?”
You can start by considering whether the people on your team:
Have control over the projects they work on;
Feel connected to the outcomes they produce;
Understand why their contributions matter;
If the answer to any of these is “no,” the bad news is there’s work to do. The good news? As their manager, you have the power to fix this.
If you’re looking for something more practical, here’s what I usually do:
Alignment, alignment, alignment: Before kicking off any project, I share why I’m considering them for the job. I provide links to product specs, design docs, and user research so they understand the problem space. This simple step gives them agency and aligns their work with their interests and career goals.
Clean-up period: After wrapping up a project, we set aside two weeks for engineers to choose what they want to work on—refactoring messy code, experimenting with new technologies, improving internal tooling, or tackling long-ignored bugs. This autonomy gives them a sense of ownership and keeps intrinsic motivation high.
Impact reminders: Every now and then, I’ll show how the team’s work connects back to the company’s objectives. If you use OKRs (or any similar goal-setting framework), tie their efforts to those key outcomes. By repeatedly highlighting the real-world impact they’ve had—like improving user satisfaction scores, reducing operational costs, or enabling a new product launch—you reinforce the purpose behind their day-to-day tasks.
These actions can’t guarantee the elimination of burnout, but they help align work with meaning, give people choice, and constantly remind them why their contributions matter. And that goes a long way.