Builds on concepts from:

Summary: If you're trying to preserve your sanity (or your employees') by scaling back on the number of things you're trying to do... make sure not to accidentally scale back on things that were important-but-harder-to-see, in favor of things that aren't as important but more easily evaluated.

Epistemic Effort: Had a conversation, had some immediate instinctive reactions to it, did not especially reflect on it. Hope to flesh out how to manage these tradeoffs in the comments.

Zvi introduced the term "Slack" to the rationaljargonsphere a few months ago, and I think it's the most clearly useful new piece of jargon we've seen in a while.

Normally, when someone coins a new term, I immediately find people shoehorning it into conversations and concepts where it doesn't quite fit. (I do this myself an embarrassing amount, and the underlying motivation is clearly "I want to sound smart" which bodes ill).

By contrast, I experienced an explosion of people jargon-dropping Slack into their conversations and every single instance was valid. Lack-of-slack was a problem loads of people had been dealing with, and having a handle for it was a perfect instance of a new name enabling higher level discussion.

This hints at something that should be alarming: "slack" is a useful term because nobody has enough of it.

In particular, it looks like many organizations I'm familiar with run at something like -10% slack, instead of the 40% slack that apparently is optimal across many domains.

Gworley noted in the comments of Zvi's post:

If you work with distributed systems, by which I mean any system that must pass information between multiple, tightly integrated subsystems, there is a well understood concept of maximum sustainable load and we know that number to be roughly 60% of maximum possible load for all systems.

The probability that one subsystem will have to wait on another increases exponentially with the total load on the system and the load level that maximizes throughput (total amount of work done by the system over some period of time) comes in just above 60%. If you do less work you are wasting capacity (in terms of throughput); if you do more work you will gum up the works and waste time waiting even if all the subsystems are always busy.

We normally deal with this in engineering contexts, but as is so often the case this property will hold for basically anything that looks sufficiently like a distributed system. Thus the "operate at 60% capacity" rule of thumb will maximize throughput in lots of scenarios: assembly lines, service-oriented architecture software, coordinated work within any organization, an individual's work (since it is normally made up of many tasks that information must be passed between with the topology being spread out over time rather than space), and perhaps most surprisingly an individual's mind-body.

"Slack" is a decent way of putting this, but we can be pretty precise and say you need ~40% slack to optimize throughput: more and you tip into being "lazy", less and you become "overworked".

I've talked with a few people people about burnout, and other ways that lack-of-slack causes problems. I had come to the conclusion that people should probably drastically-cut-back on the amount of things they're trying to do, so that they can afford to do them well, for the long term.

Oliver Habryka made a surprising case for why this might be a bad idea, at least if implemented carelessly. (The rest of this post is basically a summary of a month-ago conversation in which Oliver explained some ideas/arguments to me. I'm fairly confident I remember the key points, but if I missed something, apologies)

Veneer vs Substance

Example 1: Web Developer Mockups

(This example is slightly contrived - a professional web developer probably wouldn't make this particular mistake, but hopefully illustrates the point)

Say you're a novice web-developer, and a client hires you to make a website. The client doesn't understand anything about web development, but they can easily tell if a website is ugly or pretty. They give you some requirements, including 4 menu items at the top of the page.

You have a day before the first meeting, and you want to make a good first impression. You have enough time that you could build a site with a good underlying structure, but no CSS styling. You know from experience the client will be unimpressed.

So instead you throw together a quick-and-dirty-but-stylish website that meets their requirements. The four menu items flow beautifully across the top of the page.

They see it. They're happy. They add some more requirements to add more functionality, which you're happy to comply with.

Then eventually they say "okay, now we need to add a 5th menu-item."

And... it turns out adding the 5th menu item a) totally wrecks the visual flow of the page you designed, b) you can't even do it easily because you threw together something that manually specified individual menu items and corresponding pages, instead of an easily scalable menu-item/page system.

Your site looked good, but it wasn't actually built for the most important longterm goals of your client, and neither you nor your client noticed. And now you have more work to do than you normally would have.

Example 2: Running a Conference

If you run a conference, people will notice if you screw up the logistics and people don't have food or all the volunteers are stressed out and screwing up.

They won't notice if the breaks between sessions are 10 minutes long instead of 30.

But much of the value of most conferences isn't the presentations. It's in the networking, the bouncing around of ideas. The difference between 10 minute breaks and 30 minute ones may be the difference between people actually being able to generate valuable new ideas together, and people mostly rushing from one presentation to another without time to connect.

"Well, simple", you might say. "It's not that hard to make the breaks 30 minutes long. Just do that, and then still put as much effort into logistics as you can."

But, would have you have thought to do that, if you were preoccupied with logistics?

How many other similar types of decisions are available for you to make? How many of them will you notice if you don't dedicate time to specifically thinking about how to optimize the conference for producing connections, novel insights and new projects?

Say your default plan is to spend 12 hours a day for three months working your ass off to get both the logistics done and to think creatively about what the most important goals of the conference are and how to achieve them.

(realistically, this probably isn't actually your default plan, because thinking creatively and agentily is pretty hard and people default to doing "obvious" things like getting high-profile speakers)

But, you've also read a bunch of stuff about slack and noticed yourself being stressed out a lot. You try to get help to outsource one of the tasks, but getting people you can really count on is hard.

It looks like you need to do a lot of the key tasks yourself. You're stretched thin. You've got a lot of people pinging you with questions so you're running on manager-schedule instead of setting aside time for deep work.

You've run conferences before, and you have a lot of visceral experiences of people yelling at you for not making sure there was enough food and other logistical screwups. You have a lot of current fires going on and people who are yelling about them right now.

You don't have a lot of salient examples of people yelling at you for not having long enough breaks, and nobody is yelling at you right now to allocate deep work towards creatively optimizing the conference.

So as you try to regain sanity and some sense of measured control, the things that tend to get dropped are the things least visible, without regard for whether they are the most substantive, valuable things you could have done.

So What To Do?

Now, I do have a strong impression that a lot of organizations and people I know are running at -10% slack. This is for understandable reasons: The World is On Fire, metaphorically and literally. There's a long list of Really Important Things that need doing.

Getting them set in motion soon is legitimately important.

A young organization has a lot of things they need to get going at once in order to prove themselves (both to funders, and to the people involved).

There aren't too many people who are able/willing to help. There's even fewer people who demonstratably can be counted on to tackle complex tasks in a proactive, agenty fashion. Those people end up excessively relied upon, often pressured into taking on more than they can handle (or barely exactly how much they can handle and then as soon as things go wrong, other failures start to snowball)

[note: this is not commentary on any particular organization, just a general sense I get from talking to a few people, both in the rationalsphere but also generally in most small organizations]

What do we do about this?

Answers would probably vary based on specific context. Some obvious-if-hard answers are obvious-if-hard:

Try to buy off-the-shelf solutions for things that off-the-shelf-solutions exist for. (This runs into a different problem which is that you risk overpaying for enterprise software that isn't very good, which is a whole separate blogpost)
Where possible, develop systems that dramatically simplify problems.
Where possible, get more help, while generally developing your capacity to distribute tasks effectively over larger numbers of people.
Understand that if you're pushing yourself (or your employees) for a major product release, you're not actually gaining time or energy - you're borrowing time/energy from the future. If you're spending a month in crunch time, expect to have a followup month where everyone is kinda brain dead. This may be worth it, and being able to think more explicitly about the tradeoffs being made may be helpful.

You're probably doing things like that, as best you can. My remaining thought is something like "do fewer things, but give yourself a lot more time to do them." (For example, I ran the 2012 Solstice almost entirely by myself, but I gave myself an entire year to do it, and it was my only major creative project that year)

If you're a small organization with a lot of big ideas that all feel interdependent, and if you notice that your staff are constantly overworked and burning out, it may be necessary to prune those ideas back and focus on 1-3 major projects each year that you have can afford to do well without resorting to crunch time.

Allocate time months in advance (both for thinking through the creative, deep underlying principles behind your project, as well as setting logistical systems in motion that'll make things easier).

None of this feels like a satisfying solution to me, but all feels like useful pieces of the puzzle to have in mind.