Why, how much, and when you should be taking time off as an engineer
Without feeling guilty about it
Thank you for reading High Growth Engineer. Yesterday, we surpassed 40k subscribers in just 1 year. The growth of the newsletter is far greater than I could have ever expected and I have you to thank for it 🙏
Let’s get started 🙂
You look at the calendar to request time off.
You think, “I’d like to take 5 days off, but I’d feel a bit guilty.”
Or, “I’d love to take 3 days off, but I’ll just do 2.”
So you end up taking less than you need, you get back, and what happens?
You still feel drained and wish you had more.
It’s normal to feel like this and to be making these tradeoffs as you take time off.
But it’s not necessary to feel like this.
In this article, I’ll share with you why you shouldn’t feel guilty for taking time off, and how it benefits you and your team to take what you need.
JetBrains Academy & Learning Tracks (Sponsor)
JetBrains Academy has kindly sponsored this newsletter and is offering free resources for you.
I'm a huge advocate for JetBrains and their products. I've been using their IDEs since I started programming and they've been a huge source of my productivity.
⭐️ Main takeaways
3 key reasons why taking time off helps you grow as an engineer
How much time you should take off
How and when to take time off
🌴 Why you should take off
✅ You make better decisions
It’s a common debugging strategy to “go for a walk” or “sleep on it.”
There’s scientific reasoning behind this. When you step away from a problem, your brain is still working on it and making connections subconsciously.
Similarly, when you take time off, you come back with a fresh perspective.
In the past, I’ve taken time off and come back realizing there were weeks worth of a project that we could do an easier way, or just cut out entirely because it’s not important.
You could argue that should happen on the job too. And you’d be right.
But taking time off and getting away from a fully “problem-solving” mode helps make it happen easier.
😓 You avoid burning out
As someone who is in “grind mode” most of the time, I’ve learned the hard way you need rest to avoid burning out.
Burnout is scary.
It can take you down a path of not getting enjoyment out of your day-to-day anymore.
I’ve seen people affected by burnout become a detriment to their team, and slowly get pushed out through negative performance or worse.
💡 You have the chance to learn outside your job
This is my favorite benefit.
I love learning.
I read most of the books I recommend in the Path to Senior Engineer Handbook during my time off. Plus took some of the courses on that list too.
Doing this in between work breaks allows you to make connections with what you are reading to your most recent experiences at work. It helps you realize where you could have done things better or what you did right.
For example, I read the book Crucial Conversations during my time off and it helped me in multiple ways:
I realized how I messed up on certain recent conversations and how I could have done better.
I realized why other conversations went well and what I was doing right.
I had lingering situations that reading the book allowed me to tackle once I got back from the time off.
Omar’s comment on the value of time off resonates well here:
I liked Heather’s comment as well, sharing how she’s learned even more during her sabbatical than she had in the past 6 months on the job.
When I learn technical topics, I’m able to bring those learnings back to the team after finishing the time off.
For example, when I took Josh Comeau’s CSS for JS Devs course, I was able to bring new ways of doing CSS to our team and use the mental models from the course to teach more junior devs on the team. Using those, it leveled everyone up on the team and gave me points for mentorship!
⌛️ How much time to take off
You might wonder how much time is reasonable to take off.
This gets confusing when a company offers “Unlimited PTO.”
My general recommendation is:
Try to take at least 5 days per quarter. Minimum 20 days per year.
Give 1 week of notice per number of days you want to take off.
For 1 day, give 1 week notice.
For 2 days, give 2 weeks notice.
For > 5 days, give 1 month notice.
This can change depending on your environment, the strictness of deadlines, how “normal” taking time off is, etc.
❓How and when to take off
While you take time off, work moves on “as usual.”
This can make it difficult to take time off because you feel like taking time off just shrinks the amount of time you have to complete your tasks.
Here are my tips for avoiding that:
Take time off in between projects or milestones. This makes deadlines or targets less complicated and prevents you from having lingering thoughts about the state of the project.
Tell your team about the time off and push out the deadline at the same time.
Example: “I had some time off planned in a few weeks. I think we didn’t account for this in our initial target date. Shall we push back the target date a few days to account for that?”
See if your team would be open to a “team day off.”
At Gusto, we had 2 days off scheduled for our entire team each month, so it was incorporated as a team process. This meant that work was on hold by default, no one’s time got shrunk, and it was accounted for in our deadlines.
It won’t be possible for all teams & companies, but I’d highly recommend it.
Why you should take off:
You make better decisions.
You avoid burnout.
You can learn a ton outside of your job.
How much to take off:
Take at least 5 days off per quarter.
Give ~1 week of notice per day you take off.
How and when to take off:
Take time off in between projects or milestones.
Call out the time off and push back the deadline at the same time.
See if your team would be open to a team-wide monthly day off.
Finally, I wanted to share a fantastic visual from my friendthat sums this article up nicely.
📣 Shout-outs of the week
- by - Technical article on how Uber works behind the scenes. Super interesting.
- by - Learn helpful strategies for reading books with a short amount of time from a Staff Engineer at Meta.
- by - Interview with Lenny Rachitsky & Will Larson, Author of Staff Engineer and CTO at Carta. Great lessons on systems thinking, engineering strategy, how writing helps you make hard decisions, and more.
Thank you for your continued support of the newsletter and the growth to 40k+ subscribers 🙏
P.S. If you’re interested, I’m accepting the following:
Spots for the next Mid-level to Senior Engineer cohort (by Jan 23rd)
Newsletter sponsorships: Feel free to reply to this email or check the Sponsorship packages
Did you find this issue valuable? If so, there are two ways you can help:
You can also hit the like ❤️ button at the bottom of this email to help support me or share this with a friend. It really helps!