I recently saw a nice chart on Kathy Sierra's blog depicting the user's hierarchy of needs. What immediately struck me was the different aim points that different types of organisations shoot for, and the level of satisfaction that team members get from being exposed to projects which exhibit these various aim points.
Before we go much further lets take a look at the diagram.
Along the left hand side are my annotations to the original diagram which indicate some "aim points" relative the to needs scale given in the centre column that I've observed amongst various organisations I've worked for over the years. Now, sure, there are going to be some gross generalisations here but bear with me and you'll see the big picture I'm getting to.
Starting at the very bottom, consultancy type organisations, or businesses building internal line-of-business applications are not trying to create show-stopper software. They are trying to meet a need at minimal cost. That need is usually manifest in a specification or briefing document and the main emphasis of the team is to give the client this functionality - no more and no less - whilst trying to keep budget under control. Programmers who DON'T want to become rock stars by going above-and-beyond enjoy this kind of work, and project managers should staff their teams with such programmers. Technical geniuses are wasting their times on such projects and will be out of there faster than you can say "internet job board". Good things for management to focus on during interviews are adherence to deadlines since the scope has already been mandated more or less.
A little further up the scale we have organisations selling the software / service they create, labelled here as "shrink wrapped" despite the fact that most software is downloaded these days. Such organisations are more focused on the quality of their offerings as it has a direct impact on their business profitabilty. Often these organisations have multiple product offerings and can take a broadshot or portfolio-based approach to product management where the more successful products subsidise the not-so-successful products in the portfolio.
In order to differentiate their products from those of their competitors and attract a user-base, the software produced needs to be considerably better than average. That entails more emphasis on usability and internal product efficiency. You'll find all manner of programmers in these projects as they require a mix of people who really care and those that prefer to get the job done with minimial fuss. Regrettably, what most of these organisations fail to recognize is the economic benefits achievable by realising the negligible marginal costs associated with quality improvements. That is, the additional cost by doing extra work to improve the quality of the product can be apportioned over the entire user-base since the cost of duplicating software is effectively zero, hence the marginal cost of that quality improvements is negligible.
At the furtherest extreme of the chart we have the must-win software projects. In these cases the organisation is usually solely devoted to, and completely dependent on a sole product offering. Internet startups are the classic case of this hence I've labelled this aim point as such. Since the survival, not just the success, of the firm is entirely dependent on the product/service being developed it has no choice but to be best-of-breed, or pitched at a price point compelling enough to move customers from incumbent products to your own. This is not an easy thing to do and the failure rates of such companies are usually very high because of this. If you are heading in this direction you need rock-star programmers. A group of mediocre programmers will, more than likely, not care enough to pursue the levels of technical excellence and user harmony you need to shoot for, and most definitely will lack the ability to, as Joel Spolsky elegantly put it, "hit the high notes" ! Technical teams working on these projects will often be doing very innovative things technically and will be paying particular attention to what it's early adopters and existing users are telling it about the product.
So at the end of the day what does all this mean? Well, technical managers need to be realistic about what their aim points is - some simple economics helps - and staff their projects accordingly. On the flip side, developers should, based on their own personal ambitions, seek out the types of projects that have aims aligned with their personal goals. If there is a mismatch then job satisfaction is guaranteed to be unacceptably low. Some folks refer to this as "cultural fit" but I'd just say it's good management and common sense.