开放原子开发者工作坊

原文： http://zachholman.com/posts/how-github-works-hours/

 

转自Github公司Zach Holman工程师的一片文章，不做评论收藏，留待后用。 

 

You're reading part one of How GitHub Works, a three-post journey into how we work at GitHub. They're all separate posts on different topics, but if you're interested you can also read the other two: Be Asynchronous and Creativity is Important.

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 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 morehours 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:

• Wake up around 10am, check Campfire logs, clear overnight support tickets
• Bus into work and grab lunch around noon or 1
• Work from 1pm to somewhere around 6-9pm at the office
• Go home and work/relax from my couch until 2am, or:
• Go out and drink with coworkers (more on this later)

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.