Inside GitHub's Super-Lean Management Strategy

This is great for creating <i>new</i> products, for innovation.<p>But I&#x27;ve never understood, who then does the grunt work? Who slogs through producing the documentation, and keeping it up-to-date? Once a new product&#x2F;feature is launched, who sticks around for the bugfixes, support, etc., since presumably everyone will be more excited to allocate themselves to the next new big thing?<p>In every company, there&#x27;s a lot of totally boring, unattractive stuff that needs to get done nevertheless. With open allocation, who does that?

At a certain point a myth got started that management was a valid profession in itself and it was perfectly fine for a non-technical person to make technical decisions. And for most businesses today, growth and innovation is going to come from better use of technology.<p>&quot;Non-technical&quot; (I love that word) professional managers are thus incapable of either coming up with innovative ideas or recognizing the opportunities when they do come up because they simply don&#x27;t understand them well enough. For the same reason, they&#x27;re unlikely to make well informed choices between priorities. Even ex-technical people that moved into management still make bad decisions because they often don&#x27;t really keep up with new technology and the changing technology landscape. They might go to conferences and surf slashdot but they aren&#x27;t in a position to actually apply that knowledge so it ends up being practically useless. If they&#x27;re asked how to approach a problem they often just use the approach they would have went with 10 years ago before they became managers because that is what they truly know and understand (because, unsurprisingly, you have to do something to understand it).

Github is fortunate in being one of the few companies that their customers are the same type of people as their employees. This allows them to get a lot of what traditional management is needed for &quot;for free&quot; and allows radical freedom in their management structure.<p>I&#x27;d hesitate to try to apply their example to other companies unless you&#x27;re in a similar situation.

The current resource allocation models mostly stem from non-software industries, especially in financial planning and budgeting. As the result, the fit is not always perfect.<p>Working in software for a little over 10 years, I&#x27;d say of projects that should not have been undertaking by companies I worked for or should not have been undertaking by core developers, 90% would have had a lot of trouble attracting people within such model. Generally speaking, software engineers within companies know their own capabilities better than management, especially non-tech management, and can differentiate between a good and a bad fit for a given approach.<p>On the other hand, I have yet to run into a group of engineers that would not want to attack a valid customer problem, whether it&#x27;s &quot;sexy&quot; or not. The &quot;shit&quot; work some people mentioned, really isn&#x27;t if it is what is needed to make a difference for a customer. Engineers generally take a lot of pride in their work, so if there is a defect, they want to fix it.<p>Seems like such a model could be a much more efficient allocation of resources in the long run, but would hurt some egos in the process.

I think the key quote for me is about how effective Githubbers are as communicators. Which isn&#x27;t at all common in our industry.<p><i>I think about it is as being highly networked. [...] you look at the strength of connections between people, the communication channels, and how information travels amongst them, and then you can draw a diagram.</i><p>What seems like a higher-than-average percentage of Githubbers are particularly effective communicators publicly, even outside the management team. (Zach Holman in particular comes to mind.)

Github is a very special case because they have a relatively simple product and very tech savy audience. I currently work on a very large b2b web platform&#x2F;application where customers are typically 40+ and still using Internet Explorer. Its also so massively complex that you just cant do it without extensive planning and talking about every last detail of the implementation with all people involved. I wanted to avoid it, but not talking things through in detail usually results in misunderstandings and more work down the line.<p>Its great that github can do it like this and i envy them for it, but its not a one-size-fits-all solution to project management

GitHubber here. There&#x27;s some great questions in this thread already. I&#x27;m AFK this weekend, but if you&#x27;ve got more questions about our structure, or how we use GitHub.com to work like this, ask away and I&#x27;ll try to answer them in a blog post next week.

I&#x27;d be more supportive of GitHub if they open sourced some of their infrastructure code.

This approach seems almost magical. There are a couple areas that I&#x27;d like to hear more about.<p>- How detailed is the strategy coming down from the top? &quot;... [W]hat you work on is up to you, within the bounds of what’s important to the company.&quot; What is the process of oversight to determine if each project is &quot;important to the company&quot;? Are there often conflicts in this area?<p>- How does employee evaluation work? Does each member of a project submit evaluations for the others?

&quot;There’s Google’s now-defunct concept of 20% time&quot;<p>I wish people would stop saying this, 20% time is not defunct at Google.

Where did you pick up the link with .html appended on the end? It resolves back to without it and all the internal links lack it.

ot: i really love all these tech sites that just don&#x27;t stop loading crap while you&#x27;re already reading the article. then it just scrolls to the top, bothers you with popups and shit.<p>extremely off-putting. many times i just quit. really great for retaining readers.