Work-Life Balance for the Software Engineering Manager

Today’s post marks the start of a new series on work-life balance and on the healthiness of work in general. I’ll be coming at this from a somewhat different angle than most sources on the topic.

Searching for a Balance

I have a confession to make. I am old enough to remember when Amazon.com was basically a bookstore.

Today, if you hit up the Amazon search bar looking for books about work-life balance, you’ll get a LOT of results: mostly generalized, mostly oriented toward business work-life balance. These are the kinds of books that a startup founder might find helpful, and there are a lot of them.

If you refine the search a bit, you can find some books tailored to specific jobs, such as software developers, or toward managers in the technology space in general. Comparatively speaking, there aren’t many, but they exist.

I want to contribute to that discussion, and I want to go a step further by providing something even more specific: a guide to work-life balance for the software engineering manager.

My Perspective

I’ve been a developer for 17 years. I helped found two different companies and had my share of 60-hour work weeks to get those companies off the ground. I learned a lot about myself, about the nature of work, and about how to make development a healthy lifestyle.

There is not much content out there, at least as of this writing, that specifically tries to account for the challenges faced by software engineering managers. There also isn’t nearly enough for software engineers as a category. Most content is far more general.

My experience as a software developer has taught me that there is power in giving a project the right scope. When you know what your focus is ahead of time, you don’t have to try to fill out possibilities in all directions. You pick a direction, map out the specifics, and go. That’s exactly how I hope to approach the issues in this series. I have chosen the direction and scope of the software engineering manager.

With that said, some work-life balance difficulties are universal. Issues like burnout, overwork, boundary violations between work and home life... these are risks that come with every job, because that’s the nature of work. As such, I won’t shy away from covering these more “general” issues. However, I will be covering them through the lens of someone who is in this field, rather than trying to speak to white-collar business at large, or to the entrepreneurial side of things.

Who This Series is For

If you manage a team that engineers software, you are the primary target audience for this set of posts. Every entry should have something of relevance for you to consider.

If you are an engineer on such a team, you may also get a lot out of this series, especially the parts that cover burnout reduction and mindset pivoting. If your manager is open-minded to suggestions, you might also find the other posts to be of interest as conversation starters.

If you are an engineer who is considering seeking a management role for your next job, I hope you will find interesting food for thought here. Management requires a different mindset, but your experiences as an engineer can become valuable as sources of empathy and insight in a managing role. As you read, I would encourage you to think about how management-to-engineer dynamics have affected you in the past, so that you can better remember how it felt once you’re sitting in a management seat.

This series is not particularly written with a startup founder in mind (unless that startup founder also happens to be managing a team of software engineers), but founders might still glean some wisdom from reading. As noted, some of these issues have universal reach. You might also find the discussions of evolving the work week to be worth considering for your own business.

What This Series Covers

I’ll be covering the following topics in a sequence of short, digestible articles, many of which are available for you to click and read right now:

• Managing efficiently. How to use your position as manager to give your engineers a smoother work experience.
• Avoiding burnout, taking breaks. How to sustain yourself and your team through the workday.
• An Engineering Manager's Guide to Pivoting Out of Work Mode for Real. How to stop working when it isn’t work time anymore.
• (Releasing October 2, 2023) Setting boundaries and avoiding “job creep.” How to ensure that the previous item happens, despite living in a world of instant communication and ever-present worries.
• (Releasing October 16, 2023) Advocating for a better work week. How to reach out to fellow managers and higher-ups about improving the structure of work.
• (Releasing October 30, 2023 🎃) Implementing a better work week. How to take advantage of a streamlined, shorter work week.

The first four deal with matters directly related to the day-to-day process of managing a software engineering team. I start with broad but relevant management principles in the first, then zoom in to the micro level to look at the anatomy of problems like burnout, getting stuck in the work headspace, and preventing one’s job from encroaching on the rest of one’s life. These are issues which are as pertinent to managers as they are to the engineers, but managers have the privilege and responsibility of making those issues easier for their teammates to navigate.

The final two articles deal with meta-work issues (“working about working”), which I felt important to include in this series precisely because my target audience is managers. I know from experience that a software engineer without management responsibilities is seldom positioned to change how the team’s work week is structured. Managers need to explore the options for that and advocate for their teams. I think managers are uniquely well-positioned to do this, since we are close enough to the frontlines of projects to see how the structure of the work week affects the engineer, while at the same time having better social channels available to lobby for change.

With all of that in mind, I invite you to join me on this foray into software engineering management, and how we might do it better.