How GitHub Works: Hours are Bullshit

原文

Hours are bullshit

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.

A day

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.

Enforcement

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.