On-Demand Webinar · 48 min

10 Tips to Overcome Data Engineer Burnout

data.world CTO Bryon Jacob and DataKitchen CEO Chris Bergh on why 70% of data engineers said they were likely to leave their job inside a year, and what unreasonable requests, restrictive governance, and thin collaboration between business groups have to do with it. Moderated by DataKitchen's Beth Pfefferle. Recorded October 2021; updated August 2026.

Presented by Chris Bergh

What you'll learn 6 points
  • DataKitchen and data.world surveyed 600 data engineers. 97 percent reported being burnt out.
  • The top cause was not workload but culture: 63 percent named blaming and finger pointing, and 69 percent named restrictive data governance policies.
  • Half the respondents named the relentless flow of errors, and the same half named manual processes crowding out innovation. 49 percent named a steady stream of half-baked requests.
  • The organizational backdrop is weak: only one third of companies say the CDO role is successful and established, 24 percent have created a data-driven organization, and 29 percent are achieving transformational business outcomes with data.
  • The prescription is systemic, not personal. Build a system instead of suffering, automate rather than agonize, run toward errors, and treat 'done' as live in the customer's hands.
  • Heroism is treated as a failure signal rather than a virtue: make heroism a rare event, because a process that needs a hero every week is a process that will burn out whoever volunteers.

Prefer to read it? The written version is in 10 DataOps Principles for Overcoming Data Engineer Burnout.

Slides

14 slides

Questions from this session

How many data engineers are burnt out?

97 percent, in a survey of 600 data engineers conducted by DataKitchen and data.world. The figure is high enough that burnout is better read as a property of how data work is organized than as a matter of individual resilience.

What causes data engineer burnout?

The survey's top five: restrictive data governance policies at 69 percent, blaming and finger pointing at 63 percent, the relentless flow of errors at 50 percent, manual processes crowding out innovation at 50 percent, and a steady stream of half-baked requests at 49 percent. The two largest are cultural rather than technical.

Is burnout a workload problem?

Not primarily, on this evidence. Blame and restrictive governance outrank error volume and manual toil in the survey. Hiring more engineers into a culture that blames them when data breaks tends to produce more burnt-out engineers rather than fewer.

What are the ten tips?

Don't suffer, build a system. Don't agonize, automate. Run toward errors. Don't be afraid to make a change. 'Done' means live in your customer's hands. Don't be a hero; make heroism a rare event. Seek out opportunities for reuse and sharing. Practice agile data governance. Measure your processes and improve them. Don't put your head in the sand — focus on value delivery.

Why is 'run toward errors' advice for burnout?

Because avoiding errors is what makes them expensive. A team that fears errors finds them late, in front of a customer, under blame. A team that instruments for errors and tests in production finds them early, cheaply, and without an audience — which removes the dread rather than the work.

Where to go next