The tech world has always been preoccupied with getting things done quickly and efficiently. Unfortunately, it’s easy to forget that when something breaks there’s someone making sure that the problem gets fixed. Unfortunately this often means they will have had to work long, disjointed hours.

This on-demand culture has created significant health and morale challenges for employees in the IT industry.  Unpredictability is a part of life in the industry – an on-call worker never knows when they’ll be called to fix an incident – it could be a convenient time, but it could just as likely be 4 in the morning. Errors and delays cost millions, but financial costs aren’t the only downsides. This unpredictable lifestyle negatively impacts employee health and well-being, making the industry unappealing – so how can we fix this?

Bringing empathy to IT

‘Move fast and break things’ sounds great in the abstract, but in reality this expectation of rapid patch releases and continuous delivery models have placed strain on enterprises seeking to improve their products. Understandably, many companies are looking to DevOps practices to ease this burden and modify their team structures so that development and operations are working together in a more efficient and agile way.

These changes may affect productivity positively, but they’re not the only thing that needs to happen to make sure people are working effectively. Managers need to stop focusing solely on team dynamics and focus specifically on the individuals involved and their personal well being.

It may sound shocking, but many managers don’t take into consideration just how taxing operations and sysadmin roles can be, crucially those that involve on-call work. It sounds simple but it’s worth highlighting – if you’re woken up at 3 am to fix a server issue, of course you’ll struggle at work the next day. In fact, the research shows that interrupted sleep can be worse than no little or no sleep. The problem here is the expectation that sysadmins and on-call workers are switched-on and available at all times, including overnight. Often, IT workers feel like they have to live up to “superhero” standards.

The impact of stress in IT often affects more than just employees’ personal lives – it can affect the company. Employees with low job satisfaction will often leave their job sooner, and according to some figures replacing them can cost as much as 21% of that worker’s annual salary. This could have a huge impact on businesses and their bottom lines. People will always be a critical part of any complex infrastructure and even when they’re well looked after within an organisation that has good operational practices, human error is still a possibility. The recent AWS cloud outage proves this, so imagine the risks for companies not thinking about this in as much detail and investing less i.e. pretty much every company!

I speak from experience, as I used to work on-call at the beginning of my career. At the time, I had my own company, but that didn’t mean it was easier to manage being called away from my evening engagements. This takes a toll on your social life, your family life, and your personal health. This pushed me to figure out a way of making on call work easier, brainstorming how the industry can come together to make a change.

How can we change?

It may seem odd for me to be writing on this subject considering I am the founder of an infrastructure monitoring company. My software sends out alerts at all times of day and yes, will sometimes wake people up. But it is because of this that we’ve taken the initiative to bring in more responsible practices within IT. At Server Density, we call this HumanOps.

HumanOps is based on a variety of principles, but the one that appeals the most to me is to remember that human health affects business health. A key example is Google, who after years of trying to figure out how to boost their employee productivity, realised that all it took was for there to be a culture of kindness at work. In Richard Branson’s words, “if you look after your people, your customers and bottom line will be rewarded too.” If businesses focus on human development, everything else will follow.

This is all well and good in theory, but in practice it can be difficult to prioritise human development under pressure. Sure, businesses want their employees to get a good night’s sleep, but if there’s a crisis, your people will still need to be on-call. One easy way of making sure better practices are implemented is having developers work directly with their managers to implement feedback systems. These practices allow for reevaluation of how issues are escalated, who they are escalated to, and who has the final say on workload. Following this, internal protocols can be built to make sure that every avenue has been explored before calling someone to come in.

These aren’t the only steps that can be taken towards a more empathetic IT workplace. Policies like blameless postmortems can be put in place in order to avoid the same issues in future. It’s also key for everyone in the organisation to understand the impact of sleep loss. One interesting way of helping everyone understand how stressful it can be in  systems management is getting the manager to join in with on-call work. I’m sure they’ll remember the stresses of on-call work in no time!

Software companies need to make sure that their products work as advertised, but this needs to extend to their staff, ensuring they are working in healthy and happy environments. Monitoring metrics like time spent on call per employee, the number of alerts triggered out of hours, and interruption cost in human hours can give managers insight into where the biggest problem areas lie within the company’s systems maintenance.

DevOps is an area of IT that is fast growing, and so many people feel positively about it. This is great, and long may it continue, but there’s so much more that could be done to improve the way that people in IT work together. Companies need to refocus on their most important assets: not their servers or their systems, but the people on the front lines. If your staff are happy, better system maintenance, higher quality products and happy, paying customers will follow.

The Human Behind the Alert

As infrastructure has migrated to the cloud it has become increasingly abstracted and self-healing. Autoscaling groups restart failed instances. Health checks reroute traffic. Runbooks are codified into automation. Yet when something goes seriously wrong at 3 am on a Saturday, it is still a human being who wakes up, unlocks a phone, and starts diagnosing the problem.

The tech industry’s long-standing mantra of “move fast and break things” has spread well beyond Silicon Valley startups into every sector that depends on IT infrastructure. The problem is that this culture risks breaking the most important asset those organisations possess: the health and morale of the engineers who keep the systems running.

Why On-Call Culture Is a Systemic Problem

Scale brings complexity, and complexity brings unpredictability. An on-call engineer cannot know when the next page will arrive. The expectation of continuous availability—of being a “superhero” or “ninja” who is always ready to respond—creates sustained, chronic stress.

Some of the concrete consequences include:

• Cognitive degradation. A developer woken at 3 am to resolve an incident is unlikely to be productive, accurate, or safe the following day. Research in sleep science consistently shows that interrupted sleep can be more harmful than simply reduced sleep—though the on-call engineer often suffers both.
• Increased error risk. Fatigue reduces concentration. High-pressure, late-night incidents are exactly the conditions in which consequential mistakes happen. The 2017 GitLab database deletion incident—in which a tired engineer ran a destructive command on the wrong server—became a widely cited example of how human exhaustion amplifies operational risk.
• Staff attrition. Engineers with poor work-life balance leave. Replacing a departing employee carries significant costs in recruitment, onboarding, and lost institutional knowledge. Commonly cited estimates place replacement cost at a significant fraction of that employee’s annual salary, making wellbeing a hard business concern, not a soft one.

DevOps Extended with Empathy: Introducing HumanOps

DevOps already asks teams to break down silos between development and operations, to share responsibility for reliability, and to learn from failure without blame. HumanOps extends that thinking one step further: it asks organisations to treat engineer wellbeing as an operational metric with the same rigour applied to uptime or deployment frequency.

The term was coined by the team at Server Density (an infrastructure monitoring company) precisely because the business of sending alerts and waking people up made the human cost of on-call work impossible to ignore. The founding principle is straightforward:

Human health impacts business health.

Or, as Richard Branson has framed it in broader business terms: look after your people, and your customers and bottom line will benefit too.

Core HumanOps Principles

HumanOps is not a certification or a formal methodology—it is a set of guiding principles intended to shape how engineering organisations are run. The most important include:

• Human health is an operational concern. Wellbeing, rest, and sustainable pace are not HR soft topics—they directly affect system reliability.
• Alerts have a human cost. Every page that fires out of hours represents an interruption to someone’s rest, family time, or cognitive recovery. That cost should be tracked and minimised.
• Knowledge should not be siloed. When a critical fix can only be performed by one or two people, those individuals carry disproportionate on-call burden and become single points of failure for the organisation.
• Managers should share on-call rotation. Leadership that has never been paged at 4 am is poorly positioned to prioritise alert noise reduction or sustainable scheduling.
• Blameless postmortems matter. Creating a culture in which engineers can be honest about errors without fear of punishment is essential both for learning and for reducing the anxiety that makes on-call work more stressful than it needs to be.

Practical Steps for Engineering Teams

Abstract principles only help if they translate into concrete changes. Here are actionable practices teams can adopt:

1. Audit Your Alert Volume

Track the number of out-of-hours alerts per engineer per week. Any alert that fires repeatedly without triggering a fix is noise, not signal. Establish a regular process—sometimes called an “alert review”—to tune thresholds and eliminate pages that do not require immediate human action.

2. Define Escalation Policies Deliberately

Not every alert needs to wake a senior engineer immediately. Work with managers to map which failure modes genuinely require immediate human intervention, which can wait until business hours, and which should be handled through automated remediation. Document these policies explicitly.

3. Spread On-Call Load Equitably

Rotate on-call responsibilities across the team—including, where appropriate, managers and tech leads. Use scheduling tools to ensure no individual carries a disproportionate share of nights or weekends. Consider providing compensatory time off after a difficult on-call week.

4. Measure the Human Cost

Useful metrics to track include:

• Number of out-of-hours pages per engineer per month
• Mean time to resolve (MTTR) broken down by time of day
• Interruption cost in engineer-hours
• On-call hours per person over a rolling quarter

Surfacing these numbers in team retrospectives makes the human cost of reliability decisions visible and discussable.

5. Run Blameless Postmortems

After significant incidents, hold a structured review focused on systemic causes rather than individual blame. Document what happened, why, and what changes will prevent recurrence. Publish the postmortem internally so the whole organisation can learn from it.

6. Reduce Knowledge Silos

If only one or two people know how to resolve a class of incidents, invest in pairing, runbook documentation, and cross-training until at least three or four engineers are capable of handling those situations independently.

The Business Case Is Straightforward

Some engineering leaders still treat wellbeing as a “nice to have” that competes with delivery speed. The business case argues otherwise. Fatigued engineers make more mistakes, and mistakes in production are expensive. Burned-out engineers leave, and turnover is expensive. Alert-fatigued on-call teams respond more slowly, and slow incident response is expensive.

Investing in sustainable on-call practices—better tooling, smarter escalation, fairer rotation, and a culture that values rest—is not charity toward employees. It is sound operational engineering applied to the humans who run the systems.

Conclusion

DevOps has done an enormous amount to improve how software is built, deployed, and operated. But the movement has at times been so focused on automation, tooling, and process that it has overlooked the engineers at the centre of it all. HumanOps is a reminder that the most important assets in any technology organisation go home every night—and they need to sleep.

Recognising that engineers experience stress, that interrupted sleep has real cognitive consequences, and that sustainable working practices improve both business outcomes and human lives is not a radical idea. It is simply good engineering management applied to the whole system—people included.