IT Burnout, business expectations and mythical maintenance

Originally I have been drafting an article to discuss my views on DevOps, but I changed it when I read this CIO.com website article:

Burnout: An IT epidemic in the making

While the article mostly focuses on the IT burnout trend, and the potential flow-on effects of burnout, it doesn't "double click" on a very interesting comment that nearly 75% of employees say they devote more than 40 hours per week to work according to a survey by Robert Half. It makes some really interesting points about return-to-office, the impact on women especially... but falls short of really analysing the macro cause and potential solutions to this problem.

I'm going to focus on what I believe is the root (imho) of the problem.

Business Expectations

Several years ago on a flight out to San Francisco, a solution architect that I will always respect highly, shoved a copy of the Phoenix Project in my hands and said I should read it. I read it from Melbourne to San Fran that year, and it enthused me about the whole DevOps movement and spawned several working experiences. (Over a glass of wine or 3 I've been known for re-telling those stories, and occasionally when I finish people are still awake. :) )

The experience back then fundamentally changed my approach and desire to extend further into areas outside my remit - even if sometimes it hasn't looked that way. Fast forward, I was an avid reader and read through Gene Kim 's other books, DevOps Handbook (first and second editions), Accelerate and The Unicorn Project, amongst many other books on related topics such as Jez Humble's "Continuous Delivery". As a cyber professional with a broad interest in all things IT, my biggest priorities when undergoing these learnings ( Casey Ellis woohoo, I got to use the word in some form of context!), was to answer the question:

How can cyber better fit the modern ways of working world, keep up, be more collaborative with other teams, AND achieve the intended result of better security posture?

Through my several years since, I think in my experience perhaps the genesis of the rot which we now call burnout is a business expectations. A cat amongst the pigeons you say, well allow me to elaborate:

edit (for better context): The problem with DevOps and Agile is that the faster speeds are actually ascerbating the issues of burnout.

Unless business expectations are managed, then the promise of faster speed of delivery in the modern ways of working - all it is doing is making sure that teams are working hard for 2 week sprints and rinse/repeat without a break. They will end up applying so much pressure that all the super advantages of DevOps/Agile end up being the catalyst for a future working team disaster. At best, staff churn. At worst, staff burn.

It all starts with poor business expectations. We're so caught up in a world where we feel we need to iterate, evolve and change at speed, so that our customers don't leave us, that we fail to see the implications and consequences of these actions. Let me break it down:

1. Customers (or Employees) have a problem that needs solving (or they don't really and we conjure it up for them).
2. The business makes commitments to solving this customer or employee problem in record time. Often without consultation with IT.
3. The business then informs IT that a deliverable (product, service, etc.) needs to be delivered by X date. Don't care how, just make it happen.
4. IT re-prioritises its already full backlog, making concessions either in other deliveries or in governance & hygiene activities, just to be able to work at 100% or more to get things done. this often means sacrificing the mythical maintenance windows in sprints (80/20, 70/30) and more often than not working at 100% delivery and 0% maintenance, including sacrificing documentation.

This has 4 impacts:

• a team running at 100% at sustained pace, even if it is done in an Agile and streamlined manner, will run out of puff before too long because there is no contingency for VUCA
• remember when our job descriptions used to have 10% of your time spent on research & development? no? well they existed a couple of decades ago... the lack of reflection and deep work time causes a cognitive overload that stifles ingenuity and problem solving long term
• obviously, reduces execution of governance and hygiene activities has an impact on solving risk scenarios that cause issues, incidents or crisis. it contributes to technical debt, and in the context of cyber an aggregation of cyber risks across people, process and technology
• co-dependency + stalling in governance and hygiene teams causes stress related to risk remediation commitments and delivery expectations

If we truly are facing a slow, moderate or even critical impact of long term burnout within the IT profession - then we need to get better at:

Business-Side Collaboration: The business must play it's part in reaching towards the Technology team and understanding their world. This starts at the CEO level and goes all the way down through other business leadership roles. The urge to make promises to customers must be weighted with the ability of technology teams to deliver. Business folks should see technology folks as partners, and reduce the urge to see them as "those wierd guys/gals who talk techno-gobbledy-gook and live in spaces without natural sunlight". Any historical issues around trust or confidence must be sidelined, in favour of resetting expectations and making a mutual two-way promise involving realistic expectations and commitments to delivery.

Technology Leadership to stand fast on Delivery/Maintenance ratio: The pressure that modern day CIOs/CTOs are under is enormous. Digital Transformation is evolving almost every company or organisation out there (even the Mr Whippy icecream vans have EFTPOS facilities and websites now). The desire to leave a track record of delivery to bolster the chances of the next 7-digit CIO gig, is not worth the incredible pressure that is applied to technology teams.

The 70/30 or 80/20 delivery and maintenance window ratio must be sacred.        

It is my belief that most governance & maintenance operators - such as Cyber - can operate within the 20 to 30% maintenance window. (and if there's a big heap of technical debt or aggregate cyber work - perhaps a clean up project to start from a good base). It sure beats the 0% window in many places today.

We need to allow tired teams to operate with a bit of free-time. Trust teams to use that free-time for either self-care (which includes bonding and connecting with peers), or get back to place where strategising and planning operates best - in un-rushed deep working times.

I'm spending more time on how to solve those problems (1. how business can engage technology better and 2. how technology leadership can preserve maintenance efforts) - but I don't have all the answers I'm sure happy to hear constructive feedback from anyone.