If you’re not aware of the reason why pizza is the primary catalyst for the entire McAllister character arc in the home alone franchise, you should totally watch the film(s) again and then come back. Pay attention. There will be an exam at the end. This is important.

Oh for the days when I, too, could indulge in the culinary perfection that is a freshly baked, oozy cheese pizza with all the joie de vivre and exuberance of youth, as Kevin McAllister does, and continues to do with every spin of that archaic Home Alone DVD. But alas, dear reader, it is no longer to be. That hazy, halcyon time is lost now, tinged with the unpleasant taste of other memories, now a Pavlovian-pizza response which whispers to me… ‘overtime’.

OVERTIMMMMMMMMMMMMMMMEE!!!

Alas. Alas and foreshame. All Italian-based culinary hope is lost. God love you Kevin McAllister, you Peter Pan boy who never grew up to learn of the atrocities done in pizza’s name.

I’m pretty sure that I’m not the only person that has the connection between overtime and pizza imprinted upon their conscious. At some point or another, as inevitable as death and taxes, on at least one project you will have worked on you will have heard that optional-but-not-really-optional rally cry to the project team to stay late: pizza party time! Except, of course, the party is replaced with slightly frantic coding as the deadline looms and the project managers look increasingly nervous. The delights of pizza cannot be realised on a Saturday afternoon, whilst a beautiful August day unfolds outside your office window, sat with three other poor, lost souls, frantically coding. The pizza is no longer the gooey, cheesy deliciousness that it once was.

Skeletons don’t want pizza. But do wear snazzy ties.

And so I say unto you, dear reader, no more! This culture of overtime, this culture of ‘Crunch Mode’ before launch, should never be considered the norm. It’s not the answer to an impossible deadline, and it can easily do far more harm than good. If you’re considering asking your team to work late in order to hit an ill-conceived deadline, because there isn’t enough time in a regular working day to get everything done, then something has gone seriously wrong somewhere up the chain. Like a critical issue found in a live product, this should be the call for retrospection on how the team has ended up in this situation; and actions should be taken to ensure it doesn’t happen again.

There are few other industries where it is taken for granted that early starts and late finishes and weekend work are part and parcel of getting something out of the door. You don’t see car manufacturers working until 2am to get a shipment ready, and you don’t see builders habitually setting concrete at all hours of the day and night to get a building finished. So why does it seem like it’s part of the culture in a lot of tech organisations to consider this normal? And to boot, when we’re working in an industry considered to be the front-runners when it comes to working in a flexible, agile environment, why do we allow ourselves to be held to, and indeed why do we create for ourselves, these immovable, unreachable deadlines?

The deadline we are up against. What japes!

This isn’t just because of the fundamental conflict in principles here. Overtime is also proven to be immensely counterproductive to the codebase, general health and mental well-being, cost to the company and morale. It’s long been proven and countless studies have shown that the quality of output over the course of a twelve hour day will plummet in comparison to the productivity and quality achievable in a ‘regular’ working day. As the hours increase, it’s only natural that attention to detail will wain, and alongside that a whole host of other nasty side effects can creep into the picture (increased absenteeism, higher turnover, an increase in errors and so on) that wouldn’t arise if the work-life balance for your employees is optimal.

In addition, when this becomes the norm within an environment then the usual by-product is that the members of the team with the least influence over how we’ve ended up in this position are the ones who are paying the price for it. Those doing the development work and the testing, those least involved in setting those deadlines in the first place, are the ones who are working those extra hours in order to make that deadline. That’s not a pleasant situation to be in by any means, bearing the brunt of poor decision making up the chain that you have little to no influence over.

Of course, I’m not suggesting here that we live in a perfect world where there aren’t honest to goodness unavoidable situations where a couple of extra hours are essential to getting something over the line – but this should be very much the exception, and each time this happens we should be looking inwardly as to how we can ensure it doesn’t happen again. The need to ask your team to stay late or work weekends is a glaring indication that your process and company culture needs improvement, and those improvements might be required in a whole host of areas. Here’s a couple of big potential reasons:

Managing expectations and relationships

If you’ve arrived in a situation where you can’t have a reasoned discussion with your client (or any other stakeholder) about a deadline, then there needs to be a focus on ensuring that expectations around delivery are managed better; and fostering a culture of trust between yourself and your stakeholders should be central to enabling this, allowing all parties to recognise (and be comfortable with) the idea that that nothing is ever perfect. This environment should be championed all the way up the chain, ensuring that all parties that may be affected by the release of your product are on board with the idea that dates may well need to change. In a world of contracts this is tricky to achieve, sure; but this comes down to how you articulate what your deliverable are; establishing the outcomes you’re driving towards with a release, rather than the specific output from a team. Sure, we should be working in an environment where these delays are few and far between, but the solution to them shouldn’t be to the detriment of your team’s wellbeing, it should be to ensure those issues are prevented in the future. Those inevitable delays should be mitigated, not plastered over by extra hours; no delay in release is worth the health and well-being of those people who are fundamentally creating the product that you’re wanting to release to the world.

Managing throughput and flow

If your process is rife with bottlenecks and long delays, then care should be taken to ensure that the team has focus on managing flow more effectively, allowing earlier feedback and a more reliable cadence. This is also key for establishing regular releases and output without a detriment to quality. Once a team establishes a streamlined process, those commitments to deadlines and discussions of release dates can start to be grounded in reality rather than finger in the air, because we know, to a better degree, how long something might take to deliver.

Poor requirements gathering

If we’re finding ourselves frantically building out new features and deliverables at the last minute, then we should be looking at where we can make improvements in our requirements elicitation to ensure that our idea of what good looks like is established as early as possible, that all stakeholders are aware of the goal we’re trying to achieve, and that changes to this are managed in a rational and collaborative fashion, rather than being thrown in ‘knee-jerk’ style.

Poor risk management

If we’re not assessing the risk of each deliverable that we’re trying to build, we’re fast going to approach a situation where unexpected issues in the product can emerge. Each deliverable should be carefully assessed in terms of impact to the codebase, and this becomes an increasingly critical step in the process the closer we get to a release date.

More discipline required in prioritisation and the MVP

Establishing a strong prioritisation focus is front and center when it comes to ensuring that a launch date can be achieved, and this ties in to focusing on building a ‘why’ rather than a ‘what’; if we have a strong idea of the fundamental problem we’re trying to solve, rather than a laundry list of features that must be included in order to go live, then we have a more effective base from which to ascertain whether a ticket or feature really needs to be included in order to hit an MVP definition of done. Can the product attempt to achieve an outcome, or a KPI, without this specific feature? If so, then we’re probably in a position where we can park this piece of work and plan it for a subsequent release.

The unfortunate fact is that, when your project gets to the point where overtime is the solution, it’s probably too late to remedy in this instance. The trick here is to ensure that the opportunity to review the lessons learned from this situation is taken, and that everybody is involved in ensuring that the dreaded pizza party doesn’t happen again. Sorry Kevin, but we all should be eating a little less pizza.

You’ll thank me later. I Promise.