Burnout Is Rising. Here's What You Can Fix | Harness Blog

Lenny's Newsletter put out its 2026 tech workforce survey this year, and you should read the whole thing.

The headline stats: significant burnout jumped from 44.7% to 55.7% of tech workers in a year. Career optimism dropped from 54.8% to 48.7% over the same period of time. The survey asked what scares them about AI, and losing their job wasn’t it, with just 22% identifying it as a key concern. What topped the list was being expected to do more for the same pay (51%) and getting stuck on a pace nobody can sustain (46%).

We revisited our research and found that our data points in the same direction, even though the two surveys measure burnout somewhat differently. 

In February of 2026, we surveyed 700 engineering respondents (490 practitioners and 210 managers). We focused on how AI coding tools were impacting software delivery. While we asked about burnout, we didn’t initially dig into those results in depth.

After Lenny's report was published, we went back into the data to look at burnout directly: what's driving burnout for engineers, and whether the data says anything about what could bring it down.

Change failure is tied to burnout

When reexamining the survey findings, the first thing we checked was whether burnout tracks with anything concrete. It does: how often deployments fail. To find failing deployments, we asked about the share of code deployments that result in a rollback, hotfix, or customer-impacting incident.

Burnout by change failure rate reflects the 210 managers in our survey. Each failure-rate group had between 32 and 53 respondents (n = 47, 35, 42, 32, 53, from lowest to highest failure rate).

In organizations where less than 11% of deployments fail, only 4% (2 of 47) managers say their teams are constantly burned out. Push that failure rate above 30%, and it's 55%. The pattern is similar, but less dramatic for the practitioners. Generally, the more deployments fail, the higher the burnout.

The reason it climbs so sharply traces back to speed. DORA's research has said for years that Elite delivery means shipping often and keeping the change failure rate low, both at once. In our data, the teams shipping fastest have the highest failure rates of any cadence. Daily (or faster) deployers report that 25% of deployments fail, compared with 18% for those on a weekly cadence and 11% for the slowest group. They're fast. They're not elite. 

When you’re failing so often, somebody gets stuck holding the pieces together every time a release breaks.

You might think respondents would point the finger at AI. You’d be wrong. Instead, 84% told us AI reduced their burnout. Many developers are shipping more than they used to, and AI is the only reason that's possible. The catch is that the expectation to ship more only exists because everyone knows AI is available. AI raised the bar. 

The delivery system beneath it wasn't rebuilt to rise to that level. As a result, more releases can lead to more failures and more late nights.

What to do next

This isn’t a controlled experiment, just correlational data. We can't say fixing your pipeline guarantees lower burnout. However, teams with reliable pipelines experience dramatically less burnout, and the mechanism makes sense: less manual toil, fewer late-night incidents, and fewer people burning an evening on a release that should have rolled back on its own.

That's the clearest lever this data gives engineering leaders. Improving deployment success rates means fewer late-night incidents for your engineers and fewer broken releases for your users. The pace can stay high.

A few places to start:

• Cut the manual steps per release, not just the overall manual steps. Each cadence increase multiplies whatever toil is still in the pipeline. Approvals, evidence gathering, and code review that were fine at a slower pace don't remain fine as the pace climbs.
• Make rollback boring. If mean time to recovery is measured in hours, that's a deployment strategy gap. Canary and blue/green patterns exist so a bad release is a non-event instead of someone's night.
• Fight AI with AI. If AI-generated code means more security findings or more edge cases, that's a job for an agent that drafts the remediation, not a person sorting through a spreadsheet by hand. Agents can take the CVE information and code location and make a small code change.

Citi is a real version of this. Their previous release process had someone clicking through each environment promotion by hand and manually attesting that every check had run. It took hours or days. After automating the end-to-end pipeline, releases go from merged pull request to production in under 7 minutes, with automated tests and scans gating the release instead of a person. They did this in one of the most regulated industries. The speed-versus-control tradeoff can be reconciled with automation.

Lenny's data show the pinch is real across the industry, and most of the fix is outside any one engineering leader's control. Fixing the pipeline is something a leader can do and our data shows that fixing it is one of the strongest levers you have.

We go deeper on all of this, including where the correlation breaks down and what the most reliable teams do differently, in the full report.

Download the full report →