In the software industry it seems very common nowadays to assume you'll allow your team to work flexible hours and perhaps work-from-home. Or is that a myth?
On the other side of the coin, I hear of large corporations like Amazon who expect 60+ hours/week and treat engineers as a commodity that can easily be replaced - there's always another hundred engineers in the queue to work at Amazon, Facebook or Google.
These two perceptions are conflicting of course.
Perhaps this is driven by market pressure - large companies with huge recruiting pipelines simply don't need to care as much about their employees. Or they attract team members who are young (naïve?) and think 60-100 hour weeks are "exciting" and a badge of honor.
In the consulting world, where fixed bid projects are common and the pressure is high, you'll find the Death March projects where the hours increase as you get closer to the deadline, until the team is expected to work 24/7 to meet the date.
I've been in that world, and had to make burger runs at 3am. There's some camaraderie there.. the team pulling together, bonding, growing, but that is a very finite resource. When history repeats itself on the second and third project, the team turnover starts increasing.
It's common to see turnover of over 60% per year in consulting companies. I've witnessed that personally on two occasions.
There have to be some guidelines for working hours too.
Core Office Hours
You need to be setting expectations upfront, and core office hours (or working hours) is one of those items.
Core hours simply means the hours that everyone needs to be in the office (or online) to facilitate collaboration.
For example, if standups start at 9:15 then core hours could start at 9:15 and go on to mid afternoon; say 3:00pm.
By keeping meetings to core hours you know everyone will be normally available.
Setting core hours becomes important when you allow flextime.
Given core hours are less than 8 hours a day, you're allowing some to come in early and leave early, while others arrive just in time for standup (sometimes running!) but work later.
The beauty of flextime is that you are accounting for the early-birds and the late-risers equally - well, equally-ish. It's hard to account for team members that work best between 8pm and 3am.
Another reason to allow flextime is to account for those tasks that need your presence away from the office - fridge deliveries, doctor visits, drivers license renewals and more. Ask your team to let you know when something comes up, and allow them to make up the time later in the day/week.
You do trust your team, right? If not, you have other more important issues to solve.
Working From Home
So far, so good. Most people agree with flextime and core hours. Working from home is a hotter topic.
Personally I prefer to limit WFH to a day or less each week, although I'm flexible enough to allow more if it would help out the team member for some personal reason. But as a rule, working from the office is much preferred.
I may be in the minority on this.
Books have been written about letting your dev teams work where and when they please. But in my experience that's not optimal because you are limiting the opportunities for collaboration.
So, everyone works in the office during core office hours.
There is one exception to this - if everyone is remote. I've worked for a software company where virtually every developer was remote, WFH - and it worked because it was the norm.
Everyone collaborated using tools like Slack or HipChat and had these windows permanently open for discussion. There were no water cooler conversations to miss out on, because Slack was the water cooler.
Remote teams work well together, and office teams do too - but it's hard to mix them.
Vacation or Paid-Time-Off (PTO)
This one is easy - always give your team a very specific amount of time off each year. Provide rules such as:
- How does PTO accrue? (hopefully each paycheck)
- Can you have a negative balance and how much? (yes)
- Is there a cap on your PTO balance? (there should be)
- Does PTO rollover to next year? (it should)
- Is sick time the same bucket as PTO?
Give them rules, and make sure you make it very clear that you expect them to take their PTO. Not taking PTO is not good for them, and ultimately not good for the company.
Consider having your own cap - if the company caps PTO at 240 hours that's probably too high. You've let them accrue over 6 weeks of vacation time.. they will burn out.
My suggested cap is 150 hours. Once someone hits that, talk to them about booking some time off.
The best company I've worked for allowed new team members 3 weeks PTO and 3 weeks company holidays (July 4, Christmas, etc) for a total of 6 weeks per year. And it went up from there, getting another day PTO per year worked.
That's pretty sweet.
Another great idea they had was to give away PTO as a reward for exceptional performance. If you won a quarterly award, you'd get a primo parking space and another day off. You get a day off for your birthday too.
Encourage a healthy work-life balance.
Ha! But we have unlimited vacation!
Yeah, sounds great, doesn't it? I've seen this too, and I don't recommend it!
The thinking goes that you want to treat your team as well as possible, so let's allow them to take whatever they need to be happy and productive.
What we quickly came to realize is that:
- Engineers don't like wishy-washy. They'll keep asking "but how much PTO can I really take?" They won't stop asking for a number.
- You're not setting any guidelines, so engineers literally don't know if you think they should take a couple of long weekends each year, or four weeks.
- It will actually make them take less vacation. Why? Because they don't know what's allowed and don't want to be seen taking advantage or more than anyone else. So everyone works longer, relaxes less and gradually becomes more unhappy.
Which makes sense in retrospect.
One parting thought: when recruiting you can often negotiate PTO as well as salary. I once negotiated starting at the "five year mark" for a company so I got more PTO and other benefits.
Everything is negotiable, but you only have one chance.