How to burnout a software engineer, in 3 easy steps

The Burnout Playbook for software engineers

Engineer’s Codex is a newsletter about lessons from real-world engineering.

---

If you’re a manager who wants to burnout your best engineers and destroy their faith in your leadership skills, I can help you.

I’ve watched as smart engineers around me have burnt out before in both Big Tech and at a small startup. These teams follow the same “burnout playbook,” step-by-step.

Step 1: Don’t trust your engineers

The first step is to micromanage your engineers. Sure, they’re smart, but do they truly understand what you want the product to look like? Probably not.

When I was leading engineering at the startup, I worked alongside the CEO. He would call me daily, for hours, nitpicking at little implementation details that had no effect on the actual user experience. Are you sure we should use DynamoDB? Why does this Lambda function use Python instead of Node? 

It was exhausting to get pinged so much.

At my team in Big Tech, I also was given a limited amount of autonomy. Not necessarily because of my manager, but because of the system.

I remember working on a design for a system I was building.

I was subtly told: “We need to implement this project in this way. I know it will take a month longer, but I need it in this way [so that it looks better on my promo packet].

Marc Randolph co-founded Netflix.

Step 2: Introduce unnecessary, time-wasting processes.

When I worked at the startup, I was suddenly forced one day to start writing out huge design docs before I ever implemented anything. Every single little API endpoint created had to be discussed extensively beforehand. Suddenly, shipping a feature went from a few days to a few weeks. It was frustrating.

The worst part? We hadn’t even shipped our product yet! There was no point of all these processes before we even had an inkling of revenue.

Look, Google has a culture of many, many design docs and one-pagers. But, at a startup, you are not Google. Google needs a writing culture because they are massive and people are joining and leaving all the time. 

This can go overboard. At a certain team in Big Tech, the amount of processes often took too long. To access certain types of data, I had to file a request that was manually approved by another team, leaving me blocked for days. To launch my feature, I had to get approval from security, product, engineering, legal, compliance, and the CEO’s dog.

Some days, all I would do is edit documents, send email, read documentation, and reply to people. I did things that had 0 impact, and that’s not because I wanted to.

Emmett Shear co-founded Twitch.

Of course, these processes are needed… but there needs to be a balance. Not every project an engineer works on has to go through these processes, and they shouldn’t. Luckily, not every team at Big Tech is like this. In fact, most aren’t.

Step 3: Don’t ship code to customers.

There’s nothing worse than working on something for 8 months that nobody will ever see. Especially if those 8 months were full of long hours.

Even worse: those 8 months gets pushed to 12, 16, 20. And then, the product gets cut and what you worked on is never shipped to anybody to use.

Working on projects that never ship is, anecdotally, one of the largest causes of burnout.

Shipping is your company’s heartbeat (2013)

At the startup I worked at, we toiled away at the product for over a year without ever shipping to a customer once. Each time we would think the product was ready to ship, our CEO would ask for “just a few more features.” After a while, the team lost faith in the CEO’s ability to execute. It was hard to care deeply about something where the only feedback we got was from our CEO’s ideas and not actual users.

Products should be bug-free and have a nice user experience when they ship. But they don’t have to be perfect. If he kept inching towards perfection, then we were in for a very bad time. Especially since we hadn’t reached product-market fit yet.

Perfectionism is often an excuse for procrastination.

Looking back, I think our CEO was just procrastinating actually selling the product and receiving critical feedback.

At the Big Tech team I was in, we had constant re-orgs as Directors and VPs came and went. Each re-org came with a new executive, who had a new vision for the organization. This meant requirements changed constantly, many projects we worked on for months or years were scrapped, and we never got to see the real-world impact of our projects.

Not shipping to customers happens because of a lack of focus. When there’s no strong vision leading a product, that product is doomed to fail.

Source

Bonus step: Overpromise and underdeliver

This step is a culmination of all the above ones. The nail in the coffin, if you will.

Most engineers on these teams were over-promised benefits that never came.

At my startup, during the year of working on a product that never shipped, the CEO spent time fundraising. While I initially had a significant equity stake in the company, fundraising before product-market fit meant my stake was getting diluted. A lot. Suddenly, the financial incentive of the startup disappeared for me - I would make just as much working at Big Tech over the span of a decade even if the startup exited for $1B. Except Big Tech compensation was fully liquid and guaranteed, and a $1B exit is increasingly rare in this environment.

At Big Tech, every engineer that left had joined because of the following reasons:

• Product vision: they were passionate about the product and the problems it solved

• Scope/visibility: they felt like they would have opportunities for more scope, and therefore, more growth

• Better promotion chances: more scope and visibility → promotion

Unfortunately, every year, each engineer lost a little bit more hope in their goals being achieved.

Hopelessness accelerates burnout.

The reason they had joined simply wasn’t happening. When their hope dipped below a certain threshold, they left.

And eventually, burnout caught up to me too. So I left.

Key Lessons on Burnout

Burnout doesn’t necessarily come from hours worked.

Today, I work more than I did on the teams where I burnt out. Yet, I feel amazing. I’m having fun, growing, and I visibly see the impact my work is having on users.

I want to note that burnout CAN come from working too much. Remote work has enabled more opportunities for burnout due to the reduced separation of work and life.

It’s easy to feel as if you’re on “permanent on-call.”

Burnout happens when my work doesn’t matter.

If I’m putting all this time and effort into something, I want some sort of outcome from it. 

There is a sense of accomplishment in being given autonomy over a project and shipping it.

I’d rather have my project fail and be a bust over not shipping at all!

I need to be attached to the mission. 

These experiences made me realize that I need to be attached to the mission of the team. If I don’t care about the product area or what the team can teach me, then that’s a recipe for burnout.

This is different for everyone. While my satisfaction comes from the mission of my work, for others, it may come from working with other people, getting a paycheck that supports their family, or growing their skills.

Burnout is more common than I thought.

Source: McKinsey

I’ve read some other great articles about burnout.

My friend

Irina Stanescu

wrote some fantastic articles about burnout that are worth reading.

10 Anti-burnout strategies for success in an early-stage startup

Burnout in Tech - Part 1: Declaring War

Plus a nice little comic I found:

Source