
Inside GitHub's Super-Lean Management Strategy--And How It Drives Innovation - petercooper
http://www.fastcolabs.com/3020181/open-company/inside-githubs-super-lean-management-strategy-and-how-it-drives-innovation.bollocks
======
xal
Be careful trying any kind of lessons from Github. I admire them greatly but
they are an (almost-) unique company because every single person who works
there also uses their product 8 hours a day.

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.

------
lifeisstillgood
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?"

------
Kynlyn
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.

