Inside GitHub's Super-Lean Management Strategy

http://www.fastcolabs.com/3020181/open-company/inside-githubs-super-lean-management-strategy-and-how-it-drives-innovation.html

by ollydbg • 13 years ago

126 44 13 years ago

fastcolabs.com

petercooper• 13 years ago

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.

swanson• 13 years ago

This post was on the front page last night/this morning and dropped off, this was to avoid the duplicate check methinks

crazygringo• 13 years ago

This is great for creating new products, for innovation.

But I'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/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?

In every company, there's a lot of totally boring, unattractive stuff that needs to get done nevertheless. With open allocation, who does that?

has2k1• 13 years ago

I think that is where "cultural fit" comes in, where everyone has a sense of ownership of everything for which they possess the required skill-set.

If that is so then the real magic happens at the hiring stage.

mojuba4• 13 years ago

More often than not, boring work that nobody wants to do at your company is an indication that something went wrong in the process of design & development of your product.

For example, from my experience as an end user, if a product or service relies heavily on documentation, "knowledge bases", forums etc. then it's pretty much fucked up already. Work of any kind at a company behind such a product would be boring: from management and engineering to QA and technical writing.

Github is obviously not among this kind of companies. And I wonder what would be considered "boring job" at GitHub then.

dasil003• 13 years ago

You're conflating good product design with good company processes, but those are completely separate concerns. Of course a good product shouldn't require documentation because the whole point as a consumer product company is you are bending time and space to make something that people want to pay for. However in order to accomplish that there will most likely be some shit that needs shoveling along the way. Who does the bookkeeping at Github for instance?

sanderjd2• 13 years ago

The idea that the existence of "boring" work at a company is an indication that the company did or is doing something wrong is specious, and as a user of lots of software, I really hope this mindset doesn't become common. I want the people making the software I use to be ready and willing to do tough and unglamorous work that makes my experience better. Github's solution seems to be for everyone to really own and care about the product, such that working on "boring" things is a matter of pride. That's a really good solution, but creating and sustaining that culture is really difficult. The lesson others should learn from them is not "don't ever have boring work to do", but rather "create a culture where employees hold themselves and each other responsible for getting the boring work done".

rfnslyr• 13 years ago

Honest question, have you worked a real job before?

Documentation, by virtue of existence, does not negate product integrity. There is so much extremely complex software with very specific applications out there with documentation that would take you very long to comprehend.

It's the behavioural nature of the system being documented that determines complexity.

lttlrck• 13 years ago

There are plenty of industries where customers want to see documentation upfront before purchase and if you can't provide it you'll lose the sale, it's a clear indication of an immature product. Maybe not in your industry, maybe you don't care about lost sales, but to say any work in companies with such customers is boring is utterly naive.

specialist• 13 years ago

Word of support: Some people call this "technical debt".

At my current day gig, developing new "products", I spend a lot of time trying to understand what's what. Oversimplifying: dealing with terrible legacy code, overwraught design, poor implementations of poorly defined interfaces, supporting byzantine processes.

We have acres of documentation. Mostly out of date, useless, or both. We make up for the lack of clarity by having lots and lots of meetings, where we get to swap misunderstandings.

I experience recurring eurekas, each time I finally understand the actual end goal (business need, user's use case). Quickly followed by a face palm slap, wondering why anyone would make such a simple problem so frikkin hard.

swampthing• 13 years ago

Zach Holman has an answer on Quora on this:

http://www.quora.com/GitHub/How-does-GitHub-handle-tasks-tha...

eliot_sykes• 13 years ago

A link to the same page on Quora, but with ?share=1 appended to the URL so login isn't required: http://www.quora.com/GitHub/How-does-GitHub-handle-tasks-tha...

bshacklett• 13 years ago

I don't know how common this is, but I personally love working on documentation and fixing bugs. I can't imagine I'm the only one out there. Perhaps they just make sure they have enough people that are interested in that type of thing?

kawsper• 13 years ago

I think there are different kind of developers. Some like to build new and shiny stuff, where others like to maintain and keep stuff running.

I like to do both things, and can't say that I like building new stuff more than maintaining.

bkbleikamp• 13 years ago

Who slogs through producing the documentation, and keeping it up-to-date? Once a new product/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?

Doing this work is part, and perhaps the most important part, of shipping a feature. It's not just boring work. If someone isn't prepared to support something, they shouldn't ship it.

yeukhon• 13 years ago

I doubt they don't have assigned roles. It would be a chaos when everyone just write 100 lines for every project. Nothing will get done.

I am sure people work on specific tasks every day but they are free and welcome to contribute.

alexdevkar• 13 years ago

This approach seems almost magical. There are a couple areas that I'd like to hear more about.

- How detailed is the strategy coming down from the top? "... [W]hat you work on is up to you, within the bounds of what’s important to the company." What is the process of oversight to determine if each project is "important to the company"? Are there often conflicts in this area?

- How does employee evaluation work? Does each member of a project submit evaluations for the others?

glasz• 13 years ago

ot: i really love all these tech sites that just don't stop loading crap while you're already reading the article. then it just scrolls to the top, bothers you with popups and shit.

extremely off-putting. many times i just quit. really great for retaining readers.

robbfitzsimmons• 13 years ago

I think the key quote for me is about how effective Githubbers are as communicators. Which isn't at all common in our industry.

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.

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

sologoub3• 13 years ago

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.

Working in software for a little over 10 years, I'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.

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's "sexy" or not. The "shit" work some people mentioned, really isn'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.

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.

lifeisstillgood3• 13 years ago

Agreed - but I have thought for a few years that management as a career and a well remunerated one is coming to a close - one of the main drivers for me to get "back" to coding

sologoub3• 13 years ago

Well, facilitators and enablers will be in demand regardless of what methodology you subscribe to. For the last 8 years I've been a product manager (& director). This is one of those jobs that if you do a mediocre job, at best you'll be a nuisance, at worst an impedance. If you do a stellar job, your team's productivity will skyrocket and so will the returns on the investment.

PMs, like many other enablers/facilitators, are there to weed-out noise and make sure the team is always in the know on the relevant context and insights. When things go badly, strong PMs provide cover for the engineers to work through the storm and continuously synthesize all forms of feedback to ensure engineers have proper situational awareness and facts to make sound decisions, but not thrash in response to whatever strife might be out there.

There are other "managerial" type professions that have a place and make things better. All good managers know how to resolve conflict and make sure the team knows about any land mines, but also knows when to get out of the way and let people work. Individual development is also the job of the manager.

siliconc0w• 13 years ago

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.

"Non-technical" (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't understand them well enough. For the same reason, they'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't really keep up with new technology and the changing technology landscape. They might go to conferences and surf slashdot but they aren't in a position to actually apply that knowledge so it ends up being practically useless. If they'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).

ma2rten• 13 years ago

I don't think so. Counter-Example: Steve Jobs.

The problem is that most technical people are also bad prioritizing things: making wrong assumptions about how the product is going to used, assuming that if it is technically difficult it must be valuable, wanting to rewrite things when that is too expensive, wanting to use the latest shinny technologies.

vonpidda• 13 years ago

You seem to be making the wrong assumption that innovation is technology..? On the other hand you talk about growth and innovation coming from better use of technology. Innovation is a behavioral outcome, it's about behavior and its implications. The problem so far is that decisions of behavioral nature is taken by managers for one reason or the other not qualified to do so...

shalmanese• 13 years ago

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 "for free" and allows radical freedom in their management structure.

I'd hesitate to try to apply their example to other companies unless you're in a similar situation.

crbnw00ts• 13 years ago

Another example which backs up your hypothesis is Valve; a gaming company filled with people who love games, and thus they are their own customers. They too have a "no management" management approach.

briandoll• 13 years ago

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

nolite• 13 years ago

Does github use Jekyll for it's blog? And what chat/video conference software is used, Skype?

markdotto• 13 years ago

Fellow GitHubber here :).

No, we don't use Jekyll for our blog. It's part of the GitHub.com codebase I believe.

For chat, all standard stuff really :). We use Campfire for group chat (dozens of rooms), Gtalk/AIM/etc for individual chats, and Skype or FaceTime for video chats.

kayoone• 13 years ago

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

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

alayne• 13 years ago

I'd be more supportive of GitHub if they open sourced some of their infrastructure code.

arkem2• 13 years ago

"There’s Google’s now-defunct concept of 20% time"

I wish people would stop saying this, 20% time is not defunct at Google.

barry-cotter• 13 years ago

Be more specific. One presumes you are a Googler. If so, when was the last time you did a 20% project, how much dedicated, blocked off time did it have, and how did it effect your relationship with your manager?

Stuff like 20% time being defunct becomes common knowledge through multiple independent repetitions, like Amazon being a shit place to work, Google not doing customer service or Zynga, well, Zynga.

arkem2• 13 years ago

I recently left Google (about a month ago) but in my roughly 18 months at Google I was always working on 3 or 4 projects of my own choosing outside of my 'day job'. They each took up between 5-15% of my time so I'm happy lumping them all together and saying that they were my 20% time.

One of my non-day job focus areas was security education, I ran several classes/events to try and teach people about writing secure software. A public example I can give is the Hardcode Secure Coding competition which I was one of the organizers and judges. See http://googleonlinesecurity.blogspot.com.au/2013/05/the-resu... (I'm one of the guys in the desk photo).

Another example of my 20% projects was a dashboard that compared the number of security reports that had been reported against various parts of Google. It compared them with a lighthearted metaphor and was displayed in a relatively high traffic area in the hopes that it would draw the interest of people who did not track security issues day to day.

A final example is that I worked a little bit on Glass, but only as an interested outsider. I helped out with some security reviews of internally developed Glassware on a volunteer basis as well as wrote my own Glassware to help test the platform.

Blocked off time varied, Hardcode required a lot of blocked off time (including a trip to Singapore). My other projects generally needed a couple of hours at a time. In an average week I'd work two half days on my side projects (not every project every week).

My managers were both very supportive (and all round great guys), it helped that I could explain the potential benefits of all my projects and that they were not completely unrelated to my day job (performing security assessments and code reviews of non-Google code/systems). There are probably limits to what my managers would endorse, but I never got anywhere near those limits.

Inside GitHub's Super-Lean Management Strategy

Related Stories