Your IT Team Is Burning Out and You're Pretending Not to Notice
I lost two senior engineers in January. Not to competitors offering more money—to burnout. One took a six-month sabbatical. The other left technology entirely and is now running a surf school on the South Coast. Both were people I’d worked hard to recruit, develop, and retain.
When I spoke with each of them during their exit conversations, the reasons were almost identical. Not salary. Not culture. Not management (I hope). It was the relentless pace—the feeling that every quarter brought a new existential priority while none of the old ones went away.
I don’t think my team is unusual. I think this is happening across Australian IT departments and most leaders aren’t willing to have an honest conversation about it.
The Compounding Problem
IT burnout isn’t new. It’s been a recognised issue since long before anyone was talking about employee wellbeing. But something has changed in the past two to three years that’s made it materially worse.
Every priority is urgent. In 2024, the CTO was expected to lead cloud migration. In 2025, AI strategy was added. In 2026, sovereign data requirements and regulatory compliance have arrived. None of the previous priorities disappeared. They all stacked on top of each other with the same teams expected to deliver everything.
Security pressure is constant. The ASD Cyber Threat Report makes clear that threats are increasing in sophistication and frequency. IT teams are expected to maintain security posture while simultaneously shipping features and managing infrastructure. Security work is invisible when done well and career-ending when done poorly. That’s a psychologically punishing dynamic.
AI has created expectation inflation. Boards and executive teams have read about AI productivity gains and now expect them immediately. The IT team is supposed to integrate AI into business processes, build internal tools, evaluate vendors, and manage risks—often without additional headcount or budget. The expectation is that AI will make the team more productive, but implementing AI is itself a massive workload.
“Do more with less” has reached its limit. After years of efficiency programs, many IT teams have been optimised to the point where there’s no slack in the system. Every person is fully allocated. When someone gets sick, takes leave, or quits, the team can’t absorb the impact. Work either stops or remaining team members pick up the load and burn out faster.
What the Data Shows
The Professionals Australia Digital Technology Survey has been tracking burnout indicators in the Australian tech workforce for several years. The trends aren’t encouraging. Average weekly hours are increasing. On-call expectations are expanding. Job satisfaction is declining even as salaries rise.
The financial cost is significant. Replacing a senior engineer in Australia costs between $50,000 and $150,000 when you account for recruitment, onboarding, productivity ramp-up, and knowledge loss. If you’re losing two or three people a year from a team of twenty, that’s $100,000-$450,000 in replacement costs alone.
But the real cost is institutional knowledge. When a senior engineer leaves, they take years of context with them—why a system was designed a particular way, what the known fragilities are, which vendor promises are real and which aren’t. That knowledge can’t be documented comprehensively and it can’t be transferred in a two-week notice period.
What I’ve Changed
After losing those two people in January, I made several changes that I should have made earlier.
Explicit prioritisation. We now have a maximum of three strategic priorities per quarter, and the leadership team must agree on what we’re NOT doing. This sounds obvious but it’s surprisingly hard in practice. Saying no to a board member who wants an AI prototype is uncomfortable. But saying yes to everything and failing to deliver anything is worse.
On-call reform. We restructured on-call rotations to reduce frequency and ensure proper compensation. Nobody should be on call more than one week in four, and on-call time is compensated with either pay or time off in lieu. This cost money, but it’s cheaper than replacing burned-out engineers.
Visible rest. I take my own leave visibly and I don’t work weekends unless there’s a genuine incident. Leaders who model overwork give their teams permission to overwork. Leaders who model sustainable work habits give their teams permission to have a life.
Skills investment. We allocated 10% of each team member’s time to learning and development. Not a training budget that nobody uses because they’re too busy. Actual protected time, blocked in calendars, where people can learn new skills, explore technologies, or attend conferences.
What the Industry Needs to Face
Individual CTOs can make their teams better. But the systemic pressures driving burnout need industry-level responses.
Realistic expectations from boards. Board members need to understand that IT teams can’t absorb unlimited strategic priorities without unlimited resources. Every new initiative either replaces an existing one or requires additional investment. Pretending otherwise isn’t optimism—it’s negligence.
Honest headcount conversations. When I see organisations with twenty engineers trying to maintain legacy systems, build new platforms, implement AI, and strengthen security simultaneously, I see organisations that need forty engineers. The budget conversation about headcount is uncomfortable but necessary.
Better vendor honesty. Technology vendors consistently underestimate implementation effort and overestimate productivity gains. A new platform that the vendor says will take three months to implement will take nine. A tool that promises to save forty hours per week might save ten. IT leaders need to build realistic timelines and push back on vendor sales narratives.
The engineers leaving my industry aren’t leaving because they don’t like technology. They’re leaving because the working conditions have become unsustainable. That’s a leadership failure, not a workforce problem.
If you’re a CTO reading this and recognising your own team, start with one thing: ask your people how they’re doing. Actually listen to the answer. Then do something about it.