For those that are new to the world of development as a career, there is something you should be aware of. Burnout.

Molly shared with us all last week her story of burnout and her story is not unique. Many developers run into burnout in their careers, myself included.

For me, it snuck up on me very quick.

My story of burnout

Before my burnout, I was thriving in my career. Learning every possible thing, contributing anywhere I could, and filling in any gaps where necessary. It was a startup, you plug the gaps where you can. That's what I had been doing for the better part of five years at this company.

This was the first company I ever worked at as a Software Engineer. Because of this I viewed its success as my own success. I felt the responsibility to help the company be successful by any means necessary.

When I wasn't at work coding solutions to the problems we faced, I was at home coding solutions to my own projects to extend my knowledge base further. This was beneficial as a developer and entrepreneur. It also benefitted the company as well because I could apply the things I learned to the problems I faced in my work.

It was a lot of work, but it was also a lot of fun

My burnout didn't start until I got promoted into management. Weird right? There is a general impression that management means you pivot your focus to people instead of code. But that's not what happened for me. In hindsight, it's not weird at all that my story of burnout began the day I became a manager.

Making the transition from an individual technical contributor to a manager is not a small leap. It's a massive change, and I underestimated the distance I was jumping.

When I moved into a management role I still tried to do all the things I was doing before managing a team of eight people. I tried to do everything I was doing before but add managing a team and product backlog to my list.

I felt burned out after six months.

It was too much on my mind and body. I couldn't manage a team of that size with a product that complex and still contribute at a technical level. The context switching alone was enough to make my head spin.

It reached a point where I no longer viewed work with the enthusiasm and passion that I once did. Furthermore, I felt an intense amount of anxiety around the fact that I was falling behind the technology curve. I couldn't stay on top of all the technical aspects, people aspects, and product aspects at the same time.

So I did the only thing I could think of doing, I asked for help.

It became clear that managing the technical vision and contributing to the code base was not going to be possible. As much as I enjoyed those things I knew I had to delegate them. I knew that I needed to spend my time focusing on the team and the product, not every technical decision. So I gave those responsibilities to developers on the team and let them lead those charges.

This freed me to focus on the team and delivering the product on a regular cadence. I could have conversations with members of the team and support their careers. I could focus on what the business needed from the product and help fit that into what we were doing. Once I delegated things started to hum on all those fronts.

Problem solved right?

But, it wasn't solved, the damage was already done.

Delegating technical aspects took things off my plate, but it was already too late. The burnout had already set in and after a while, I started to long for the technical aspects.

Management is very different than being an individual contributor. You can do both if you have the right culture in your team. But for my situation, technical and management tasks were very different, so I couldn't do both.

I was in a role that I didn't hate, but it was missing all the things I enjoyed doing. I couldn't contribute to the things that were valuable to me. Mentoring others, coding, designing architectures, and debugging were things I enjoyed doing, but I stepped out of that side of things.

This is OK in the short term, but in the long term, it will cause you to burn out. Because burn out isn't just caused by trying to do everything. Although that is a large percentage, there is another factor to consider. It's the factor of not doing what you want to be doing at a given moment that is the extra burden to consider.

Trying to do everything for your team is exhausting. Trying to do everything for your team and not getting the satisfaction from your role is grating.

This is what led to my own burnout. I enjoyed working at that company and I learned a truckload of things while I was there. But, I ended up in a role that I didn't enjoy. All the things I once loved I didn't get to do because I couldn't do those and my new responsibilities. So everything suffered.

Pulling yourself out of burnout

Step one for me was asking for help.

I asked members of the team to take over the technical vision so that I could focus on the team and what they needed from me. This feels like the right thing to do when you are in a management role. You have to choose what you are going to focus on. So there is likely going to be things you have to delegate.

That prevented the burn out by trying to do everything under the sun. But, it didn't prevent the eventual burnout that would happen because there was a conflict between what I was doing and what I wanted to be doing.

So how did I pull myself out of that? Long story short, I left the company.

I needed some time to focus on the things that interested me. So I took a few months off. In those months I worked on a bunch of different things. I wrote blog posts about all the things I was learning. I launched parler.io, added more content to my Learn AWS By Using It course, and traveled to France 🇫🇷.

Not everyone is lucky enough to be able to do that for 2-3 months. I was fortunate in that I could focus on my own projects/ideas for a few months while on vacation. This allowed me to recharge my batteries and work on the things I enjoyed.

It also allowed me to sit down and think about what are the things that are not negotiable when it comes to my next position. I knew that I didn't want to work on my own ideas full-time, at least not yet. So I sat down and made a list of things I wanted from my next position.

1. My work should be impactful. This was the missing link that my extended break helped me reveal. My friction from earlier was because I wasn't feeling like my work was having an impact. So, my next position must have an impact on the business and ideally on the world.
2. Compensation that I don't have to worry about now or in the future. It's no small feat to negotiate your compensation when joining a new company. But, it's 100% necessary, so if you are feeling fearful about it, ask for help!
3. Ultimate flexibility. I love to travel, work from coffee shops, finish my work and go snowboarding. Remote work was a must have for me.

Those three things are short, concise, and to the point. But they took quite a bit of time for me to generate. I thought about what was missing from my past positions and how I got burned out at those companies.

By taking a break to breathe, focus, reflect, and work on things that interested me I was able to define what I needed from a company. Once I had that list ready, I started applying to companies that I thought had a high likelihood of fitting into these criteria.

Conclusion

Working in software development is a lucrative opportunity, but it's also a lot more taxing than most people expect. We are constantly working on new things, learning new technologies, and improving our code bases. Don't get me wrong, it's a ton of fun and I wouldn't change a thing.

But it's important to keep in mind the toll this work can take on your mind and body. We need to take breaks and recharge our batteries. That bit of downtime can allow us to reevaluate what we want from our career because that is guaranteed to change over time.

So, take it from me, burnout is a real thing that can happen. Know that you aren't alone it, many have been through it or are going through it right now. Ask for help, take a break, and recharge.

Are you hungry to learn even more about Amazon Web Services?

If you are looking to begin your AWS journey but feel lost on where to start, consider checking out my course. We focus on hosting, securing, and deploying static websites on AWS. Allowing us to learn over 6 different AWS services as we are using them. After you have mastered the basics there we can then dive into two bonus chapters to cover more advanced topics like Infrastructure as Code and Continuous Deployment.