The 40 Hour Work Week
The 40 hour work week is an odd thing for a developer or any knowledge worker for that matter. Even the simple question of “when are you working?” is not easy to answer. When the output of our labor is not mechanistic, it’s very hard to quantify what value we provide and how we are performing it.
Since our work is very hard to quantify, management needed a different way to evaluate it. They settled mostly on a location-dependent attendance model augmented by their intuitions. It’s easy to see why a few problems might arise using this approach. This is one big reason the shift towards remote work has the potential to make a huge difference in productivity and job satisfaction.
When Are You Working?
Is it when you’re sitting in your office in front of your computer? What if your mind drifts off for 10 minutes to a relative who has health problems, does that count as work? You are sitting in the office chair in front of the computer after all.
How about when you take your evening walk around your home neighborhood and you spend 30 minutes thinking about how to solve a problem for work. Does that count as part of your 40 hour work week?
These are silly examples. Silly because they highlight the absurdity of how our work is tracked and ostensibly how we are paid as knowledge workers. In truth nobody tracks every minute of the day that they worked or thought about work.
It’s the fundamental difference between knowledge work and mechanistic work. Non-linear work vs linear work, in other words.
The Shift to Remote Work
Transitioning from in-office work to remote work is more than just changing the physical location of work. It tends to shift the primary evaluation of a worker from attendance based to output based.
When you’re working in the same physical location as all your coworkers, it’s too easy for cognitive biases to overwhelm everything else.
For example, John is socially awkward and has bad BO. He also has some health problems, so he’s not able to sit in his office chair for 40 hours a week. But his coding is bulletproof and he completes stories with amazing efficiency. Yet he’s still likely to be treated by management as a “difficult employee.”
Todd on the other hand is always impeccably groomed and easy to talk to. He’s always in his office chair for the whole 40 hour work week yet his output is poor. In the in-office world, Todd is more likely to get promoted.
Remote work gives us a better, while not complete, solution to this problem. In a fully remote company, John is far more likely to be correctly recognized as a high performer. While Todd will not be unduly elevated merely by having good attendance and grooming habits.
Managing a remote development team also becomes easier to evaluate. In short, it’s easier to recognize whose output is high and whose needs improvement. This is achieved by removing an impediment, i.e. the cognitive biases as shown in the John and Todd examples.
To wit, this is the Via Negativa principle in action. Nassim Nicholas Taleb covers this at length in Antifragile.
The Future
It’s always perilous attempting to predict the future. But what the heck, let’s have a go!
I believe the 40 hour work week will continue to wane in importance. Particularly as more development teams go fully remote. Removing the butts-in-the-seats imperative of in-office work will free up workers and management to focus on more important things like output.
I don’t expect the compensation model to change, at least not imminently. The 40 hours times an hourly rate seems too ingrained in the enterprise world.
Using an output based model we can more accurately determine who is adding more value to the team. However, that’s still a far cry from being able to translate output to value added to the company. This is a much more difficult problem that I don’t anticipate will be solved any time soon.
Summary
The 40 hour work week is not well suited to knowledge work. It largely endures due to inertia.
Quantifying what counts as work for developers is very difficult. We are not simply making widgets, therefore counting hours to task completion is rife with ambiguity. Our tasks vary widely in both complexity and value addition.
Shifting to a remote work model has the potential to improve this situation by focusing more on developer output. This can help mitigate human cognitive biases which are inescapable in co-located work environments.
The future of the 40 hour work week may diminish in importance for developers. This is assuming the shift towards remote work continues to accelerate. Both would be welcome changes for us knowledge workers.