5 ms·
I'm super sick of these articles patting Valve on the back for its super-innovative business structure. The fact is, you can afford to have a goofy office like
by Sivart13 14y ago
I'm super sick of these articles patting Valve on the back for its super-innovative business structure.
The fact is, you can afford to have a goofy office like this when you've already achieved a comfortable level of success. Valve has been free and clear ever since Steam became the go-to place for digital game distribution, and Github is pretty comfortable in its place as the top source code host.
Emphasizing these companies kooky structure conflates correlation and causation. It's not that they're profitable or interesting because of their management structure: instead, they can afford to play around because they were early movers in a very profitable space.
- Evbn 14y agoDid they play around before they were successful? Did others try and fail in the same space? Valve didn't invent software downloads.
- georgemcbay 14y agoValve is pretty unique in that it was founded by Microsoft millionaires. They had their own personal fortunes to play around with (much like Curt Shilling, except they also had backgrounds in shipping very successful software) while they figured things out. However, while Steam is certainly a very big deal now I think it is silly not to mention Half-Life as a very important part of Valve's early success. Half-Life was very successful and the fact that it, its sequels and the Source engine begat so many related franchises like Counter-Strike is a big part of the reason Steam was able to leverage a huge built-in audience and succeed in its early days while so many would-be-competitors failed.
- einhverfr 14y agoOne thing about Microsoft though is that they leverage things like email lists internally to provide many opportunities for participation one might think of as primarily characteristic of these flat organizational models. For example, a lot of the work that was being done on competing with Linux when I was there was taking place on the basis of this sort of flat model. The point I am making is that these wouldn't have occurred to the Valve founders in a vacuum. They were built on top of what they already knew worked. So it's not a matter of playing around but rather trying to copy what you think works well in your past experience and ditching the rest.
- f1881bbee31 14y agoMany popular web-centric software companies operate this way, and it's basically how open source software development operates. Anyone with even an ounce of management skill and education knows that when you have skilled people working for you, you get out the way and let them do their thing. This isn't exactly news.
- DanielRibeiro 14y agoWhich companies? I found Valve to be quite unique (Github seems to be similar, but they seem to operate more like a group of open source projects). I'm serious: I find this inspiring, and would love to know other companies doing something similar.
- MattRogish 14y agoFogCreek and StackOverflow. Etsy. We're doing it, too, at my company Funding Gates (http://fundinggates.com/jobs http://fundinggates.com/jobs)
- tptacek 14y agoThat doesn't sound like the Fog Creek I've read about, but maybe I'm just projecting from their well-publicized salary/seniority ladder? The dribs and drabs I've read about Joel's companies suggest that they're well-run classically-organized teams with a heavy dose of _Peopleware_ thinking (which is a great book).
- MattRogish 14y agoOh, I see. I was speaking primarily to: "Anyone with even an ounce of management skill and education knows that when you have skilled people working for you, you get out the way and let them do their thing. This isn't exactly news." I don't know about the internal organization of the teams
- f1881bbee31 14y agoUnless this post is wrong, facebook in many ways, too: http://framethink.wordpress.com/2011/01/17/how-facebook-ships-code/ http://framethink.wordpress.com/2011/01/17/how-facebook-ship... 20% time policies are another variation. The whole notion that everyone is responsible for product is pretty mainstream at this point, increasingly so since the whole "lean startup" concept gained traction.
- pchivers 14y agoI don't know if it's possible to figure out which is the chicken and which is the egg in these cases. Semco, a Brazilian manufacturing company, has been using a "boss-less" style of management since the 1980s. From what I understand they were not exceptionally successful before they implemented this management style. http://en.wikipedia.org/wiki/Ricardo_Semler http://en.wikipedia.org/wiki/Ricardo_Semler
- schacon 14y agoI'm curious how you think it's possible for a structure like this to emerge after some level of success? You think that any company sets up a traditional management structure, accomplishes success and then fires all the managers and tells everyone to work differently? Or do you think it might be more likely that thinking differently early on about how to treat employees and how to focus creative energy somehow helps to achieve that success? GitHub has always run this way, since it was 4 people. When we tell people how we operate, they have always responded that it will never scale - people have told us that since we were 4. We're now at nearly 100 employees and it's still working great. Valve is 300 and Gore has several thousand, so we're pretty sure we can keep going this way. We are slightly different than Valve, but their handbook really resonated with the way we do things. The main difference between companies like Valve or GitHub and many other companies is that we don't look at other places and ask ourselves how we can copy their structures, how we can cargo cult their success, instead we look at our problems and ask ourselves how we can address them in the best way possible. It appears that Valve has done the same thing and we've come to some similar conclusions. I think this is a big reason why we've been successful - that we ask ourselves this when approaching product too. You say we're sitting pretty at the top, but when we started there were tons of source hosts. Valve was just as bad - starting in another industry that was totally saturated. The reason we were able to break through I believe was largely due to the fact that we thought about problem solving differently than the industry leaders that we started up against. The real point you should take from the article is not that Gore or Valve or GitHub are lucky, but that we approach problem solving in a very different way and that might be an interesting thing to take a look at. If all you read in an article like this is that we're 'goofy' or 'kooky' then you're missing everything that's important and it's a waste of time for you to read the article at all. In fact, if that's what you take and then you try to copy us you will fail horribly in what you do, because you're blindly copying the least important of the many symptoms of this approach. Approach problems from first principles. Figure out what the best possible experience would be for the person using your product (not just the person buying it). Make that experience a reality. Don't copy anyone. Do that same thing internally. Now what does your company and your product look like? That should be what you take from this article.
- velshin 14y ago
- einhverfr 14y agoI think it's more complicated then that. The fact is that there are multiple ways to do things. These different ways have different tradeoffs. You know, if you are just starting to found a company with 2-3 friends, chances are you jump into eachothers' roles as needed. There may be an official hierarchy but chances are pretty good that this hierarchy exists mostly on paper. As you hire employees, typically you want to maintain control and this is where management structures come in. I think that there are all sorts of possible management structures that could work and these have different advantages and disadvantages.
- jacobquick 14y agoI forwarded Valve's employee handbook to an economist friend a few months ago, and he suggested that whoever set up the company was actively experimenting with public choice theory, and that from that perspective the good and bad things mentioned in the handbook were not that difficult to suss out from the structure.