So there are two things that remain unclear from this analysis:
1) Moving between Valve projects may be like a "market" where the "buzz" around a project is like its "price"... but then the analogy breaks down, because in a real market, you'd have to pay to be on the hot team.
But at Valve you don't, so in this case, why doesn't everyone just drop their project and move to the hottest, most interesting team? Obviously in real life not everyone will, but if a team only needs 5 people, and 50 people want to join, who determines who really joins? Well, the project manager will have to choose, and now we're just back to managers choosing. Or am I missing something?
2) There's a lot of grunt work in software development. Bugfixes to maintain a year-old product, writing documentation, etc. If nobody wants to do the grunt work, then who does it? Because there's usually more grunt work than people who want to do it. Everyone wants to work on the new exciting sexy stuff, but that's not always what generates revenue and pays people's salaries.
This culture was pretty active at Google and it had some interesting downsides. The fact was that people were recognized for shipping and not for 'finishing' and so a lot of shipped but unfinished things clogged things up. When a bazillion people were being hired, new hires would be dumped on a project as their 'starter' project, and the smart ones would figure out it was a dead end and move on quickly to either their own project or one that was about to ship.
During the crisis in 2009 when hiring froze, and the new hires dried up, this became unsustainable and folks had to be 'incented' to work on less glamorous jobs. Really good project managers made a group feel good and the community aspects kept people around, but they hadn't solved the problem before I left.
I would expect that for games or anything which has a relatively short life after being shipped, you could extend this sort of thing for a long time.
Vertically integrated web based businesses like Google have a tremendous advantage that comes from being able to prototype something and then instantly have it available to all customers with a simple push [1] out to production.
There were of course different levels of thing, Gmail was a 'big' thing, updates to the calculator one box, were 'small' things. But everything has a certain amount of technical debt [2] associated with it. This was especially true of infrastructure changes as there were often many subsystems that might be affected in one way or another and each of them usually had some sort of 'porting' effort to get with the program as it were.
"Shipping" was getting something running in production without having it be kicked out by SRE [3]. "Finishing" was having everything that was affected by the change that had been in production before shipping fixed and/or updated to run with the new system. As with most large systems I've had exposure too there is a big chunk of obvious stuff that is affected and then it asymptotically approaches zero. People seemed to start leaving at the 3dB [4] point.
[1] "pushing" is the process whereby a new capability is delivered into the production clusters that are customer facing.
[2] "technical debt" is the requirement that additional work is going to be required later (the debt) to resolve issues that aren't show stoppers initially.
[3] SRE see "The Roads must Roll" by Robert Heinlen.
[4] "3dB" is 3 decibels. In engineering or control systems the 3dB point is where the signal has been reduced in strength by 1/2. Also known as the 'cutoff' point for a filter.
There are no project managers. The closest thing Valve has to them are nothing but glorified receptionists. There is no-one who can do the decision to not accept a team member.
If you flood into a project that is already overstaffed, you'd be hard pressed to find any actual work to do. Which means that you're not producing much, if any, value visible to your co-workers, and those are exactly the people who will be evaluating you.
One thing to consider is that the teams may not be totally ordered by "buzz". So everybody won't naturally gravitate towards the team with the most "buzz" because no team has the most "buzz"! There are also other factors: everyone has different preferences and teams are interesting not just based on what they do but on how they do it and on the people comprising them.
There is, of course, a decent amount of grunt work. However, a lot of programmers don't just enjoy programming as such but also enjoy making something cool. I know I'm certainly willing to spend time ironing out the bugs in my hobby projects because having something that works well is just as fun as writing something novel. Also, I suspect that everyone at Valve puts effort into minimizing the grunt work as much as possible, meaning they probably have far less really boring things to do than most other companies. So a bit of cleverness and forethought combined with a passion of creating something of quality can get good programmers to do the grunt work.
> Also, I suspect that everyone at Valve puts effort into minimizing the grunt work as much as possible, meaning they probably have far less really boring things to do than most other companies. So a bit of cleverness and forethought combined with a passion of creating something of quality can get good programmers to do the grunt work.
This is a big difference between big and small organizations. People will sit in a big org chart and do the same maintenance code-monkeying for a paycheck, but people on small passionate teams have the freedom and motivation to automate their way out of mindless code-monkeying.
1) Moving between Valve projects may be like a "market" where the "buzz" around a project is like its "price"... but then the analogy breaks down, because in a real market, you'd have to pay to be on the hot team.
But at Valve you don't, so in this case, why doesn't everyone just drop their project and move to the hottest, most interesting team? Obviously in real life not everyone will, but if a team only needs 5 people, and 50 people want to join, who determines who really joins? Well, the project manager will have to choose, and now we're just back to managers choosing. Or am I missing something?
2) There's a lot of grunt work in software development. Bugfixes to maintain a year-old product, writing documentation, etc. If nobody wants to do the grunt work, then who does it? Because there's usually more grunt work than people who want to do it. Everyone wants to work on the new exciting sexy stuff, but that's not always what generates revenue and pays people's salaries.