The Ethics of Overtime in Technology

A crunchie bar with the centre exposed.
The only good kind of crunch available in workplaces.

Recently, I took on the mantle of teaching data ethics and security to colleagues who join my company. Some people study this for their entire lifetime, so what we cover in a day isn't meant to be an entire ethical guideline of how to work, but a jump start into taking responsibility for their own decisions about how to work securely and ethically. Amongst other things, we cover;

  • The basics and principles of (UK) GDPR.
  • What does it mean to work securely?
  • The difference between working ethically in one's own work, the work the company does as a whole, and the contextual situation that those occur in.
  • What techniques can we explicitly use in pipelines, visualisations and copy to work in an ethical way.

The training runs over a whole day, but I still feel there's so much I can't cover. Making some tea this morning, I realised one of the really important ones was an item that comes up at work under the radar a lot, which is the ethics of overtime.

What do you mean this comes up a lot?

Mostly, when it comes up under the radar. Searching for "Ethics of overtime" tends to focus on sociological and management studies looking at whether or not overtime should be paid, and whether or not it diminishes the productivity of staff doing it a lot, and some legal items examining how overtime can "fit" with labour legislation. However, labour legislation is not a common chat topic in our office - indeed, we don't often discuss whether or not overtime is the right thing to do. Instead, I'd like to take you to a different district of technology land, where this has a name, and a lot more scrutiny.

Picture of a chocolate bar from the UK, which is called "Crunchie".
By Adambro - Own work, CC BY 3.0

Crunch, in game development, is the unfortunate practice of huge amounts of overtime done in the closing stages of development in order to get the product ready to meet a deadline (usually a shipping date). Crunch entered popular internet discourse with an online journal started by "EA Spouse" Erin Hoffman in 2004, which detailed her partner's unreasonable working situation at Electronic Arts, a large game publisher. Ten years later in 2015, Ian Williams in The Guardian revisited the subject and found that crunching had most definitely not gone away, and very recently famed "no-crunch" developer CD Projekt Red broke this internal rule when trying to rustle up Cyberpunk 2077 in time for Christmas 2020, resulting in one of the most spectacular blow-outs of expectations in video game history. It's not rocket science to say that crunching is unethical - it symbolic of terrible management and a toxic work culture. But how does that relate the sort of work my colleagues and I do? We aren't asked to work 14 hours a day for six days a week for months at a time, so how is this relevant?

Williams' article has a particular quote that I'd like to draw your attention to;

This may be as simple as encouraging a culture of peer pressure: quietly exploiting the natural desire to do well is a method that many of the staff we spoke to had encountered. However, we were also told of managers who noted which staff had put in the most hours when making a potential layoff list.

Ian Williams, "Crunched: has the games industry really stopped exploiting its workforce?" - The Guardian, 18 Feb 2015

For those of you in the analytics community, particularly online and in the visualisation sub community, the bells might now be ringing a lot louder than they were when I was talking about game crunch. It's not about the hours on the clock; it's about the race to the bottom culture which generated those hours on the clock, rooted in the idea that the only way to be successful in technology is to be passionate and perfectionist.

I find myself having discussions with colleagues in the evening who are doing overtime on client work. I'll message them to ask if they have watched RuPaul's Drag Race yet, and they'll explain that because of development issue X occurring during the day, they're working overtime to catch up on the planned time lost due to the other thing occurring. They couldn't have foreseen the other thing occurring, but hey, a deadline is a deadline. And at the moment (February 2021), they have nothing better to do in the evening, right?

What people think they have to take on the chin as a cost of working in a competitive industry becomes insidious corrosion on that industry, because it warps expectations of development and how long things take. In the games industry, this becomes the idea that a AAA+ game can be put out in two years, because one studio did it once in two years, and this is similar right? Well we're better than that studio, so we can do twenty months, right? And so on. Part of the encouragement of this is on the client in the first place, who are making a large investment in the game/product and naturally don't want to spend more money than possible. But there's also an expectation on behalf of the consumer. The trolliest of gamers say that devs should simply suck up their overtime complaints because hey, they're working in a dream industry and blah blah blah so much bollocks. From the consumers of our analytics products, I have also seen this start to make an appearance - you guys work in the world's sexiest industry, what do you mean the data quality isn't good enough to add in the four levels of geospatial analysis in 10 minutes? Harvard Business Review told me you guys were magicians?
This can be illustrated in the below chart.

This chart shows a cyclical diagram of five blocks. The first block says "client submits woolly requirements for project". This leads to the second block, which says "arbitrary deadlines provided to client based on said woolly requirements". This leads to a third block which says, "Devs encounter issues with requirements, general shit happening". This leads to a fourth block, highlighted in orange, which says "Devs work to fulfil the expectations and deadlines of the client". This leads to a fifth block, which says "client gets expectations based on this". This leads back to the first block, completing the circle.
A quick diagram of how the problem corrodes expectations and development over time.

The unethical implications of working overtime in unexceptional circumstances (if no one is going to die, then go home) is not that your evening is better spent watching Drag Race because stepping away from work is good for your mind, though that is certainly true. The unethical part is the obligation you're putting on the next developer, which could be you, or one of your colleagues, or someone else entirely, confirming unrealistic expectations of development. When someone does this, they are literally making the industry harder to work in for other people. It engenders that race to the bottom which prioritises people with spades of free time, who may have that because of other privileges going on in their lives - and the technology industry wonders why the people at the top of the tree all seem to be a certain way, right?

If you can't say no to overtime because of your own self worth, then try saying it on behalf of everyone else in your industry.

Thanks to my brother and colleagues who I've had long conversations with about this over the past few months.