Frederick Winslow Taylor wrote the seminal analysis of management and efficiency in 1911 with The Principles of Scientific Management. He took the first scientific approach towards maximizing efficiency in manufacturing jobs. Time is money. Faster is better. More hours are better.
Hours are great ways to determine productivity in many industries, but not ours. Working in a startup is a much different experience than working in a factory. You can’t throw more time at a problem and expect it to get solved. Code is a creative endeavor. You need to be in the right mindset to create high-quality code.
Think back to the last time you were depressed or angry. How productive were you? Now think back to the last time you were truly productive. Code flying from your fingertips. Not just the sheer quantity- the sheer quality of that code. When you’re in the right mindset, your best day of coding can trump weeks of frustrated keyboard-tapping.
We want employees to be in the zone as often as possible. Mandating specific times they need to be in the office hurts the chances of that. Forcing me in the office at 9am will never, ever get me in the zone, but half of GitHub may very well work best in the morning.
By allowing for a more flexible work schedule, you create an atmosphere where employees can be excited about their work. Ultimately it should lead to more hours of work, with those hours being even more productive. Working weekends blur into working nights into working weekdays, since none of the work feels like work.
Everyone at GitHub is different. I don’t really have an “average” day, but this is a close approximation:
We have a contingent of (insane) people who come into work around 7am, we have some who come in at 3pm. We have some who are more productive at home. You don’t have to come into the office every day if you don’t feel like it (although most of the time everyone comes in).
Why is our day so “loose”? Because 1) working in chat rooms lets us work when and where we want, and 2) we want to create an environment where people are most productive. There’s no one work day that fits everyone’s productive hours, so we don’t enforce one.
We’re currently at 35 employees and growing, and this approach still works great. But managers love to assign hours for a reason: it gives them the illusion that hours can measure performance.
If you don’t go hard on hours, you do have to look at different metrics. How good is their code? Are they fixing bugs? Are they involved in work, or is the greater flexibility not motivating them?
It’s difficult to make these qualitative judgements, but they’re still going to be more valuable than “did this guy put in his ten hours of work today”. Because as soon as you make it about hours, their job becomes less about code and more about hours.