Name: Slack
ISBN: 9780767907699

Slack

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.

What Hacker News says

vonnikJan 2025

relevant:

Slack, by Tom DeMarco https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...

thread

NomDePlumJan 2025

Peopleware is indeed still very relevant. Always felt Slack by DeMarco made important points around efficiency seeking damaging actual effectiveness, which I always found very convincing and chimed with my own experience.

thread

BlackstratMar 2023

I managed developers for a long time, prior to retiring. Generally, except when I worked for a company filled with PMPs, I asked developers when they would complete an assignment if things went well and if they didn't when. I didn't ask for task level estimates. I did ask for descriptive write up of the direction/approach and any intermediate milestones that told them they were on track and how well the project was going. Over time, I learned who was good at this type of estimate and who wasn't, who sandbagged, who was overly aggressive, etc. It took some time to get my bosses happy with the lack of detail, especially since I usually gave the pessimistic estimate or something close. I hated being micro-managed when I was writing code everyday and wasn't going to follow at practice that I myself had hated. This process worked great until I worked for a PMP-driven company, where projects routinely crashed and burned. Slack by Tom DeMarco should be required reading for all PMPs and their managers.

thread

astral303Nov 2022

There’s a great book by Tom DeMarco that argues for having slack, and for that being critical for innovation: “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency”

thread

shagieNov 2022

Assuming its the same post as I found when searching, that's me... https://www.reddit.com/r/cscareerquestions/comments/9ymkmg/h... you'll also see the same date too. The order itself - https://imgur.com/TkDmLPv

I try to keep the same name/idenity-ish across systems. It was originally a collision of names (three people on the team all had the same first name). One got the short form, one the long form, and the Scoobie Do movie had just come out and for some reason, I got "Shaggy". A bit later, had a coworker who was Japanese and my first name is awkward to say to the Japanese sounds, but "shaggy" is fine - except that it was pronounced as "SHA-gie" which turned out to be much less taken as a user name than the traditional form, so I use it where I can.

That order also had Slack and Peopleware by Tom DeMarco (which I'll also recommend).

These are things that are timeless (though Peopleware is on a 3rd edition).

thread

saidajigumiNov 2022

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.

thread