I’ve been officially a manager for just over two years now, and I think I am ready to start rambling about some of the things I’ve learned along the way. First up, setting a good work/life balance with your team.

A lot of organizations preach all about healthy work/life balance, but they don’t really practice it. For teams of developers/engineers or other knowledge workers, there is absolutely no excuse for it — especially with remote workers.

It doesn’t have to be like this. And the cool part: as a manager, you are the one who can help. Here are a few rules for you:

  • Your reports work 40 hours a week. Period. They might need to help with an issue and work 10 hours on Monday. It is on you to encourage them to work a shorter day that week to make up the time.
  • Approve all reasonable PTO requests by default (if the person has the hours available). NEVER refuse PTO because of being short staffed. That is your problem, not theirs.
  • Encourage people to work early or late to make up for doctors appointments instead of wasting PTO on routine things.
  • Encourage a total disconnect from work on PTO — no Slack, email, etc. This can be difficult in remote places, with developers and engineers. A lot of us are friends with our coworkers and like to chat. Devs and engineers usually enjoy their work, and might use their PTO to work on a pet project. Don’t be a jerk, but discourage this. It is important that people can fully disconnect from work; they should know it is important to you.
  • Accept the fact your reports might need to duck out for a few minutes to deal with family, perhaps even daily. If this amounts to ~30 minutes, don’t be a jerk and ask them to make up the time. Smokers don’t usually stay late to cover for their breaks, do they?
  • Seriously, stop fucking Slacking/texting/emailing your people after hours. Unless they are oncall, there is no reason for you to bug people off the clock.
  • Encourage your reports to keep Slack and work email off of their phones. Your projects will go on without them for a week or two.
  • If someone is on PTO, the only reason you should bug them is it is an emergency. An emergency worth bugging someone on PTO is one where your team/company will suffer irreparable harm if that person isn’t brought in. A lack of preparation on your part is not an emergency on theirs.
  • Encourage your reports to find replacements for their oncall rotations that fall during their PTO. They shouldn’t be on the pager on vacation. They can be trusted to find coverage themselves.
  • Avoid doing too much after hours yourself. If you are constantly sending emails at 2am, messaging people at all hours, and generally never disconnecting from work, your reports are going to think you expect the same thing from them.
  • Lunchtime is not for working. It is for food and unplugging for a bit. Stop scheduling meetings during lunch. Stop letting people eat at their desks while working.
  • If they wake up early, you do too. Our work is always going to require coordinating big upgrades and feature rollouts. It often makes sense to do these earlier in the day. But, if you need to annoy them by making them work off hours, it is only fair that you do it, too.
  • Set clear expectations around when and how you want people to call out for the day or to submit PTO. It might surprise you, in spite of everything I wrote above, that it really grinds me gears when people miss our daily standup. But, I let my team know that I need to hear about absences by that meeting, and they do it. It probably helps that I am pretty laid back about PTO otherwise.

This is the one hill I will die on when it comes to remote developer/engineering work. Do your part, fellow manager.