Having worked at a company that did a four-day week, I'll chime in that it was both amazing and eye opening. I say that as someone who had read Tom DeMarco's now-classic book Slack[1] long ago, after a lot of up-close and personal with the antipatterns described therein. Intellectually, I expected something(??) good but the reality was even more suprising. With a four-day work week, I was able to complete (solo!) a production website application upgrade (Rails 2.x to 4.5) in a very reasonable timeline, and less than I'd heard competent teams failing the same task elsewhere. This wasn't because of any "10x developer" nonsense - it was clearly because I had a /three-day weekend/ every week and came in on Monday clear headed and ready to HIT IT, BABY.

Let me be clear: I later realized that this project would have been a soul-draining death march at many other places I'd worked in my career. Exhausted just a few weeks in, with management hounding the team for schedule estimates that can't possibly exist because management failed to fund maintenance for years.[2] (There were actually rational reasons for this, in this case. tl;dr the project got renewed interest and investment due to a new business case.)

To those who lament on this topic about "devs (in country X) just aren't motivated these days" or whatever, let me suggest something. If you have poor clarity of purpose, poor giving-a-fsck about humans, or a number of other culture failings then yes, you may encounter problems. Your solution is still not to tie your knowledge workers to their desks. You need to fix the root causes of your underlying productivity debt, not pave over them with an overwork-butts-in-seats mentality which just makes things worse in the long run (<--- read DeMarco).

[1]: https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...

[2]: Pro tip: "evergreen" ecosystems, especially young and rapidly changing ones like early-mid Ruby/Rails and a lot of current npm/JS-based stuff, often have a wickedly non-linear cost curve if/when maintenance and dependency updates fall off. Some of the most expensive I've encountered of this ilk is when /test infrastructure/ incurred a lot of past churn that wasn't tracked, but suddenly (cough) needs to be updated.

The article can be summed with with a link to the book it itself links:

https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...

There's even a whole book about this: https://www.amazon.com/dp/B004SOVC2Y (by one of the authors of Peopleware[1], which is also excellent).

[1] https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...

Tom Demarco wrote Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency[1] back in 2002. It talks about how keeping slack in human systems makes them more resilient and humane. I first heard about it from Joel Spolsky, who started Trello and Stack Overflow[2].

Slack is a great read for those responsible for managing software teams and illustrates that there are no new ideas under the sun; there are just repackaged ones.

[1]-https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...

[2]-https://www.joelonsoftware.com/2005/11/22/reading-list-fog-c...

This seems like an opportune time to mention "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco (DeMarco is better known as one of the co-authors of Peopleware).

https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...

If you've read and liked Peopleware, you should read Slack as well. If you haven't read either one then you should.

One of the commentators on the story says: "An empty plane flying every night – an excellent example of the value of spare capacity. But I wonder how many organisations would have taken a narrow view, classified this as “waste” and cancelled it?" is so on point. Reminds me of Tom DeMarco's Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ( http://amzn.to/1H4qRld ) which is all about having slack (spare capacity, which means not having 100% efficiency) in order to deal with unplanned issues. Failing to have slack results in a slow grinding process when issues arise and has enormous opportunity costs.

>I make sure 1 other person knows what someone else has done, even my own work

I try to do the same. I've often viewed my job as trying to eliminate my job by slowly delegating and having others able to fulfill my current responsibilities. Then I take on the next "level" of responsibilities and/or provide either more slack in my schedule or others. Slack is what allows organizations to operate smoothly and deal with change(s).

If you aren't familiar with the concept of slack, I highly recommend reading "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco

http://amzn.to/1sGWsWe (affiliate link)

http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...

Also Peopleware http://amzn.to/1TYIMio And Slack http://amzn.to/1CDfnj4

Demarco is great!

Slack is crucial for all businesses.

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco is a great read.

http://amzn.to/1KGF8DG (affiliate link)

I think Tom DeMarco makes the same point in the book Slack: http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...

He didn't - IIRC - talk about "20% time" specifically, but Tom DeMarco wrote a whole book about the importance of "slack" time at work. One point he makes is that if everyone is too busy doing the routine stuff 100% of the time, then the firm can't adapt quickly, because nobody has time to learn anything new, do exploratory / speculative work, etc.

His book Slack is a fascinating read, and I'd recommend it to any HN'er who hasn't read it yet:

http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...

http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...

"Slack" is also a great read: http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...