Inside GitHub's Super-Lean Management Strategy--And How It Drives Innovation(fastcolabs.com)
fastcolabs.com
Inside GitHub's Super-Lean Management Strategy--And How It Drives Innovation
http://www.fastcolabs.com/3020181/open-company/inside-githubs-super-lean-management-strategy-and-how-it-drives-innovation.bollocks
3 comments
Recently read a breakdown of the three main stages of team formation and the subsequent management styles needed
- Survival (Crazy deadlines, lack domain knowledge.under resourced). Style : command and control, with aim to clear enough time to get to
- Growth ( Adequate time, domain knowledge) Suitable for learning and experimenting with new methods and tech. Style: Coaching: needs structure and encouragement to reach new skills and potential
- Self-directed: individual team skills top notch, good domain knowledge and sufficient time to experiment. Style: facilitation - check in from time to time, discuss whys of strategy etc
It seems pretty clear GitHub is in the third category - but they did not get there by having a crazy management structure - they got there by being a skilled team, that then was able to attract and hire equally skilled people. They never found them selves with dumb coders who needed to learn something other than Java and don't know why source control is useful. So because of that they did not grow layers of management as a form of duct tape holding it together, and because of that they found no need to add in those layers once management stuff needed to happen.
The problem is of course that most in house software departments are thus massively over staffed if the coders are good enough to be self directing, and if not the coders are bad enough that you need to stop and skill up, but which managers are going to say "these guys and this environment is pants, hire some good coders and you won't need me, please can I print out a CV?"
- Survival (Crazy deadlines, lack domain knowledge.under resourced). Style : command and control, with aim to clear enough time to get to
- Growth ( Adequate time, domain knowledge) Suitable for learning and experimenting with new methods and tech. Style: Coaching: needs structure and encouragement to reach new skills and potential
- Self-directed: individual team skills top notch, good domain knowledge and sufficient time to experiment. Style: facilitation - check in from time to time, discuss whys of strategy etc
It seems pretty clear GitHub is in the third category - but they did not get there by having a crazy management structure - they got there by being a skilled team, that then was able to attract and hire equally skilled people. They never found them selves with dumb coders who needed to learn something other than Java and don't know why source control is useful. So because of that they did not grow layers of management as a form of duct tape holding it together, and because of that they found no need to add in those layers once management stuff needed to happen.
The problem is of course that most in house software departments are thus massively over staffed if the coders are good enough to be self directing, and if not the coders are bad enough that you need to stop and skill up, but which managers are going to say "these guys and this environment is pants, hire some good coders and you won't need me, please can I print out a CV?"
I think it's a worthwhile goal to attempt to achieve this in other companies, but it's also important to truly understand why this works so well at GitHub.
GitHub is largely developers writing software for other developers. An interesting problem to a GitHubber is just as likely to be something that their customers are interested in. GitHub is a classic example of dog-fooding. They use their own product and many of their employees used the product before they came to work there. A typical developer at Github is very likely to have the same vision (and passion!) for the product as the owners of GitHub.
If your product is software for a vertical that doesn't happen to be other developers then are going to be likely challenges. What is interesting to the developers very well might not be interesting to their customers.
GitHub is largely developers writing software for other developers. An interesting problem to a GitHubber is just as likely to be something that their customers are interested in. GitHub is a classic example of dog-fooding. They use their own product and many of their employees used the product before they came to work there. A typical developer at Github is very likely to have the same vision (and passion!) for the product as the owners of GitHub.
If your product is software for a vertical that doesn't happen to be other developers then are going to be likely challenges. What is interesting to the developers very well might not be interesting to their customers.
This is so profound that when Github they face a significantly smaller set of scaling challenges. By definition everyone there is a expert user of the product and will have a complex and valid view of what's lacking and what can be improved.
I'm glad they are utilizing this gift to the fullest and experiment with new ways of doing things. They can significantly contribute to the global brainstorming effort of how to build a better kind of company. But be careful deriving lessons verbatim. If you want to apply lessons from github to your own company you will first have to figure out how you can get everyone in your company to do everything ( writing, reporting, identity management, coding, designing, ... ) through the same product that you are trying to sell.