Burnout at Scale: What Running 200 Engineers Taught Me

A survey from Yerbo in 2024 found that two in three engineering leaders experienced burnout in the past twelve months. I read that number and thought: that sounds about right. I was one of them.

This was during my time at a global logistics company. We were rebuilding a major platform from the ground up. I had 200 engineers spread across four countries. Post-pandemic supply chains were still broken. Shipping schedules were unreliable. Customer pressure was constant. And in the middle of all that, we were trying to replace systems that had been running for over a decade.

What it looked like

It did not arrive as one big moment. It crept in.

My scope kept growing. More teams moved under me. More senior stakeholders wanted updates. I was in meetings from 8 AM to 6 PM, across time zones, and then doing actual thinking work in the evenings. My calendar was full, but my output felt empty.

I started sleeping badly. I would wake up at 3 AM thinking about a deployment that was due in two weeks. I stopped exercising. I ate badly. I told myself this was temporary, just a hard quarter, just a push to get past this milestone. That is what we all tell ourselves.

The worst part was that I could see the same thing happening to my leads. Good engineers, people who had been with the company for years, started going quiet in standups. One of my best architects asked for a week off with no notice. Another started delivering late on things that used to be easy for her. I knew what was happening to them because I could feel it in myself.

What I got wrong

I tried to be in every room. I thought that if I was present in every decision, I could keep things moving. I sat in architecture reviews, sprint demos, vendor calls, leadership syncs, and incident bridges. I believed I was helping. I was not. I was just making myself the bottleneck.

I did not delegate enough, early enough. I had good leads, but I kept pulling decisions back to myself because I was worried about consistency. In a rebuild of that size, one bad architectural choice can cost you six months. So I held on tight. Too tight.

I also confused availability with leadership. I wore my long hours like proof that I cared. But my team did not need me to be awake at midnight answering Slack messages. They needed me to be sharp at 10 AM when the hard problems landed on the table.

What helped

Three things made the difference.

First, ruthless prioritisation. I sat down with my leadership team and we listed everything we were doing. Then we cut a third of it. Not delayed. Cut. Some of those things were good ideas. They just were not the most important things. When you are rebuilding a platform while keeping the old one alive, you cannot do everything. You have to pick.

Second, I started protecting the team from noise. In a large company during a crisis, every senior leader has an opinion and a request. I made it my job to absorb that and filter it, so my teams could focus. I took more of the politics so they could take more of the engineering. That trade felt right.

Third, I accepted that some things would be late. This was the hardest one for me. I come from a background where you deliver on time or you explain why. But I learned that if you push 200 people to hit every deadline without exception, you do not get quality. You get tired people writing bad code that you will fix later at twice the cost.

The line that matters

There is a real difference between a hard quarter and burning out your best people. A hard quarter has an end date. People can see it. They push, they recover, they come back. Burnout does not have an end date. It just keeps going until someone breaks.

The signal I watch for now is when good people stop caring about quality. When your best engineer ships something they would normally be embarrassed by and does not mention it, something is wrong. That is not a performance problem. That is an energy problem.

Another signal: when people stop disagreeing with you. A healthy team argues about technical choices. A burned out team just says yes and moves on. If nobody pushes back on your ideas anymore, do not assume you have become smarter. Assume they are too tired to fight.

How I changed after

I restructured how I spent my time. I blocked two hours every morning with no meetings. I gave my leads more authority and accepted that they would sometimes make different choices than I would. Most of the time, their choices were fine. Some were better than mine.

I started having one-to-one conversations that were not about work. Not long ones. Five or ten minutes. How are you doing, really. Are you sleeping. Is this sustainable. Those conversations surfaced problems weeks before they would have shown up in delivery metrics.

I also got better at saying no to stakeholders. Not in a difficult way. Just clearly. We can do this or we can do that. We cannot do both well. Which one matters more to the business? When you frame it that way, most reasonable people will help you prioritise.

Credit where it belongs

I want to be clear about something. The rebuild worked. We delivered it. But I did not deliver it. The team did.

I had engineers who stayed up late to fix production issues they did not cause. Leads who shielded their own teams from pressure they were feeling themselves. Architects who rewrote their own designs three times to get the migration path right. The company got a new platform because those people cared about their work, even when the conditions made it hard to care.

My job was to make it possible for them to do that work without destroying themselves in the process. For a while, I failed at that job. I was so focused on the delivery that I forgot the people doing the delivering.

If you are running a large engineering org right now and you feel like you are just getting through each day, I do not have a simple fix for you. But I can tell you that the answer is not more hours. It is fewer things, done well, by people who still have enough energy to think clearly.

Take care of your team. And do not forget to include yourself in that.