Skip to content
article

Burnout isn't a resilience problem. Here's what I check as a manager.

If one person is always the hero, you have a staffing problem.

July 24, 2026 · 2 min read

Every time burnout comes up, someone recommends a meditation app. I have nothing against meditation. But in my experience, most burnout on engineering teams is caused by how the work is set up, and that's the manager's job, not the engineer's.

There's decades of research on this. Christina Maslach's six areas of worklife (workload, control, reward, community, fairness, values) are a good starting point if you want to read further. Here's what that looks like in practice on my team.

What I actually check

  • Workload: I count pages per person per month from our on-call tool. Not the rotation schedule, the actual pages. Schedules look fair. Pages often aren't.
  • Control: Is anyone being handed work with no context and no say in how it's done? That's how good engineers start feeling like ticket machines.
  • Reward: When did I last recognise this person's work in a place their skip-level could see it?
  • Fairness: Who got the visible projects this half? Who got the migrations nobody will ever thank them for?
  • Community: Does this person have anyone on the team they actually talk to, or are they an island?

What I do about it

  1. Say no to my VP in writing, with a trade-off. "We can do X by the 15th if we drop Y. Which do you want?" A written trade-off is much harder to ignore than "the team is stretched".
  2. Protect focus days. Two afternoons a week with no meetings for the whole team.
  3. Push PTO. If someone hasn't taken a week off in six months, I ask about it in a 1:1.
  4. Model it. I log off visibly. I don't send Slack messages at 11pm, even with "no rush" attached. There's always a rush when the manager writes at 11pm.

The one I missed

A few years ago one of my best engineers carried about 60% of our pages for a whole quarter. He was the only one who really understood a legacy settlement service, and he never complained. I praised him in every review as reliable. Then he burned out completely, took leave, and later left.

I was rewarding the exact thing that was hurting him. If one person is always the hero, you have a staffing problem, not a hero.

What's one structural change that actually reduced burnout on your team? I'm always looking for ideas I haven't tried.

Written by

Renee Whitfield

Engineering Manager at a payments company in NYC. 14 years in, 6 managing. I write about 1:1s, promo packets, hiring fairly, and getting Black women into rooms that weren't built for us. Spelman alum. Opinions mine.

Get the best of Dynamo Geeks weekly

One email each Monday with the most useful posts. No spam; unsubscribe in one click.

Comments

6

Sign in to join the conversation.

Sign in to comment
Kenji Tanabe@kenjitanabe
The pages-per-person count. At my last company one engineer on our team took 40% of pages for two years because he was the only one who understood the scheduler. He was "a hero" in every perf review. He left three months before the layoffs, and honestly that's the best thing that happened to him.
2 net votes
Danny Cho@danny_cho_la
"If one person is always the hero, you have a staffing problem" should be printed on every on-call doc. Heroics are a bus factor with a smile.
0 net votes
Sanne Bakker@sanne_sre
SRE here, burned out last year. What helped was exactly the written trade-off thing. My manager finally said no to a migration deadline in writing. Thank you for writing this.
1 net votes
Renee Whitfield@renee_em
I'm glad you had that manager, and I'm sorry it came after the burnout instead of before. Take care of yourself.
1 net votes
Jessica Tan@nomad_jess
the "model it, log off visibly" part. our CEO sends emails at 2am and then writes "no pressure to reply". there is pressure. there is always pressure
2 net votes
Trần Phương Thảo@thao_qa
Pages per person for QA is "who gets pinged when the flaky test fails". It's always me 😅 good list
2 net votes