Learning — Workplace Psychology

What the Psychology of Software Teams Teaches Us About Burnout

New research argues that developer burnout is not a character flaw or a stamina problem — it is a predictable consequence of how software teams are organised, interrupted, and asked to perform under constant change.

• The work of Dr Cat Hicks and colleagues draws on empirical studies across major engineering organisations and thousands of developers worldwide.
• High turnover, chronic burnout and low resilience in technical teams are traced back to the same root: relentless interruption and the erosion of attention.
• The book “The Psychology of Software Teams” (Routledge, 2026) reframes the fix as organisational design, not individual willpower.

Software teams have a reputation problem. They ship fast, they are paid well, and yet they leave at alarming rates and report some of the highest burnout of any profession. The usual explanation points at the individual: work harder, recover better, build “resilience.” Dr Cat Hicks, founder of Catharsis Consulting and author of the new book The Psychology of Software Teams, pushes back. Burnout, her research suggests, is what happens to a focused human mind when its attention is fragmented continuously by meetings, alerts, handoffs and the pressure to keep up with a codebase that never stops moving.

The mechanism is straightforward but often invisible. Deep software work requires long, uninterrupted stretches of concentration. Teams that run on constant context-switching — a Slack thread, a status check, an urgent ticket — deprive engineers of the attention span their work actually needs. Over months, that produces fatigue, errors, cynicism, and eventually exit. The fix, then, is not a meditation app but structure: protected focus time, fewer but better meetings, and leaders who defend engineers' attention the way they defend deadlines.

The wider lesson is that many “soft” problems in technology are really hard structural ones. A team that cannot retain engineers is usually a team whose working conditions, not its people, have failed. Treating burnout as something the individual must outlast lets the organisation off the hook; treating it as a design problem gives leaders something concrete to change. In a sector already stretched by the pace of AI change, that distinction may be the difference between a team that lasts and one that burns through a generation of talent.