Evolving notes on open allocation and Github management
These are my previously internal and incomplete notes from researching Github's hierarchy and open allocation. I'm making them public to solicit feedback while I continue my slow research.
trifecta of culture
1. optimize for happiness
allow people to work remote (more than half of github is remote)
everything is asynchronous - log everything (chat, issues etc) "everything needs a URL"
- chat ops (launch servers, make graphs) : hubot becomes a audit trail
don't separate, tools for everyone
no managers, teams self form, ship internally for prototype/testing
"cant' get anyone else to work on something with you? its probably a bad sign"
2. first principles
problem? often jump to solution,
build something thats beautiful and simple to use
buddy program for new hires
"boxen" setup app for new hires http://boxen.github.com/
no qa teams, every team is responsible for qa, integration etc
write out what's important to you
invest in employees makes fiscal sense
happy people produce better work
happy people help you recruit
happy people keep you happier
trust employees, help them out, check on every once in awhile
limit required in-person chat
everything is on chat, its logged
no technical meetings
"create more value than you consume"
highly networked teams
people before profits
its not perfect
its not flat
investing in humans is how to build the best company
pay enough to remove money as a motivator
pushing responsibility down (the chain) - ship it
Holman Keeping People
nobody likes the man
friction is frustrating
"I'll use your product if you add my feature"
attachment to the unique
people like to stick around for interesting reasons
culture is not ping pong tables
"your main job as the manager of that section is to communicate strategy, and then let other people determine what’s important in order to accomplish that strategy" - tom
communicate with least common denominator
it can be harder to communicate over text, to get your idea into actionable points
does it work?
will this work for another company?
github works because many of the developers understand the industry
other companies may be in industries that are less understood?
external demands on the company
“There is no such thing as a structureless group,” Freeman wrote. “Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion.”
https://vimeo.com/85490944 - Spotify Engineering Culture