I’ve been working really hard over the past few months on a project and yet I feel I’m further away from burning out than I was most of this past year. This feels counterintuitive, so I decided to write down some thoughts on the topic in the hopes that I will become more self-aware of patterns that might lead to burnout.
I’m convinced that burning out is not directly related to the amount of work being done, it’s totally possible to achieve work-life balance and still burn out. Of course working for really long hours and neglecting your personal life will increase your chances of burning out, so that’s not what we are talking about here.
With that in mind, I tried to pinpoint what were the characteristics of my work over the past few years that has led to my burnout symptoms. Nothing here is groundbreaking, but I hope it will be helpful to at least one more person besides myself.
Autonomy
Feeling a lack of autonomy is a big red flag for me. It’s not necessarily related to the autonomy of deciding what to work on, but rather the autonomy of deciding how to work on it. As long as everyone is aligned, having the flexibility to decide how to work on a problem is a big motivator for me. This is not always possible, but it’s something I will try to optimize for moving forward.
I’ve observed that communicating effectively increases my chances of being granted this autonomy, so it’s something to strive for. What I mean by that is framing my communication style to match what leadership expects. Some useful questions to keep in mind when communicating are:
- What will be different when this effort is done?
- How will this effort impact the business?
- Are there any clear metrics (financial, efficiency, efficacy, or otherwise) that can be framed up to help show the current state versus the desired state?
- How can you scope this work to help clarify the breadth of impact?
This is what leadership is thinking about, so framing your communication in this way will help you reach alignment and get buy-in. Talk to your manager or other senior engineers if you need help framing your proposal.
Context Switching
Being trusted is not enough when you don’t have control over your own time. Being unable to focus on a particular problem due to frequent context switching is a big source of personal stress. Something that helped me in this regard and that I will keep improving on is to strategically arrange my calendar to have blocks of dedicated time to focus on a problem. I’ve achieved some success by blocking my calendar for a few hours every day and clustering meetings in the morning or afternoon.
You can also reduce the amount of context switching by making sure your work is visible. This can be done by talking directly to your manager and explaining all the things that are stealing your focus, your manager can help you by delegating work to others or prioritizing efforts. It’s also worthwhile to do your work in public. Avoid handling work on private messages, instead move the discussion to public channels and involve other teammates when possible.
Momentum
I find this is a topic that is not discussed enough in the context of burnout. The feeling of making constant progress really motivates me and I get a lot of energy from it. This is also the time where I have the most context about a particular domain, so it’s the time where I can collaborate with others more effectively. Finding ways to protect this momentum is something that I’m still working on.
Striving to have good documentation and clear next steps for myself and others is a big part of this. Having good documentation for my projects not only increases the chances of having more people that can contribute to it, but it also helps me to get back on track after a break. Both of these things are really important to keep momentum going.
Pair programming with peers that are as motivated as me to work on a project tends to increase my momentum. We tend to feed off each other’s energy and bounce ideas really quickly with the added benefit of a quick code review cycle.
Something else that I’ve learned the hard way is that just because a project is a priority for you or your team, it doesn’t mean it’s a priority for other teams around you. My general rule of thumb at this point is to always make sure that teams that my project depends on are treating my project with a similar level of priority. If that’s not the case, I will likely lose momentum waiting for code reviews, feedback or features.
Last but not least, managing my time effectively is also a big part of this, so the same tips from the previous section apply here.
Recognition
Working on something that is not recognized by your peers or leadership is really demotivating. The lesson I’ve learned here is that I should make my own work visible to my manager and leadership and make sure that they are aligned with it. Working asynchronously makes this even more important, it’s really easy to spend hours per week helping others in obscure Slack channels and direct messages and not having anything to show for it. These days I simply share a weekly update with my manager summarizing these interactions and the impact they had on my work. It also helps my manager to identify silos and bottlenecks in the team.
Changes in management or leadership are special cases where I tend to be extra verbose about my work. The earlier I communicate, the sooner I can get feedback and adjust my work accordingly, or make my case for why I’m working on something and it should be a priority.
Recognizing your peers is also important and an area that I’m still working on.
Values
Over time I’ve noticed that it’s common for companies (orgs, teams) to shift their values depending on the stage they are in. This is not necessarily a bad thing, but it’s something I’ve learned to be aware of. Is the work I’m asked to do aligned with my values? Are the people around me open for change and feedback? Am I willing to change my values to align with theirs? If not, it might be time to move teams or companies.
This might be understood as an “us versus them” mentality and that is absolutely not what I want to convey here. You are part of a team and should have explicit conversations about culture and values with your teammates. You are not subject to circumstances, you can help shape outcomes even when faced with challenging situations.
Community
I’ve noticed that I’m much more likely to lose energy if I don’t have people around me to collaborate and interact with. Helping and being helped by others is a big source of motivation for me and I cannot remember a time where I had momentum and did not have others to collaborate with.
Pair programming, good documentation and selling your project to others are tools I’ve used to increase my chances of having others to collaborate with. I’ve learned to be more deliberate about making sure I’m not working in a silo and that it’s fine to ask for help from your peers or managers. People are generally happy to help if they can.
Doing things that energize you
Preserving time for things that fuel me is one of the most important aspects to avoid burnout. This can be partially done at work, but it’s usually related to hobbies that happen outside of work. For me that would involve activities like climbing, hiking or playing games with friends. If I don’t take time to actively do those things because I’m tired or stressed, things snowball fast. Make sure to do the things you love, even if you don’t feel motivated to do them. For example, sometimes I go climbing even when I feel like doing nothing and once I’m at the climbing gym I end up having a great time and feeling much better.
Conclusion
You might have noticed that I’ve not listed things like “poor management”, “poor leadership” or “lack of rewards”. These are not things that I can control, so I’ve tried to focus on things that I can control or influence and that have helped me in the past. I’m also sure there are other patterns and nuances that I’m failing to capture here, so please reach out if you have any feedback or suggestions, I would love to hear from you. See you next time!