paint-brush
40 Hours is Enoughby@jsrn
10,524 reads
10,524 reads

40 Hours is Enough

by James NuttApril 10th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

I recently read an <a href="http://brianknapp.me/programmer-60-80-hour-weeks/">article</a> by Brian Knapp dismantling the idea that there’s a benefit to getting programmers to work more than 40 hours a week. The gist is that as the hours worked increase, so does burnout. Since there’s probably not enough work to fill more than 40 <em>productive</em> hours a week, what you get is a bunch of unhappy employees who try their best to look busy while quietly resenting the company they work&nbsp;for.

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - 40 Hours is Enough
James Nutt HackerNoon profile picture

I recently read an article by Brian Knapp dismantling the idea that there’s a benefit to getting programmers to work more than 40 hours a week. The gist is that as the hours worked increase, so does burnout. Since there’s probably not enough work to fill more than 40 productive hours a week, what you get is a bunch of unhappy employees who try their best to look busy while quietly resenting the company they work for.

If you’re an employer and you’re trying to get every last drop of productivity out of your developers, ask yourself (or even them!) if any of these things are stopping them from getting things done before you ask “how can I get them to work more hours?”

What’s currently getting in the way of their productivity?

  • Excessive meetings. Especially meetings that they don’t need to be included in.
  • Interruptions. Are developers constantly being interrupted to answer questions for the support staff or give input on bugs that a user is reporting? This points to insufficient documentation and is often caused by…
  • Knowledge silos. Are small groups of people being pestered for things that only they know? Are others held up waiting for a single source of knowledge to get back to them?
  • Firefighting. Are developers always rushing from emergency to emergency? This could be a sign that there’s too much focus on pushing out new features and not enough focus on finishing things properly.
  • Technical debt. Is too much time being spent going back and repaying technical debt? This is the horrible sibling to Firefighting. Debt always has to be repaid eventually, and it’s often cheaper to take the time to do things right the first time.

How can I help them engage with and care about the product and its users?

  • Do employees feel as though they’re working on something valuable? It’s difficult to maintain motivation if you’re not convinced that your current task is worthwhile.
  • Do employees see the impact the product has on the user base? Testimonials, sales information, feedback. Any indication that what they’re doing is having an impact on the world.
  • Are features chosen because they fit the product or to chase sales? It’s demoralising working on a difficult or disruptive feature that hardly anyone is going to use.

How can I show my employees that I care about them?

Unless they’re motivated purely by money (which almost nobody is), people work harder when they feel cared for. If you want someone to feel cared for, don’t ask “how can I get them to work 80 hours a week?”

Let’s look at the numbers. There are 168 hours in a week. Let’s be optimistic and say that people get 8 hours of sleep a night. That leaves 112 waking hours. With an 80 hour work week, that leaves 32 hours. That’s about four and a half hours a day in which to travel, work, eat, and, y’know, live. Why would you want to do that to somebody you care about?

If you actually want your employees to feel cared for, identify and resolve current problems in their working lives. Or buy them beanbags or something. Just don’t chain them to their desks.