Work-Life Balance Accelerates Careers

Working less each week can accelerate your career. If you're smart about it.

[A few weeks ago, Sidwyn Koh and I thought it’d be fun to pick a topic to each take one side of. We picked “work-life balance’s effect on careers,” which we expected would afford rich discussion. Here’s Sidwyn’s response to my post last week.]

Sidwyn Koh, Staff Software Engineer @ Meta, author of Path to Staff Engineer

Last week, Philip wrote about how work-life balance can slow down a career. His main point was: “If you are just as smart as everyone else, and you work just as hard as everyone else, you’re just as average.”

While there is some truth to that, I do disagree to a large extent.

A career is defined as “a field for pursuit of consecutive progressive achievement”. This definition resonates with me. To me, a great career means a mix of external recognition (level you are at) and internal growth (of your skills). While they tend to have some correlation with each other, they don’t necessarily grow at the same speed.

However, disputing the definition of the career would be a pedantic approach to this debate. I’ll focus on external recognition in this post, and leave a small point to discuss the internal growth of one's skills.

That said, I'd like to present my side of this debate: how having work-life balance can accelerate your career, especially when it comes to external recognition, aka levels.

• WLB provides you time to disconnect. I’m sure you’ve heard that complex problems can be solved by returning to them "the next day". Allowing your brain to disconnect from work helps it solve problems in unique ways. Rest has been shown in multiple ways to help improve work performance, increase alertness, and reduce fatigue. Of course, you probably already knew that, but let me explain why.

  • Many problems are solved “overnight”. Your brain makes valuable connections when you are well-rested. I’ve never found working past 50 hours to be helpful. In fact, taking more time to solve a problem correctly has always proven to be the better path, despite taking longer to resolve. This is my way, and I suspect for many of you, too.

  • A lot of problems are solved by observing the world around you. Facing a challenging architectural problem? You might read a paper on the weekend that helps you compose the exemplary architecture. Dealing with a rude teammate? You might observe the same erratic pattern with another grocery shopper on the weekend. Or you could ask your partner for tips over dinner. Can’t figure out how to write for your audience? Browsing the internet, or reading the news / your favorite Substack might inspire you to write better. This should naturally tie into your activities & hobbies outside of work, and not something that you purposefully do to tackle your work problem.

  • It’s essential to find your balance. Philip argues that 55-60 hour work weeks might be your upper limit here. This is likely true. While I agree with Philip on an upper limit, I encourage everyone to find their limit at least once, so you know when to tap out on challenging weeks at work.

• Working hard only accelerates your career from E3 (junior) to E5 (senior). Quantity matters most through these junior levels, where you go from a fresh grad to a senior level, and usually not more. I’ve seen engineers progress through these three levels as fast as 1-2 years, and then stall out entirely at the senior level for several years. Why?

  • Junior engineers are expected to code way more than senior folks. Juniors are expected to hone their coding skills by the amount they can output. Senior engineers and up, you’re supposed to be writing good code and setting direction. An increased number of hours does not lead to developing a better direction.

  • Past that senior level, making the right, impactful decisions on what to work on is much more important than the amount of code you write. Choosing the correct problems to solve is way more important than trying to solve every issue under the sun. Adding 20-30 hours a week won't help here if you need the proper judgment and headspace to make these calls. As I mentioned earlier, problems can be solved outside of work, especially when your brain is on a break.

  • During the promotion cycle, other managers will remember you for one or two impactful projects. It’s way easier to sell someone based on one or two projects than to show a smattering of work that you’ve done. Managers recognize quality over quantity at the senior levels. As you level up even further to staff, you are expected to show that you can delegate and work through others.

  • Caveat: This does not apply if you are a coding machine. At senior+ levels, there are archetypes including coding machines, where you are mostly calibrated and performance-judged based on how much code you write. This is pretty rare (I think usually 5% of senior folks), and this point can be negated entirely if you fall into this archetype.

• WLB provides you with the time to build important connections in your industry. Building connections involves investing time in attending virtual/live events, joining communities, and meeting new people, or even writing your blog. These connections open up a whole new world and expose you to future job or collaboration opportunities. Heck, even this is a great example. If I hadn't chosen to write on Substack, I don’t think Philip and I would have connected.

  • Connections open up job opportunities. This one’s pretty straightforward. If you spend time networking and connecting with folks outside of your company, you can get a referral to these companies when you need them, which I’d argue is extremely important in this economy.

  • Switching companies is one of the fastest ways to level up at the junior levels. I've done this when I was more junior, since I was able to reset expectations when I changed companies. With these connections, you can leverage them to accelerate your career.

  • As I get more senior, these connections are even more valuable. I’ve joined local hackerspaces, attended tech events, and connected with other engineering authors through my writing. These have opened so many doors to other companies. I now have connections who are VPs/directors at top-tier companies like Google, Amazon, Stripe, and Coinbase. This sets me up for the ability to shift companies if and when the time comes.

• It’s essential to recognize that career growth isn’t all about external leveling. As mentioned at the start of my article, I’ve learned that career growth is also about recognizing your own strengths and talents.

  • If you obsess over what level a company perceives you as, that’s the end of your career. It’s important to recognize your own internal growth, and I’d argue that at the senior+ levels, this becomes more important than external recognition.

  • Counterpoint: It’s important to recognize when you stagnate internally. You could also not be growing internally. It is important to reflect every month on whether the past month has helped you grow in the skills that you want to grow. I’ll write in a later post on Path to Staff on how you can define markers for internal growth.

With that said, if you’re up against engineers like Philip who put in the hours, how do you succeed? (As I was writing this, I stumbled upon this struggling with ”rockstar” engineers, a Reddit post.)

• Find a team where your strengths shine. You don’t want to compete head-to-head with them based on the # of hours. For me, I know collaboration and communication are my strengths, and I want to find teams where engineers traditionally suck at this. If you’re strong architecturally, find a team that struggles with building good architecture.

• Say “No” often. Once you’re on a team that values your skills, figure out a prioritization framework that works for you. This came up as a question on Philip’s post, and I plan to write a piece on how I tackle this.

• Plan ahead. Think ten steps ahead and figure out what your team/org/company needs before you get approached to solve it.

I hope this article provides a good counterpoint to the WLB debate. Most importantly, what do you think? Which side resonated with you more?

If you enjoyed this, you'll probably like my other pieces too. Follow me at Path to Staff!

= = = = =

I’d like to thank Sidwyn Koh for sharing these well-argued and quite convincing insights. He has many useful software engineering career posts at Path to Staff, so give it a spin!