Shouldn't being involved in an interesting project (e.g. Steam Client) mean you'd actually want to see it through to completion and iron out bugs, etc. - assuming the developers actually care about their work?
In practice, makers are different people from polishers, and Valve's system of hiring the "best" (people with impressive CVs) and salaries based on stack ranking means there is a huge bias towards makers (Who brought the company more money? the person who helped roll out dota2 or the person who fixed edge cases in the steam client?).
Many of Valve's products are full of bugs that don't get fixed for years. And since they only hire the "best", they don't have any testers. Many times patches are released that cause servers to crash within seconds (tf2 falling damage crash). And sometimes they release them on Friday which means it doesn't get fixed until Monday (Overflow error writing string table baseline crash). These patches were also mandatory.
What's missing is negative reinforcement. If not through a management hierarchy, some sort of Customer Pain Index is at least required. Every crash, every slow load, every extra click, every reported bug, every support call would push the index up.
Edit: though, to contradict myself, this is still as gameable as all hell if you do something silly like connecting it to reward and punishment.
I don't agree with this. Good developers realize that no work is beneath them. Getting things 'right' takes hard work and part of that work can be menial at times. Part of being a good engineer is understanding that completing a project is both glamorous and boring at times.
I never really thought about it this way. Nothing will probably ever stop Valve from being successful, but I do think they would be more successful if they contracted out half of their work (i.e. the boring/uncreative jobs).
They've already got a caste system, actually. If Valve hires you to do customer support, the only thing you can ever do at Valve is customer support. They don't allow sideways-promotion from their support department like many game companies do with QA/support staff because they don't want there to be a 'back door' into the company.
I began to write about Toyota and Admiral Rickover's "Nuclear Navy" cultures, but then stopped.
I'm not sure if cultures like Toyota or the Nuclear Navy can be considered under this heading, as they mostly worked at a procedural-improvement level, rather than a product-improvement level.
There are no bosses at Valve and they have a stack ranking system deciding how much money you make.
This means people there don't do unglamorous things like maintenance and stability fixes.
How to create an incentive for this kind of work is an interesting problem, and I don't know enough about Valve to know if they've solved it.
I will say that the alternative is more dysfunctional. Closed-allocation, corporate alternative: some number of people are staffed on the ugly, career-damaging maintenance projects. The good ones either find a way to play the politics and move, or they quit, the bad ones stay. The end result is that the maintenance work is done by incompetents who don't care. This is a big part of why most legacy code only gets worse over time: the maintenance work is given to people who don't have the clout to do anything else, not to people who care enough about the health of the project to do it well.
This means people there don't do unglamorous things like maintenance and stability fixes.