One Day Work Week

I'll not be talking about this idea of being able to only work a single day in the week - if you can, great for you, but I'm not there (yet?).

The One Day Week I refer to is a situation I now experienced at two different customers - due to my "time slicing" approach to freelancing (I've between 2 and 3 customers at the same time and I split my days between them) which is working a single day a week for a given customer/on a given project.

This lead me to some insights.

The days and the calendar

The most immediate impact is the wide difference between the work days and the calendar days. A small feature requiring 4 days of work is now a full month. A medium sized one of 10 is almost a quarter.

Assuming the rest of the project/company is not working on the same scheme (that's unlikely) and is going to continue to run on the other days, it make any task coming my way a very lengthy one

No time for getting in

Working on one day chunk means no or very limited time to "get in". Taking half a days to get back in stuff after a week of holidays will be (rightly so) considered ok.

Doing so every day of work, not.

It means organizing the work so that I can get "in" in less than an hour. Either because I've good notes (see later) or because I start something new that is well prepared/scoped.

Collaboration aspects

This also means that nothing I do can be blocking for colleagues - or the very very minimum. So even more than usual, well prepared, autonomous tasks are the only reasonable way of working.

Something I experienced already also is no regular meeting or any overhead - a two hours team meeting may be very reasonable out of a 40 hour week (that's 5% of the time) - much less so out of a 8 hour week (because it bumps to 25%).

Small tasks/deliveries

This is as usual the key - one day workweek only works if deliveries are split into single day or maximum couple of days tasks (two days is already half a month!).

While not easy (I always say that pretty much everything in software development can be made simple by splitting it into small pieces - but that splitting is generally quite difficult), the "one day workweek" context moves this from a "good thing" to a "mandatory one" - something that's generally beneficial to the team/organisation (short, regular deliveries).

Notes to self

Knowing that if I don't finish something completely by the evening I'll go back to it in a full week means taking a lot of notes to preserve context - I generally either have them in the task tracker (so I can easily get back where I was) or even directly as an appointment in my calendar scheduled at my next hour of work for that company.

This takes the form of a "letter to future me", with status but also/mostly ideas of next moves and "voiceover" of identified unknowns/things to try/etc.

The idea is really to have a "snapshot" of my mindset at a given time in order to restore it as fast as possible.

It's tough

Let's be honest, starting this was really tough. Each day means being very precise about the goal/output to make sure to have it done (or at least a viable PR) by the end of the day.

That put an unusual pressure on my "delivery or die" kind of freelance approach - I'm here to produce outcome, not code or even outputs - doing this on single days iteration is not easy.

It works (under certain conditions)

I've done this for some months at two different companies and I can confidently say that it can works - as is, generate real value for the project.

Among the conditions I'd require:

• Mature stakeholder with efficient communication - in one of the cases, I had something "finished" each week, so each new day started with a 20 minutes call with a stakeholder about the next need, followed by quick chat Q/As when needed, and a PR at the end of the day.
• Seniority: I would not have risked this early in my career. I'm playing on my seniority as in fitting in capability here.
• Dedicated area with limited contact surface with other developers: It's difficult to work this way on part of the code that are under heavy changes by the team

Things I've done using this scheme:

• Performance improvements
• Refactoring (with the idea it does not need to be done in one single session, as long as it can be merged after each, incrementally improving the situation)
• New (small) features, using feature toggles if needed to be able to deliver them in one day chunks

I also thing that the approach force me to challenge even more the "this cannot be split in deliverable parts" - because it usually is, if you dig a bit more.

Opinions? Let me know on LinkedIn!