Making the four day week a reality

by Dave Barter on

The "Four Day Week", a headline grabbing aspiration put out by the T.U.C or a reality? Is it really possible to operate a company on a four day week and remain productive and competitive? Is it doable without huge degrees of automation or cuts in wages? Can there really be any benefit to the employer, surely this is just a socialist pipe dream?

I don't have empirical answers to the questions tabled above but as a CEO I have an instinct. And my instinct tells me that a four day working week could possibly help grow my business rather than hinder it. As a result we've taken the brave decision to move to a four day week as of right now. Here's our story, how we arrived at that decision and how we think it's the right one for business and employees alike.

"Open sourcing" - improving the code by opening the doors

Richard (CTO) and I have grown and run Nautoguide for years, fueled almost entirely by enthusiasm. The only money we've burnt has been our own, which means stretch targets have often been achieved by late nights and the occasional compromise. It's a truth to say that the compromises have always been made in favour of our customers rather than ourselves. On occasion we've had to prioritise their functionality over the things we'd like to accomplish. This has left us with a massive list of tasks in the "to do" box. I don't mind admitting publicly that some of our code is perfectly functional but hard to maintain. For example welcome to the regex from hell:-

var re = /~([a-zA-Z.]://a-zA-Z_/.0-9@\s#-[a-zA-Za._0-9][:]{0,1})/g;

This particular line of code has been integral to our systems for years. It even has it's own movie poster. Every time we have to go near it there are muffled screams in the office. We keep meaning to refactor that whole area of the system but time and other priorities prevent this.

And the regex from hell is where it all started.

Richard and I were discussing the regex and lamenting the fact that we keep meaning to sort it all out. I started chuntering on about making time in the calendar but shut up quickly when we both realised that it would always get shifted by another higher priority. The code works and it's a hard decision to park everything and give it some love. Stuff that doesn't work or hasn't been built and needs to be would always get priority.

And then Richard said this:-

"Maybe we should just open source it all? That way someone else could get rid of the regex and replace it with something better"

But then he said this:-

"Problem is, we'd need to sort out all of the other code, get rid of the legacy stuff, document it and make sure our tests are comprehensive"

And there was our revelation. Richard was right, in order to open source our codebase we'd need to make sure that others could understand it. We'd need a bit of refactoring to make it a bit more intuitive and of course decent documentation would be required to help strangers understand what was going on and contribute accordingly. This all sounds hard but surely this is what we should be doing anyway? Or we'd fall into the common trap of the complacent growing business that thinks they can always dig themselves out of the messes of their own making. Sometimes the pile just gets too high.

So we've decided to go fully open source. We've decided to let go of the idea that our IPR is solely vested in the code we've written and instead we're measuring our value in our role as curators of something we've conceived and nurtured. This drives new discipline in our work and offers significant benefit to our customers who will soon have full transparency over what we've done and the option to do it themselves in the future. There's no better catalyst for improvement than public scrutiny and that's what we hope to achieve by moving towards open source.

Great decisions come with great impact

So Richard and I brought our great idea to the wider team expecting them to welcome it with open arms and get on with the job. This didn't quite go to plan. It was seen as a load more work in a schedule that we occasionally struggle to deliver. The team were moving from task to task barely having time to breathe. As soon as they'd finished one thing it was on to the next or fixing something that had broken as a result of change. This was down to Richard and I, we were not managing the team well enough. We were taking very little time discussing architecture and design with them. They were expected to pick it up as they went along, "It's obvious isn't it?".

Consequently we were in danger of letting standards slip and more importantly having our architecture stagnate as time squeezed individuals wrote code that works rather than code that leads to a vision. This lead to our second revelation. Let's give ourselves more thinking and planning time and thanks to the T.U.C we found the answer.

After discarding ideas such as Friday planning sessions (always canceled by urgent support requests), Tuesday pizza meetings (waistlines say no) and daily stand ups (sorry we tried that agile and got backache), we took another tack. Why not force thinking time upon ourselves by not going to work.

It's a fact that we have our best ideas when the mind is allowed to roam. We work best when refreshed rather than at the end of an eighteen hour shift. We're loyal when we think our employer actually cares about us as individuals. And finally how great is it to have a day when you'll actually be at home once a week to catch the postman writing one of his sneaky red notes.

We've postulated that as a business we'll grow faster by thinking smarter across the board rather than putting in more hours. We've decided that all of us are now working four days out of five. Our hypothesis is that the four days will be much more productive, as five is simply dilution of a fixed amount of mental effort that can be put in. And our work is primarily mental.

The full premise of our four day week is this:-

  • we each nominate our casual day and ensure that we've full cover throughout the week (not everyone can have Friday when all the support requests come in)
  • the casual day is not spent working, its for enrichment, such as riding a bike, reading a book, tending to some flowers or winning at Fortnite
  • sometimes bad things happen and on your casual day you must be ready to help out if required, please keep in touch
  • the casual day is a place where you digest your work and use it to breed new ideas or improvements, this may seem counter to "not working" but we're hoping it's a natural byproduct
  • the remaining days are much less casual, they're focused, you now have to achieve what you previously did in 4/5ths of the time or we probably go to the wall
  • we all strive to make the casual days work, they live if we thrive and die if we wither, we own the casual days as a team benefit not an individual right

Jam Today

And so this week we took a collective decision to move to this new model. We see it as a major spring clean at the wrong time of year and are excited by the breath of fresh air its blown into our business. We're doing two things that seem counter to any business strategy you've ever read. Working less days and giving our stuff away for free. But I like to think of this as disruption. All the funky startups have disrupted things left right and centre whilst losing their life balance in the process. We're attempting to disrupt from the other end of the scale by improving our lives first in order to drive growth within our own business as a result.

Finally, let's discuss motivation. Isn't it typically attempted via the "jam tomorrow" route?. Work hard and then there will be reward, hopefully? We're hoping to buck the trend of jam tomorrow with some jam today. Why do incentives always have to be paid after effort? Isn't that showing a level of distrust in your employees? In this case we think we're asking them to do the right thing because we have. Which may prove more of an incentive than the tired old model of sweating hard in the hope of a distant pay-off.

It's a potentially risky undertaking and one that we'll be keeping a close eye on. But I hope to come back here in six months time and show you a set of figures indicating that Richard and I got it right, along with a link where you can browse all of our splendid code and agree that the process is working.

Making the four day week a reality

Contact us

Subscribe to Nautoguide