Avoiding burn out at a tech company
Creating the space for effective work
In June 2016, my team at Dropbox were 7 months into a project that was replacing the core foundations of how sharing content works. We were about to ship this work on 5 platforms (web, Windows, macOS, iOS and Android) at once and it hadn’t quite hit me that this was a big release with some pretty hairy problems to solve and coordinate.
We were sprinting the last miles of a marathon and it felt unsustainable. I was stressed. The team was stressed. But you push through it, get that last bug fixed, and celebrate the feeling of shipping your work to millions of people. Right?
Once a project has shipped, you may find the cost of the effort hits you and you need to take a break. You’ve gone way past toughing it out and those few late nights have turned into a few-too-many. You’re tired, mentally fatigued, and the well of creativity is dry.
This is called burn out.
It’s something that happens in tech companies fairly often and maybe you’ve experienced this yourself.
So, how can we avoid it, or at least, put in some measures to reduce the likelihood of it happening? It’s worth mentioning that I’m a designer so my take on this is slanted that way but I hope it’s generic enough to be applied to other disciplines.
Design’s involvement during a project
Before digging into this, it’s important to understand what design’s involvement is in a typical project.
- At the start of the process you’re defining the problem (usually with a PM or fellow designer) and designing solutions to that problem.
- Then you have some arbitrary handoff or knowledge transfer moment when engineering starts writing code. You’re still involved here but it is in a supporting role to answer questions and provide guidance to the engineers.
- Engineers near the end of the build phase and you’re keeping a closer eye on shipping deadlines while raising bugs and making sure things are coming together.
- The QA process is in full swing in this phase and you’re actively involved in bug bash sessions, maybe pushing code changes yourself, and generally making sure the work is still solving the original problem to the highest quality.
Understanding this loose process matters for sequencing of work. Due to the high design involvement at the beginning and end of a project, you can not be finishing one big project and starting another at the same time. In a perfect world we’d be starting to think about new projects while engineering has their hands on the wheel but it doesn’t always work like that.
Too many projects
Better sequencing of work helped us a lot while shipping features to 5 platforms but it is incomplete without taking into consideration the time design needs to do the work.
If a designer is on 5 projects at the same time, they can only allocate 20% of their time to each.
To be effective, I believe designers should be spending around 50–60% of their time on a single (but big and impactful) project in order to really focus on it. With too many projects, you’ll be rushing your process, and likely making incremental progress in 50 different directions. I’d much prefer designers on my team get 2 projects to 100% vs. pushing 4 projects to 50%.
Context switching
Don’t underestimate the cost of switching context between multiple projects in different stages. I really struggle going from thinking about product strategy in one meeting to jumping into execution mode at my desk in the next hour.
The ideal design time allocation
Designers should be committed to their product area work stream which is ideally 1 project. In addition, designers should be contributing to a project that helps the greater design org. These can include:
- Contributing to pattern libraries
- Creating a playbook of design processes and techniques
- Process overhauls and refinements
- Culture improvements
- Recruiting
I’ve also included a 20% miscellaneous bucket because there is always something that pops up that you didn’t account for. It might be supporting another team temporarily, giving a talk at a conference, recruiting drives, etc.
This time should also allow for cross team pollination across the company. At Dropbox (and previously working at Atlassian) we encouraged designers to break out of their day-to-day teams to understand what other teams were doing and what other designers were thinking. As companies scale this can become really hard so make an effort to immerse yourself with the designers you don’t work with every day.
The best laid plans
The last drawing is “ideal” and definitely not always possible so be prepared to adapt and put in extra effort to help your team when plans change.
The key is to aim for a balance like this so your designers get the space they need to grow, do good work, and contribute to the wider design team. By sharing these approaches with my team at Dropbox, we’ve significantly improved how we plan the work designers need to do and how many designers we need working on a problem space.
Do you have any tips or techniques for avoiding burn out on your teams? I’ve love to hear ideas or ways you’ve been able to create effective environments for designers on product teams.
