Recently, I’ve said a lot of bad things about “busyness”. I stand behind all of them, but that does not mean that the way to be agile and lean is to do nothing.
It is not true that just because you’re doing something that you’re delivering value. It is also true that you must do something in order to deliver value.
Today we’ll look at some research on relating hours worked per week to long term productivity.
Why does this matter?
Working in software can be a rather terrible experience. It can also be fantastically rewarding when your hard work and long hours make life better for (potentially) billions of people.
The trouble is that there’s too much of the former in the world.
There’s more legacy code than not. There are more deadlines than vacations. And no one ever seems to understand why things take so long or that by asking for feature “X” there will be an impact on the timeline for feature “Y”.
The result is a very short developer half life. From graduation until the age of 40, here is a continuous flow of people leaving the profession. For an organization, this is terrible. Just as people become masters of their craft with all that time and energy having been invested into their development in that arena, they leave it.
There may be some elements such as people becoming managers at play here, but most engineers don’t become managers.
As an industry, there is a brain drain that occurs. It simply hasn’t been an issue yet, because the new graduates are plentiful enough to fill the need. But we shouldn’t be satisfied with that.
Why does this matter? It takes years to develop skill mastery, and by 40, most engineers are likely at that skill level. These people could be tremendous assets to to building truly world class software. Maybe you also care about your own work-life balance, quality of your work, and if you’re a leader then these attributes for your team members. If that’s not enough, consider an agile principle that reinforces the need:
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This may be the most obvious element of this article to anyone in software. That having been said, it’s also the most frequently violated (even by those who intuitively know that it’s true).
The idea is that when we consider hours worked and productivity, there will be a range starting from zero where for each extra hour worked, I’m positively increasing my productivity.
While in the next range, as I increase the number of hours worked, my actual productivity doesn’t really change. It’s neither increasing nor decreasing.
In the final range, for each extra hour worked, my productivity actually decreases. Continued long enough, and each additional hour worked may actually be undoing the preceding hours’ gains.
Loosely, this could be pictured as an upside down “U”. As a concept, it actually applies in our world in many scenarios. Often we fail to understand that the outcome we’re manipulating lies on one of these curves. For a period of time, the changes we make get us the result we want (working a few more hours to get stuff done, reducing class sizes by a few students to increase learning). However, there reaches a point when changing that variable stops helping. Worse, if taken too far it can actually be a negative. If I work 120 hours per week, my output is likely of poor quality and will require much rework. If we have only 5 kids per classroom, the ability for the kids to sustain a productive dialogue or have sufficient skill diversity may actually impede learning.
For a great book that delves deep into this idea, pick up Malcolm Gladwell’s David & Goliath. We know enough of the idea here to continue, but there’s much more to be said for understanding this idea more thoroughly.
Points of Inflection
If we take the lesson of the “U” curve to heart, then there are two points we need to identify. The first is at what point working more hours actually causes productivity to decrease. The second, is the point at which productivity appears to have reached it’s peak. Anywhere between these values, is likely a good place to find optimal productivity.
One important consideration is that we’re concerned about these values sustained over a long period of time. Returning to our agile roots, this is the pace that everyone should be able to sustain for their career.
Maximum Sustainable Pace
As Henry Ford was getting started, the vast majority of Americans were working 12 to 14 hour days. There had already been people lobbying for 8 to 10 hour workdays for over a century, but this wasn’t the norm.
Regardless of the motivation, Henry Ford instituted an 8 hour day for all factory and office workers. This was a decrease from 9 hours per day. Despite the reduction in hours, there was a significant boost in productivity. Over the next two years, his profit margins doubled.
What does this tell us?
9 hours per day is beyond the peak of the U-curve. 8 may not be optimal, but it yields better sustained results than 9.
Many countries have found a similar upper limit and passed laws that impose penalties on companies with employees exceeding 35 hours per week or outright bans on working more than 48 hours.
What does this mean? As a general rule, you probably shouldn’t be working more than 40 hours per week. Over the long term, it’ll contribute to burn out and it’s actually reducing, not improving your productivity.
Minimum Sustainable Pace
As noted earlier, some countries consider full time work to be in the range of mid-thirty hours per week. They’re not alone in finding that to be optimal. Moreover, those researchers found that the 35 hour week was best for mistake prevention, a costly element of software delivery.
Rather than beat this to death, let’s assume that the ideal value may vary a bit from person to person but that it is likely in the range between 35 to 40 hours per week.
Keep in mind, this is not the minimum. This is the net hours. If you plan for 40 but have a night or two you stay late per week, then you’re likely exceeding your sustainable pace. If you shoot for the middle of the range, that gives you some slush room on both sides while still maintaining a sustainable level of peak productivity.
What Is a “Working Hour”
Does this include lunch? If I take a brain break for an hour, is that work or not? What if I’m still in the building?
I don’t know.
I’d encourage you to just keep this limit in mind and evaluate how you feel over time. At the least, you should have a sense if you’re notably over or under. If you’re close enough that you’re counting the minutes you spend walking to Starbucks everyday, you’re probably fine.
Some of that research made a point of saying that the way we distribute the hours doesn’t impact what the total is. Whether it’s fewer hours over more days or more hours over fewer days didn’t seem to matter.
That supports a different argument to help people sustain a better work-life balance, to get away and to return with a fresh perspective. That is to shift to a 4 day work week. This offers a 20% reduction in days worked and a 50% increase in days off. It also makes it easier to work what is regarded as a full day while respecting the ideal limit of hours. Likewise, it removes some opportunities for people to over extend themselves and ultimately deplete value from the team by staying late.
There are some cautions to go with this idea. One is that for it to work, everyone must be on the same 4 day schedule. Otherwise, a fear of missing key talks or being omitted from decision making may cause people to forgo their extra day off, or at least not use it well. With that in mind, there are many scenarios where teams must provide support during all traditional business hours and that may make it impossible to have such a schedule and avoid that pitfall.
Regardless of how long a weekend may be, use it. Not taking the time off to refresh yourself will do more harm in the long term than good in the short term.
How can I keep up by doing less?
There are two sides to this. The first, is to be very purposeful with the time you do invest into work. Prioritize and be prepared. If you need help figuring out how to prioritize your opportunities, refer here. The second is the cruel irony of this whole thing. Your overall productivity can actually go up by working less (especially if you’re at an extremely high number of sustained hours). It may not feel that way, but your mind may be lying to you. Remember, being busy is not synonymous with value delivery or productivity.
What is the right balance?
There may not be a one-size fits all answer, but perhaps some of the ideas we’ve discussed may provide some guidance. Just remember that feeling as though you’re getting a lot done doesn’t mean that you are. Our goal shouldn’t be a great day, week, or month, but a great career within an even better life. Our goal is a pace that is sustainable by all contributors for their entire career. It may feel as though you’re losing a great deal of productive time, but remember that each shortcut has a cost. Sometimes it’s defects. Sometimes it’s rework. Sometimes it’s high blood pressure at 40. Sometimes it’s a heart attack at 50. Sometimes it’s being disabled at 60.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Trust is more than just acknowledging that the tech folk know software engineering and can choose a framework better than their manager. It means trusting that being away from the project is sometimes the best way to contribute, that they’re growing professionally, and that you will want to use their ever-growing expertise for future projects. For that, though, the engineers must still be alive, they must still work in software, and they must still work here.
Don’t be afraid to go slow to go fast.
How often do you work over the weekend?
How much of your vacation time do you not use?
How often do you answer e-mails late into the evening?
Can you sustain what you’re doing forever, or do you keep thinking that you’re just one or two milestones from finding a better balance?