In my opinion, GitHub does the best original thinking on the Web about how to run a tech company, and Clay Shirky is right to call them one of the most important companies in the world. Also in my opinion, Ryan Tomayko wrote one of the best "how GitHub works" posts ever:
What we're learning at GitHub is that opting in to open source project constraints often results in better natural survivability characteristics for many types of business, product development, and operations activities.
It shouldn't be a surprise that a company which specializes in tools and workflows for open source development, and hires based on open source participation, finds the tools and workflows for open source development useful in its day-to-day operations. However, in Tomayko's post, he explains that GitHub, like Valve, successfully escapes the Dilbert-hell resting state which many people assume all startup activity converges to, that GitHub does so using GitHub, and that he believes other tech companies can do the same thing.
Tomayko's post includes a 43-minute presentation from a conference, and it's worth watching, although a little overlong in my opinion. In the presentation, he highlights a traditional corporate org chart:
He then compares it to a chart of open source activity in the Perl community which was generated by software which measured and correlated interaction using the GitHub API:
He says GitHub is more like the second chart, and I believe him. However, I think any healthy company is more like the second chart; the first org chart represents a dreamworld cooked up by overpaid aristocrats, pitifully focused on their hierarchy, whereas the second is founded on measurement and observation. (You don't need my political point of view to look at the first org chart and notice that it is an absurdly simplistic model for any human social system.)
Every company with more than one person working there will feature some tension between the rules people set out and the way people actually behave. Healthy companies have very little of this tension; dysfunctional ones have very much. GitHub throws away the traditional social fiction and mostly focuses on the reality. I say "mostly" because Tomayko explains that GitHub does present one new social fiction: in their recruiting, they claim they have no managers, but what that really means is that everyone is their own manager, and by signing on, you accept the responsibility of managing yourself.
I definitely recommend reading Tomayko's post and watching his presentation. If this was the type of dipshit mating-honk you sometimes find on Hacker News, I would go on to further tell you that GitHub's way of organizing projects is The Way and/or The Future. But I'm going to stop short of that, and simply call it one way and one future (albeit maybe the best way and the best future), because of an extremely powerful counterexample: Skyrim (and World of Warcraft).
Modern fantasy role-playing video games feature incredible gamified to-do lists. Their effectiveness is far beyond any to-do lists which exist in the real world. If I ever figure out how to make my own real-life to-do lists feature the same compelling blend of enticement, reward, and repetition, I'll become so productive that people will suspect me of being an entire army of clones who all happen to share the same name.
It's incredibly easy to sit down to play one of these games and not stand up again until six or eight hours later. The whole time, you're telling yourself that you're just going to go and do this one other task. People have spent entire years of their lives in these games, accomplishing far more in the fantasy worlds than they do in reality (and sometimes literally starving to death in reality as a consequence). It sounds crazy to say it, but for a very large number of people, having a computer tell you what to do next must feel really good.
I'm not the only one who wonders what it would be like to gamify my to-do lists. And because the group raids aspect of Warcraft requires a great deal of planning and coordination, fans of the game -- including Joi Ito, the entrepreneur, investor, and director of MIT's Media Lab -- claim that it's not only entertaining, it's great training for project management, including project management in technology companies:
I am in awe of Persimmon who is our raid leader. She works in a hospital in real life. She is the stabilizing force during the raids, supporting the class leaders, nudging the conversation and keeping the raid moving as fast as possible without moving too fast. I find that she reminds me of many successful open source project leaders or Jimmy Wales of Wikipedia, except that what she has to do happens much faster and in real-time. Without her fully customized user-interface and scripts she would never be able to manage what she does...
The structure and the organization required to complete missions or quests in WoW adds a great deal of focus and complexity to the community compared to a chat room and the communications and management begins to feel much more like collaboration in a work environment. I think that the ever-evolving user interface and communication tools that we are developing might impact the future of management in the real world. My feeling is that what we are doing in WoW represents in many ways the future of real time collaborative teams and leadership in an increasingly ad hoc, always-on, diversity intense and real-time environment.
Although Ito compares running a raid to running an open source project, it's clear that his model implies managerial responsibility. But if you read Tomayko's post and watch his presentation, you'll witness a strong argument against the use of any managerial staff in technology projects:
Avoid synchronization / lock points when designing process. This is DVCS writ large. We don't have a development manager that grants commit bit to repositories before you can do work, or a release manager that approves deploys, or a product manager that approves work on experimental product ideas. Work toward a goal should never be blocked on approval. Push approval/rejection to the review stage or automate it, but surface work early to get feedback.
Another major contrast between Ito's post (made in 2006) and Tomayko's is that Ito praises always-on communication, and treats its usefulness and primacy as a foregone conclusion, while Tomayko recommends that it be strictly optional.
The reason why?
This is [distributed version control systems] writ large.
Distributed version control systems decouple collaboration from coordination. This is the same benefit which Wikipedia provides to archivists and Twitter supplies to activists. It explains why Clay Shirky likes GitHub, too, because it's the same dynamic Shirky explores in his terrific book Here Comes Everybody. He finds the act of decoupling collaboration from coordination -- and removing authority figures, by removing synchronization -- at the heart of a huge range of online and social phenomena, and identifies it as the aspect of the Internet most likely to transform society permanently (just as the printing press eventually did).
It's a brilliant idea. It's an idea whose time has come. And it obviously works for GitHub. But I'm not sure how to reconcile Shirky's very compelling arguments or GitHub's wonderful success with the sheer, dimwitted enjoyment I get out of being told repeatedly to go over there and kill another orc. Again.
One thing which makes it tricky is that when you participate in open source projects on GitHub the site, you're doing the same essential process that working at GitHub entails, and all the working parts of that process are exposed. You can track issues, commits, and pull requests, and you can see how everything fits together. But in games like Warcraft and Skyrim, although the task lists are impressively addictive, whatever makes them that way is hidden below absurdly primitive user experiences. Nobody will ever hold up the Warcraft quest log as an example of beautiful UI.
A lot of companies are working on ideas like gamifying the workplace. I think a lot of them will fail, and that they will look stupid in the process, because most of these companies don't seem to think very hard about what "gamifying" means, and they don't seem to think about what "the workplace" means at all. It's possible that GitHub and Valve represent the first wave of what will become a normal, predominantly office-free way of living and working for the same people who would have been called "office workers" throughout the 20th century.
If that's the case, then the whole concept of "gamifying the workplace" might be irredeemably fucked, because "workplace" might not even be a meaningful term in a few decades. It certainly won't refer primarily to physical locations; for many people today, it already doesn't. I think a lot of these companies are putting futuristic lipstick on a Steam Age pig. Adding badges and meaningless points to a process which feels antique is no way to create the future.
If there is any future to ideas like "gamifying the workplace," it's in some merger of elements from GitHub and Skyrim, but I'm still not sure which elements, or in which proportion.