How GitHub Works. Scott Chacon.

GitHub was forced to be distributed and flexible which made them happy.

Hours are bullshit

Crafting code is a hugely creative endeavor. Set up an environment where employees can be creative. You can’t force creativity to happen between 9-5. The best solutions happen when you’re in the zone. Interruptions kill productivity. Hours are bullshit. Focus on whether work is getting done, not how many hours are being thrown at a problem.

When you’re in the zone, you can crank out some great work, when you’re not you’re not in the zone and aren’t being productive, do something better, go to the zoo with your kids. It doesn’t matter if it’s 10am on a Tuesday. Creativity doesn’t abide by business hours.

Embrace flexibility

Humans weren’t made to be working 90 hours/week. We need to get out, need to rest brain. Working long hours isn’t a badge of honor, it’s a badge of foolishness. All nighters are a recipe for redoing everything again later. Marathon code sessions drain you mentally and lead to poor code quality. Optimal mindset is: happy, fresh, creative, fulfilled, open, clean slate, loving what you’re doing and creating. Create an environment to foster these things.

“Startups are only for single 20-somethings.” Bullshit.

GitHub approaches problems from first principles. What are we trying to accomplish? What are we trying to do? Is the policy addressing a real problem or cargo-culted from previous companies? Are vacations really a problem that require a vacation policy or can we treat our employees like responsible adults?

Being less hour-centric = being more family-centric.

Happy families = happy coworkers. Happy coworkers = productive companies.

Trust your employees, but verify that things are getting done.

Working like this requires communication. Who’s committing? Who’s participating? What does their code look like?

Be asynchronous

If you want to hire the best you need to look for a globally distributed work force. Not likely that the best programmers all live near you. Limit required in person contact. Use chat. GitHub BEER:30 – every friday at 4:30, it’s beer and fun and catch up time. GitHub opens the phones at designated times to allow anyone to call in and ask the founders questions. Post recordings of talks given at GitHub.

Want developers in the zone, being productive, doing actual work, not being distracted. Environment where anyone can walk up to you and interrupt with a question is bad! When wearing headphones, the person should be considered behind closed doors in an office and should not be interrupted. Allow developers to be in a place of productivity without being distracted.

No meetings. No in person distractions. No managers, or rather 60 managers. Everybody is a manager. Here are the problems we need to address, choose what you want to work on, make it happen. Crowd sourcing the management of the company.

GitHub: product company, dog food, full ownership, profitable

GitHub Teams: mac, help, shop, enterprise, gist, pages

Small teams let you focus.

Aim for minimal process. The minimum viable process is the least process required to have things functioning well.

Show code as soon as possible, ship ASAP for immediate feedback. “this is what I’m working on, what do you think?” Chat, pull requests, wikis, internal apps. Make it ok to say “no”. If the culture says it’s not ok to say no, then people will not be as creative as they can. Ideas and projects discussion board for all employees. Draw good ideas from across the company, otherwise you’re wasting your resources.


  • Auto deploy every time master has been built successfully.
  • Simple branching, designer friendly “non-technical” deployments, for example, support team can fix copy on a page and deploy.
  • Simple rollback, partial deploys, staff-only, specific servers, specific processes.
  • Pull requests are discussions that improve code quality.
  • Push branch, get feedback, make improvements, merge branch.
  • Asynchronous and non-invasive. 

It’s ironic that in so many large companies, the software on our machines was built with the same mindset and processes that management doesn’t want us to use.

A slow test is a regression. The CI server should build every branch.

Graph everything. Collecting metrics gives you a different perspective on performance (graphite library). GitHub pushes all of their data. Tweets @github are graphed to look for anomalies with @ mentions to see what was going on.

“Mass assignment usage in Rails was not well disclosed.” -Scott Chacon

During public key reset, graphs of rejected ssh connections, successful ssh pushes and support requests were useful.

Custom dashboards showing useful metrics is important.

Google bot hits are tracked separately to prevent false positives.

You don’t need distractions. You don’t need to be in the same country. You really don’t need a lot of process.

GitHub: 60 employees, 0 have left

This requires a happiness-oriented workplace.

Foster exploration

  • Shared side projects (Hubot started as fun and became a business)
  • Kindles and ebooks for every employee
  • Arduino lessons
  • Spanish learning
  • Conferences
  • Meetups
  • Hiring
  • Learning
  • Marketing
  • Meet people
  • Encourage networking

Music app from GitHub keeps track of who likes what music and plays based on music tastes who’s in the office. People can drag drop tracks to be queued

Be flexible. Build a company you want to work for. Push for happiness.

Slides and full video from talk available from Chariot Solutions.