Overwork is Destructive

I’ve long been a fan of the eight hour burn. Here’s what I wrote about it in March:

Thinking about Developers, we tend to work very long hours, even though it empirically hurts us and the company. Extreme Programming tried (and failed, sadly) to introduce the notion of the Eight-Hour burn; a reasonable spin on what programming should be. But with distractions aplenty, it’s hard to justify an eight-hour burn.

The eight hour burn is meant to combat those behaviors that seem helpful to the company, but are ultimately destructive to the individual and the company. This centers around programming beyond 40 hours for any reason, especially:

• launching the inaugural product
• feeling passionate about the product/project/mission
• to catch up with the promises Sales made
• to beat a competitor to market
• moving fast and breaking things
• to show the company you’re a “team player”
• because you have x months of runway left
• because you are in over your head and don’t want others to realize it

The trouble with each of these reasons is that they’re easy to rationalize. “Oh, I’m only working 60 hours a week until the product is launched, and then I’ll take a vacation.” or “Oh, if only I put in a few more hours each day, I’ll learn this faster.” And not all rationalizations come from developers; some come from the powers that be: “We need this feature so we can sell to Enterprise companies; and since we promised we had it, I need you to deliver it before they finish implementing our software. You have four weeks.”

Some rationalizations are even so basic that they’re sacrosanct: “We move fast and break things.” “We work hard and play hard.” “We need to beat our competitor to market or we’ll lose.” “We need all hands on deck to ship this product before Q2 ends.”

At some point, these rationalizations for over-working will cause you to burnout. You’ll start to slow down, spend less time on work, and ultimately either be put in a performance improvement plan, reset and get out of the burnout, or find another job.

Besides the extreme examples of what happens when you overwork (burnout), there are other side effects. Fixing bugs created during the course of a 60+ hour week. Designs produced during late nights are found to be logically flawed the next week. Frustration, fatigue, and arguments that shouldn’t break out (but would seem to be that much closer to the surface).

In my case, it wasn’t a push from above or a shortened timeline that caused this. Our CEO makes sure to tell us to take time to recharge, that this is a marathon and not a sprint. She wants us to stay healthy and not burn out, but even with her total support, I found myself working 50–65 hours a week, working through vacation, and even working in my sleep. I believed in the eight hour burn, but I had the hubris to believe that the destructive effects of overworking “wouldn’t happen to me”.

We have met the enemy and he is us.

So what can we do? How do we turn this into a happy ending?

For leaders, this means paying close attention to your subordinates.

• If you notice commit messages spanning lots of hours, or late night emails after having seen them working all day, ask about it. “You seem to be putting a lot of hours in; how are you feeling?”
• If they say they’re taking vacation, make them take vacation. Make sure they know they should be unplugged.
• Don’t encourage a culture where late night emails garner responses. If you send an email late at night (perhaps you shouldn’t?) then explicitly state that you don’t want action on that email until a reasonable time.
• If you have DBAs or Ops, make sure they’re cycled through production support or system administration rotations frequently. Treat those operations like hazardous duty: They should be well compensated and not spend an inordinate amount of time in that rotation. I’ve done both production support and system administration work, and it begins to wear on you after a few months of late nights and weekend work.
• Encourage subordinates to keep a reasonable work pace. This doesn’t mean ‘go slow’; it means “Don’t break your neck when there’s no reason to.” There will always be fires; but the person you’re sending to fight the fire should be more valuable to you than the fire itself. If that’s not the case, your priorities are askew.

For us as professionals, this means:

• Setting our own boundaries. Passionate should never mean “going to burn out in 6 months.” We’re good enough, even if we’re imposters. Work is work, but you should have something outside of work that keeps work from overtaking your psyche and your life’s energy.
• Learning to say ‘no’. This one is really difficult for me. I want to say ‘yes’, I want to be valuable; and saying “no” doesn’t seem like it makes me valuable, right? Not so fast. Being able to say ‘no’ when the situation warrants it means your leaders don’t have to weigh opportunity costs; you’ve already done it for them. It means they don’t have to worry whether you’re taking on too much — you’re telling them when that’s the case. It means they never have to worry if you’re going to “over promise and under deliver” because you don’t.
• Work an eight hour burn. It’s easy not to do this; because our default state isn’t action, but with some changes on our side, we can. I’ve started to use stayfocusd to ensure I’m not spending random time on twitter. That article is full of great suggestions, and I’m incorporating them into my life.
• Live a complete life. There’s an old saying, no one on their death bed wishes they spent more time working. You spend (maybe) a third of your life at work; should it account for all of your energy?

What are your tips for combatting burnout?

This post has been adapted for Medium and originally appeared on my blog.