The tech industry can be a hard taskmaster - an unending whirlwind of fundraising rounds, deadlines, and product launches. Burnout is a real issue, and one that you can't afford your team to succumb to. Here's how to avoid it.
Software engineering is full of rules. We have processes for pretty much everything. The rules are there to stop things going wrong - to ensure that the code we write isn’t broken before we ship it out. It’s a way of regulating our work, a way of guaranteeing that quality is never compromised.
One Friday evening, a couple of months ago, I broke a whole load of those rules. I bypassed our established processes and shipped some code before I had tested it. I knew it wasn’t the right thing to do, but I felt I had to. I was suffering from serious burnout – I was overstressed, overworked and overwhelmed, and reaching my breaking point.
As soon as I pressed the button, our entire site went down.
So software engineering needs rules. When the pressure is on, those processes hold you to the straight and narrow. Most tech companies understand this.
But what they often don’t understand is that the processes around your people are even more important.
Looking back, I know that I learnt a lot from that experience, and Charlie also learnt a lot as a company. Later in this post, I’m going to set those lessons out, so you can learn directly from our mistakes. But first I’m going to walk you through how we got here in the first place.
The new feature
In mid-2018, Charlie began work on a new feature called Reviews. It was a huge project - something that our customers had been crying out for ever since we’d launched.
Like many tech companies, we work in a pattern of sprints and cycles. At Charlie, a cycle usually means 10 weeks, which is further broken down into five, 2-week Sprints. Our team knew at the beginning that this piece of work was too big to fit into a single cycle - so we were effectively committing to work on something that wasn’t going to produce any value within the deadline. And this was okay at that point - so we proceeded.
After spending about a month on the project, the initial timetable that we laid out slowly became diluted. People across the company started to have very different ideas about when the feature would be ready - that it would be built and deployed within the deadline after all.
I can’t point to one reason why this happened - it was a perfect storm of many things. First of all, I know that I didn’t communicate strongly enough with the rest of the company. Meanwhile, I think there’s always a tempting instinct to fit every project into a single cycle so that it doesn’t spill over into the next. All of this is underpinned by the excitement of the new cycle when it’s very easy to get swept along in the heat of the moment.
As the cycle progressed, Tim (another Charlie engineer) and I started to stay at the office later and later. We were putting in more and more hours every day to try and keep the project on track for the new deadline. I can’t even count the days Tim and I were in the office well into the night.
I know myself to be quite an obsessive character. Outside of work, I am a competitive rock climber, and it’s something I train for really seriously. Many years of tough, focussed training blocks mean that I’m used to operating at my maximum capacity for long periods of time and my threshold for sustained effort is quite high. That trait is a big strength of mine, but if you push a strength too far it’ll eventually become a weakness. It is great that I can push things to the limit but I am not self-aware enough to know when to stop.
Over time, the pressure I put myself under continued to build, and something had to give. Eventually, I hit my breaking point and shipped that broken code.
If you work at a tech company, then it’s very likely that your team is working hard - probably too hard. Tech is a highly competitive industry - a whirlwind of deadlines, product releases, and looming fundraising rounds. All that coalesces into a culture of ingrained pressure and burnout.
There’s nothing wrong with pressure - but if it’s not handled in the right way then that stress can quickly lead to burnout. Here’s how you can tackle it.
1. Listen to your engineering team
To any founders and product managers, I’d say this: listen to your engineering team. They know best how long a piece of work will take, and what it’ll take to get there.
2. Push your team - but be aware of the context
At Charlie, we have an ingrained culture of high performance, and I’m really proud to work within an environment that pushes me to do my best work. But every company needs to be aware that there are plenty of people out there who aren’t great at communicating their emotional state with others, for whatever reason.
So by all means, push your team to excel - but make sure you understand the best moments to apply that pressure. You may be pushing someone without knowing that they’re already having a rough time.
3. Make communication a central part of your culture
Software engineers can be pretty bad at communication. I think that’s often because of the nature of engineering work - it is ‘deep work’, and they need to go into their own zone. They focus on the task at hand in a pretty intense way, and that sometimes means they aren’t perfectly attuned to wider conversations happening around them.
If you’re working with any kind of ‘maker’ - team members whose main job is to produce something, such as code - then it’s a good idea to make two-way communication an integral part of your day-to-to-day. Set aside some time that is specifically for communication between teams.
4. Make time for individuals
One thing I learnt from this experience was how important it is to be aware of my individual state of mind. I’ve started doing self-check-ins when I get to the office in the morning and when I leave at the end of the day, rating my stress levels on a scale of 0-10.
There’s no right or wrong level of stress - it’s very individual - but in my case, I know I like to operate at around a seven or an eight.
The key is knowing how much stress is manageable and sustainable. Ask yourself, “can I continue working at this level of stress for the duration of the project?”. If the answer is no, you have to either lower the pace or book in some space to take a break.
Over the last few years, companies have got better and better at talking about stress and burnout. It’s gone from something of a side issue to one of the biggest focus points in HR. Traditionally, we’re pretty good at this at Charlie - but this experience was a reminder that we can always get better, and it’s something we have learnt a lot from as a company.
