Don’t Be a Hero: My Experience with Burnout

Don’t Be a Hero: My Experience with Burnout

Burnout is an issue which is becoming more widely recognised and discussed within the technology industry. The more I have spoken to colleagues openly about this topic, the more I am surprised how common the experience is. A recent statistic identified that a shocking 57% of technology workers suffer from burnout.

Earlier this year, I gave a presentation titled ‘Don’t be a Superhero’ during the the Ministry of Testing’s conference, TestBash Brighton. During my presentation I discussed my own experiences with burnout, how I recovered and what individuals and employers can do to prevent experiencing something similar.

Burnout Talk

If you would like to watch the full presentation, then you can sign-up for a free Ministry of Testing Dojo account and find the video here.

The following is a summary of that talk.


I began my software testing career in January 2014 as a Games Tester. Since I started that particular role with no prior technology experience, I had a deep desire to improve my skills and prove myself.

I moved into my first Agile testing role in May 2016 and began to learn how to code. I knew I was entering the role at a fairly junior level, but I wanted to keep growing my career and began to push myself harder and harder in order to do so. It was this and wanting to improve my testing skills, that eventually led to me burning out.

How did I fall into the burnout trap?

Over time, I used to love being the go to person when a critical situation arose in our production environment. Working late was something I enjoyed doing because it meant I was saving the day. Having people treat me as a fountain of knowledge on the area I was working on was addictive. In hindsight, I simply cared too much about what my colleagues thought of me and compared myself to them.

I wasn’t just focusing my ‘free time’ on work projects, I was self-learning and wanted to learn new technologies, programming languages and skills that would make me a better tester – time I should have spent unwinding and resting. But instead of resting, I was watching YouTube tutorials on the latest technology trends.

Slowly, I began to realise the impact of the hero role I had forged for myself. I became sick of being the hero in the team, but still had managers approaching my desk at 5pm to tell me something in production was on fire. My holidays were routinely interrupted by colleagues asking me how to technical questions. I was even once asked to work on something critical on the same day I had phoned in sick.

As a result, the quality of my work also suffered. I found that even when I was working on a new project, people involved in the previous project were frequently asking me questions. I hadn’t shared my knowledge with anyone else as I was preoccupied with putting out fires and not preventing them.

What was burnout like for me? 

I was stressed. I never felt at ease at work as I felt I had too much work to do and not enough time to complete it. All of the work I had committed to in my ‘hero’ role came to a head at the same time and I began to feel overwhelmed.

I used to be extremely enthusiastic and passionate about my work, but at the point of burning out I couldn’t care less about the work I was doing. Every day, I was simply going through the motions.

My work relationships also suffered. I had previously made a lot of effort to form good working relationships with people in my team, but due to burnout and demotivation I was turning down offers of collaboration indiscriminately.

One of the worst symptoms was physical as well as mental deterioration. I was finding it difficult to sleep some nights because I was worried about how demotivated I was at work. I was no longer performing as well as I should’ve been because I was fatigued. 

Burnout Talk

How did I recover?

It wasn’t until I read a blog I found on Twitter that I realised I was suffering from burnout. It was here that I began to take some actions to improve my work-life balance. Here are three recommendations I hope you takeaway:

  1. Learn to say no

The first thing I did was to learn to say “no” to any excess work which was coming my way. This was a difficult thing to do as my managers were used to me taking on every piece of work, but they mostly understood why I was saying no.

  1. Go back to normal working hours & mute notifications

For the most part, I also stuck to my normal working hours. In our industry, overtime can be a common occurrence. I learned to question the need to do overtime when I didn’t believe it was necessary so that I was working a reasonable number of hours each week.

I also muted Slack and work email notifications on my phone outside of working hours. Having these apps active all the time can really blur the lines between personal and work life. Please don’t be the person whose downtime is on the couch watching TV but also replying to a work email at the same time – it doesn’t help anyone in the long run. 

  1. Prioritise & realistically plan workload

Learning to delegate and share knowledge on a daily basis was difficult but incredibly important. It allowed me to plan my workload, knowing the critical tasks I personally had to tackle each day.

Planning my workload now included any study and research outside of working hours too. I was able to be realistic when it came to setting targets for learning and development.


I’m now fortunate enough to be on the other side of my burnout experience and have found ways of addressing my work/life balance for the better.

A large part of this is that my current employer, ECS Digital, actively plan catch-up weeks once a month. This ensures I have the time and flexibility to upskill and explore new technologies within my contracted hours.

Having the support of a talented team when learning new skills is also extremely important. I don’t feel as if I am learning in isolation as the team is always available to collaborate with me on solving problems.

Why businesses need to take note

According to a recent Kronos study, one of the top causes of burnout in 2017 was unfair compensation packages that lend themselves to employees working too much overtime and having an unreasonable workload. The same survey reported that 46% of HR leaders believed employee burnout was responsible for up to 50% of their annual workforce turnover.

Another aspect is that organisations frequently reward hero behaviour but fail to recognise the consistently good work of their employees who can achieve a high standard of work within their nine ‘til five.

At a time where businesses are struggling with the IT skills shortage and employee engagement is a competitive advantage, businesses can’t afford to ignore burnout within their teams. In the words of Charlie DeWitt, Managing Director of ANZSEA at Kronos:

“Employee burnout has reached epidemic proportions. While many organisations take steps to manage employee fatigue, there are far fewer efforts to proactively manage burnout. Not only can employee burnout sap productivity and fuel absenteeism, it will undermine engagement and cause an organisation’s top performers to leave the business altogether. This creates a never-ending cycle of disruption that makes it difficult to build the high-performing workforce needed to compete in today’s business environment.

Organisations should seek out and implement technology solutions that provide a proactive approach to mitigating burnout, such as the scheduling of rest during rolling periods as long as a year. Workforce analytics can also identify and alert managers to trends in scheduling and absenteeism that may indicate an employee is on the path to burnout so changes can be made.”

Lessons Learned

Since I began to become more aware of my burnout symptoms I have achieved a greater work-life balance and now take a lot more time to relax. I take more time to spend with friends and family. My stress levels have reduced as I don’t work nearly as much as I used to and the self-learning that I now do is something that I’m truly passionate about.

The main thing I took away from the experience is that whilst enjoying what you do at work is extremely important, nothing happens in a vacuum and there are a lot of things in life more important than your career.

Just released!

To see the talk that inspired the blog, head to Ministry of Testing’s website for Ali Hill’s presentation on burn out at this year’s TestBash, Brighton here.

About the author:

Ali Hill is a passionate and motivated software tester at ECS Digital with a specific interest in improving teams’ processes to assist them in delivering quality software. Not only a test consultant, Ali is also heavily involved in the testing and tech community through my co-organising of Edinburgh Ministry of Testing Meetup and public speaking at various conferences – including a recent visit to the Nordic Testing Days conference.

Ali HillDon’t Be a Hero: My Experience with Burnout
read more
Out Scaling Peak Load

Out Scaling Peak Load

Not building your website for scale can be extremely detrimental to your service / product line and reputation – and can become an expensive mistake in the long term! Surges in genuine traffic are a rare opportunity, which makes it terrible timing for your website to be crashing.

In this short 25 minute talk, Morgan Atkins, DevOps and Continuous Delivery Consultant at ECS Digital, covers:

  • Why you want to engineer for scale
  • How you can build your services to scale
  • What the common success factors are
  • Where this technology is moving to next, and how this evolution will support scale beyond the Cloud



You can also watch the video for free on our YouTube channel here and learn how you can get yourself in the best position to react to unforeseen, performance-critical traffic spikes to your website.

If you want to talk to the team about any specific parts of the lecture, please reach out to and one of our consultants will be in touch to help answer your questions.


Banner Photo credit: Farzad Nazifi on Unsplash

Morgan AtkinsOut Scaling Peak Load
read more
Year in the life at ECS Digital

Year in the life at ECS Digital

  • Ever wondered what our consultants do?
  • Do you have an interest in engineering practices, culture, automation, coding or testing?
  • Are you ready to join our family?

At ECS Digital, we are always looking to grow and diversify our talented team of consultants. We pride ourselves in creating the optimal environment for our team to succeed. This means investing in our people when it matters most to them on their journey.

We also make sure that each day is a new and exciting opportunity for learning – because doing the same thing day in day out just isn’t fun for anyone.

So, if you’re looking to break into the world of Agile, BDD/ATDD, coding, CI and CD, Continuous Testing or DevOps, here’s what you can expect from your first year at ECS Digital:

Month 2

By month two, you should be settling into your new role and starting to learn how ECS Digital really works. You’ll start working towards your first certifications and shadowing on customer sites – which means lots of new faces and names to remember.

To help sharpen your consulting skills, you’ll be asked to conduct a few internal presentations and, seeing as we’re a social bunch, it’s likely you’ll have been invited to attend one of our frequent dinners or seasonal parties too! In addition to food and drinks, we plan regular events such as yoga and team-building sessions.

“ECS Digital has an amazing culture which promotes a good working environment for everyone with plenty of opportunity to progress if you wish to. ECS Digital will support this progression and ensure you have the tools required, but they also understand that sometimes the real world can get in the way and provide you with the flexibility needed too”

“While ECS Digital ensures you have people supporting you so you are not overwhelmed, they also provide you the opportunity to take responsibility if you want it, running an event like DevOps Playground provides a great stepping stone.”

Months 9-12

You should be feeling pretty great about what you have achieved and feeling confident in being responsible for delivering a whole host of tasks, as well as where you see yourself progressing in the coming months with us.

You’ll be encouraged to work towards additional certifications or attend one of a wide variety of courses, all while receiving the support and encouragement you need to succeed. It’s an exciting time, so be open to every opportunity that comes your way and continue to sharpen your skills as much as possible. Training is always available to employees but staying curious as you work towards leading your first client project is hugely important.

“After 12 months, I led my first client project involving two ECS Digital resources to work with the customer, a large UK based bank, on building up its Cloud capability. This involved a wide range of areas, control, security, infrastructure, networking, etc. and my personal focus has been on making all of that align so that project teams can consume AWS in a controlled and secured manner.”

When the time comes, usually after around a year with us, you’ll become responsible for leading a client project – with all of the support of your ECS Digital family around you, of course! Awards dinners and events will also guarantee you celebrate your first 12 months as an ECS Digital Consultant in style.

And that’s it, your first year with ECS Digital! We’re excited for you to start your consulting journey with us. If we’ve piqued your interest, take a look at our vacancies now.

If you missed our recent Year in the Life infographic, you can check it out here.

ECS DigitalYear in the life at ECS Digital
read more
The life and work of: The DevOps Engineer [Infographic]

The life and work of: The DevOps Engineer [Infographic]

The_DevOps_Engineer-page-001.jpgAs demand increases for DevOps skills, the profile of the DevOps
engineer is evolving. In the past year alone, demand has doubled. Today, 4% of all UK permanent jobs, are for DevOps engineers.  

DevOps engineers have a diverse and unique skill set, which makes finding good ones increasingly hard. As this demand grows, the best are earning higher salaries, but they are also being worked harder.

We created an Infographic to demonstrate just how the profile of the DevOps engineer has changed in recent years. Click to enlarge

ECS Digital (previously Forest Technologies) are well versed in benefits of DevOps. We often shout about the improved speed, quality and consistency that DevOps brings. One benefit of DevOps that is often mentioned in discussions, but rarely gets focused upon is employee satisfaction: retention, happiness and engagement.

Why, when employees are so important to the successful adoption of DevOps practices, is this side of the playing card often ignored?

Is it because employee satisfaction doesn’t directly result in organisations making money? Is it just lower down on their list of priorities?

Or is there more to the story?

I recently read an article about Tesla and SpaceX CEO Elon Musk that got me thinking. The premise of the article is that Elon Musk works his employees, hard. He works them so hard that it’s not uncommon to work 100 hours a week under his leadership.

Some say that Elon is killing his employees by placing them under such intense pressure and stress. However, more often than not, his employees are actually happy to do so. They feel part of something bigger, that they’re making an impact. Dolly Singh, former head of acquisition for SpaceX says “Diamonds are created under pressure, and Elon Musk is a master diamond maker”.

This is not all that different to how I’ve seen the role of the DevOps engineer evolve. I’ve been working in DevOps for over 7 years, and from what I’ve seen, DevOps employees are being worked harder than ever. In fact, research shows that more DevOps engineers report working 50+ hours a week than any other IT job role. 

You thought DevOps engineers were immune from burnout?

The Puppet State of DevOps 2016 report was recently released. Just as was claimed in 2015, the new report backs up the suggestion that working within DevOps results in lower levels of employee stress and burnout.

In reality, this is an assumption based upon the collaborative culture of DevOps.

The thesis is that DevOps employees should be happier and less pressured because they’re able to work within cross-functional teams, which encourages the sharing of workloads and removes single-points of failure and blame that can result in employee stress.

Whilst I’m completely sold on DevOps as a collaborative culture, and, to an extent, I agree that a blameless culture is beneficial to stress levels, I do not believe that DevOps engineers are invulnerable to burnout.

From what I’ve seen, DevOps engineers are becoming more and more stressed. They’re taking on longer hours and huge workloads. They’re also expected to know a lot more than your average IT employee.

Why is the DevOps engineer role stressful?

DevOps is a way of working. Whilst the foundations of DevOps lie upon many automated processes, DevOps success is hugely reliant upon having great DevOps engineers.

The DevOps engineer is the hard-working, knowledge-packed asset that allows organisations to see radical improvements such as 200x more frequent deployments and 2,555x shorter lead times.

Some might argue that “real DevOps shouldn’t have DevOps engineers” but that’s just the point. The DevOps engineer seems to have become this all-encompassing job title used by recruiters after a specific role, be it cloud migration, container adoption or infrastructure automation. And the role itself isn’t well defined. I challenge you to search and find two job opportunities that fall under the “DevOps engineer” umbrella and specify the same skills and responsibilities.

But, that’s why we’re seeing a decrease in specific skills across the board in IT. Highly skilled and specific IT roles such as SysAdmin have decreased in demand, whilst more generalised IT skill DevOps jobs have increased in demand (IT jobs watch).

The DevOps engineer is today expected to know every role along the pipeline. They’re expected to understand production cycles, in depth, from start to finish. Whilst this allows increased transparency, collaboration and quality when working with other staff, some might say that the knowledge expected from a DevOps engineer, borders on ridiculous.

Whilst this level of knowledge is hugely important for the success of DevOps, it’s also a hugely stressful way to work. No longer can these employees focus on perfecting a specific skill; they have to know everyone’s job.

So, why would anyone want to be a DevOps engineer?

I touched upon this slightly when I mentioned the Elon Musk article that I read. Of course, salary is often a huge driving factor behind career choice, and a skilled DevOps engineer comes with a price tag. For many DevOps engineers, the average DevOps salary – which outweighs the UK average salary by a massive £41,000 – will dwarf any risk of being over-worked. For others, it’s the chance to be part of something bigger. Since IT is now almost universally acknowledged as an enabler for business, the DevOps engineer truly is part of something big.

DevOps as a way of working is not going anywhere. In fact, by my guess, all organisations will be using it in some way or another, within 5 years. Some of the largest organisations in the world – Amazon, Etsy, Netflix – are as successful as they are because of DevOps.

A DevOps engineer gets to be a part of a hugely important organisational-wide transformation, and that’s pretty exciting. It’s rewarding to be a part of the movement that completely reforms and improves the way an organisation works.

Whilst, from my experience, DevOps staff retention can be pretty low (probably because those with the skills are also exceedingly at risk of being poached by other organisations), DevOps engineers in high-performing organisations are content. They’re actually 2.2x more likely to recommend their organisation as a great place to work to a friend or colleague.

The DevOps world is hugely competitive. To become the best, organisations need to hire the best. DevOps engineers have a diverse and unique skill set, which makes finding good ones increasingly hard.  DevOps engineer salaries and vacancies may be on the ever-increasing upward climb, but they are also being worked harder, and are, as a result, highly vulnerable to high stress and burnout levels.

Is the career worth it, what do you think?

You can explore a more in-depth analysis into the business benefits of DevOps in our new Whitepaper. The CIO Guide to DevOps: The value behind the hype explores DevOps from the perspective of the CIO, and how its implementation can help the modern CIO achieve their key priorities. You can download the whitepaper here.

Jason ManThe life and work of: The DevOps Engineer [Infographic]
read more