HN Books @HNBooksMonth

The best books of Hacker News.

Hacker News Comments on
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

Tom DeMarco · 9 HN comments
HN Books has aggregated all Hacker News stories and comments that mention "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco.
View on Amazon [↗]
HN Books may receive an affiliate commission when you make purchases on sites after clicking through links on this page.
Amazon Summary
If your company’s goal is to become fast, responsive, and agile, more efficiency is not the answer--you need more slack. Why is it that today’s superefficient organizations are ailing? Tom DeMarco, a leading management consultant to both Fortune 500 and up-and-coming companies, reveals a counterintuitive principle that explains why efficiency efforts can slow a company down. That principle is the value of slack, the degree of freedom in a company that allows it to change. Implementing slack could be as simple as adding an assistant to a department and letting high-priced talent spend less time at the photocopier and more time making key decisions, or it could mean designing workloads that allow people room to think, innovate, and reinvent themselves. It means embracing risk, eliminating fear, and knowing when to go slow. Slack allows for change, fosters creativity, promotes quality, and, above all, produces growth. With an approach that works for new- and old-economy companies alike, this revolutionary handbook debunks commonly held assumptions about real-world management, and gives you and your company a brand-new model for achieving and maintaining true effectiveness.
HN Books Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this book.
The article can be summed with with a link to the book it itself links:

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.



Oh boy, the rabbit hole. Check out this:

Yep, a linux based on the idea of Slack, developed '93.

And just as there's the Spaghetti Monster, there's also even a religion around Slack:

developed '79, short quote from wikipedia: "the group holds that the quality of "Slack" is of utmost importance—it is never clearly defined"

I've been using Slackware as my primary OS for a few years now (even my work computer runs it). In retrospect, Slackware fits the article's mentality remarkably well; instead of the approach taken by most Linux distros (where everything is neatly and tightly integrated with a dependency-resolving package manager and dependency-resolving init system and all that jazz), I instead work with a system that sure, maybe some of the pieces don't fit together perfectly, but they're readily adaptable to all sorts of different situations. It's a less fragile system specifically because it's built around accepting the components for what they are instead of trying to patch them to "perfection". And of course, the conservative component choices certainly help, too.
That's exactly where my mind went as well.

You want some amount of inefficiency in your system to accommodate sudden changes.

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).

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

Hi there, I'm quite new to engineering management as well, with approximately one year of experience. I've had some great mentors, as well as a reading list passed down to me. I'll highlight those I found as having the most impact for me.

At the top of the list is "Managing Humans: Biting and Humorous Tales of a Software Engineering Manager" by Michael Lopp[1], which was recommended to me by a manager who helped me get my start in engineering management. This book touches on a lot of the nuances in dealing with people and, as an introvert, I found this really helpful. The same author blogs under "Rands in Repose[2]" which has much of the content from the aforementioned book available for free.

While in the people category you'll also get a lot of recommendations for "Drive!" by Daniel Pink[2], which is a book about intrinsic motivators (autonomy, mastery, purpose) and how they are more important and effective than extrinsic motivators (e.g. money), particularly for knowledge workers. My personal advice, however, is to watch his TED talk[3] which is a great summary of basically the entire book. In this same category I could also recommend "The Great Jackass Fallacy" by Harry Levinson[5].

Now on the wall between people management and engineering/project management is "Slack" by Tom DeMarco[6], which is about how organizations and managers tend to run their staff at 100% capacity. As the book points out, however, this is a good way to not only burn people out, but it also sends response times through the roof (from queuing theory), and stifles change ("too busy to improve"). You can read this one on a plane. For some shameless self promotion, I've also written a tiny blog post relating Slack and the need for upkeep (software operations and maintenance)[7].

Next, fully in engineering/project management, I have to recommend "Waltzing with Bears" by Tom DeMarco and Anthony Lister[8], which is specifically about managing risk on software projects. The authors highlight the common practice of project/engineering managers communicating their "nano date", which they point out is typically the lowest point on the uncertainty curve. In other words, the project has the lowest possible chance of shipping by this date when you look at the possible timeline as a probability distribution. This book changed the way I talk about projects and the way I manage my team's various risks and I have been more successful as a result.

One final recommendation I'll make, since you're in the midst of a transition, is "The First 90 Days" by Michael Watkins[9]. It's a wonderful book that outlines how and why one should develop a transition plan in order to hit the ground running - and in the right direction. For my last engineering management opportunity, developing a preliminary 90 day plan as part of a "starter project," was a major factor in being given the job.

I believe that a subset of these will give you a great start. After that, you should read on the areas you feel the need for the most amount of help with or the areas that interest you. If you are avidly interested in project management, for example, you should read books on various methodologies, particularly the one that you or your organization practice.










Apr 24, 2013 · henrik_w on Hacking debt
I think Tom DeMarco makes the same point in the book Slack:
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:

damn, I totally should have mentioned that in the post. I'll add it via an edit.
HN Books is an independent project and is not operated by Y Combinator or
~ [email protected]
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.