Burn-Out in the IT Industry
Developers are still human beings. You stress them the same, they react the same.
A recent tweet from #NoEstimates advocate Vasco Duarte, drew attention to one of the tragic sides of IT industry, which has provided a consistent theme throughout the contemporary incarnation of our business. Burn-Out.
Burn-Out is as mysterious as it is tragic and far reaching. Yet, despite this, there isn’t a single categorization which adequately covers it within psychological, neurological or psychiatric literature. It mixes symptoms of exhaustion, fatigue, depression and anxiety, and manifests in ways as unique as the individual sufferer, but reaches deep into their networks of friends, families, colleagues, finances and business. In the UK, stress related conditions accounted for 20 million lost working days per year.
Adrenal Fatigue
A little bit of stress is good for us. A famous psychological anxiety curve shows the link between stress and performance. Too little stress, performance suffers, too much stress, performance suffers. The key is to find the sweet spot in the middle. Sports people have been harnessing that for peak performance, for years.
Now, I am no neuro-biologist. In essence, I am a layperson, albeit one who has had some training for my work within charities in this area. Despite this, and for the fact that I don’t want to sound too hippy, I invite more qualified folk to correct me where I’m wrong. However, touching upon the science, the effects of stress boil down the consequences of the synthesis of adrenaline through the adrenal system.
Adrenaline is triggered through the metabolisis of noradrenaline (aka Norepinephrine for readers in North America) synthesised through the dopamine and L-DOPA line of neurotransmitters. These sympathetic nervous system pathways evolved to respond quickly, allowing us to act fast, especially in stressful situations. They’re also central to the famed ‘fight or flight’ response. Precipitating the generation of adrenaline in the adrenal system, for short periods of time, allows us to defend ourselves, enjoy ourselves, or freeze like a rabbit in headlights. It suppresses the immune system, increases the metabolism of blood glucose, fats and carbohydrates.
However, this line of neurotransmitters did not evolve to be omnipresent in our system. Indeed, long-term exposure to stress with the reduced immune response makes us more susceptible to illnesses, slow healing and in the worst cases, diabetic like symptoms, ruining our sleep and triggering the onset of mental health conditions. All of which not only impacts on individuals, but also on the people and processes that rely on them.
Recovery Time
Burn-out is much more serious than common knowledge would have us believe. It’s also a field of medicine and public health that has yet to consider the full systemic impact on the body. Some of the longer term effects mentioned above appear irreversible. The build up of cholesterol in the wrong places is also under investigation for long-term, enduring and degenerative mental health conditions such as Alzheimers and other Dementia. This then arguably becomes as much a public health issue as a responsibility for employers.
The key to sustaining the performance of teams is to understand this baseline. In terms of recovery from adrenal fatigue, it takes a lot longer to recover from burn-out or exhaustion than the duration the individual was in that state in the first place, as demonstrated in the graph below. Dr Lam’s findings are repeated across several studied covering different forms of fatigue, mental health conditions and indeed, burn-out. It’s a small wonder that the condition is not recognised with a symptom cluster all of its own.
Software Engineering: The Double Edged Sword
The problem with software is it comes with an equal split of passion and stress. Most if not all auto-didactic developers started in the industry for the passion. Hobbies turned into qualifications, which turned into occupations. As a result it can become all too easy for developers to fall into the position of wanting to deliver on impossible deadlines. For some, their coding ability is so tied into their self-esteem and identity, that any threat is cuts deeper than the 9–5.
For managers, especially those without a background of software development or IT, the field can be extremely alien. Their over-reliance on these “magicians” can lead to situations where the individual manager’s or product owner’s reputation and sometimes even their identity is tied into the delivery of a product they have little to no control over. Hence, software development environments can become very toxic, very quickly and do so in such a way that is hard on everyone.
The latter cohort, who wield greatest classical power, often attempt to control aspects of delivery and uncertainty by asking for unmovable, 100% commitments from software and systems engineers. This is based in the somewhat mistaken belief that all aspects of systems engineering are under the control of the engineers in the room, have zero variability, and linearly scaling teams provides linearly proportional productivity increases. Those familiar with the Mythical Man Month (F. Brooks Jr) or the work of Professor E Goldratt, author of The Goal, will tell you this is absolute folly. Especially in the face of contention, failure demand and bottlenecks. Each of which adds invisible work or makes demands of resources and people, as well as any subsequent waste.
In essence, this all means that wider factors and the actions of people outside the developers direct contact can have an effect on developer performance and thus, affects alignment to their estimates. Also placing often unfair pressure on an individual who in all likelihood, is already placing significant stress on themselves. It also transfers the responsibilities of management of uncertainty to developers, who already have enough on their plate, but crucially, also transfers with it the responsibility and accountability for failure, without the empowerment to change processes to de-risk that failure.
All this lowers the worker’s position in the stress-vulnerability threshold Zubin and Spring, 1977).
Epilogue
It is little wonder many developers fear providing estimates. The impact on their reputation is one thing. The personal fear is another and placing them in confrontational positions, a third. The reality though is that stressful workplaces are a symptom of a wider organisational culture problem. Poor management, poor processes, poor support, exclusionary practices and bullying all contribute to the toxic environment.
There are better ways to manage risk. Those with analytical mindsets are best placed to understand how to do this, but the reality is very few middle and senior managers are. With only 1.4% of that cohort possessing the necessary skill to effect the necessary change across all industries. If there was more, management would look very different to how it does now.
Still, it’s certainly not impossible. Onwards…
