Engineering an ineffective team

It's unfortunately far to easy to engineer an ineffective software development team. How about these ways to start with...?

• Create an awful working environment... and prevent the team from changing it. (Don't know how to create an awful workspace? Use this handy list. You could make it: too hot, too cramped, too isolated from the team's customers, too loud, too dark, too busy, too rundown - preferably with furniture that is uneven, unsteady or falling apart, too obstructed by partitions and cubicles, lacking whiteboards, lacking shared space, or lacking necessary software / hardware / connectivity...)
• Give the team conflicting goals... and be adamant that you require all of them to be met
• Set meaningless deadlines... like slicing 30% off all the team's estimates "to set stretch targets"... and hold the team to those deadlines, no matter what happens in the meantime
• Or set a meaningful deadline... but make the team agree to complete more work before the deadline than they believe is possible
• Get upset if you ever see developers not "hard at work" (i.e. hunched over their keyboards)... especially if they're "wasting time" by talking to one another
• Track the effort spent by individual team members on each development task... and reward those who spend the least time on "their" tasks... regardless of the quality of the work they produce
• Ostracise members of the team who don't want to spend their weekends working to fix bugs... that they knew 6 weeks ago would be the result of the corners cut "because we don't have time to do it right this time"
• Insist that the team's software must conform with common architectural standards and guidelines... without allowing the team to discuss their ideas with any of the people who drew up the standards and guidelines
• Stick rigidly to the original plan of action that was drawn up when the project was conceived... no matter how much the business or technical environment alters. (You may of course revise the plan at any stage if the political environment alters.)
• Never - EVER - tell the team that they are doing a good job... instead keep them motivated by fear: the fear that they will be late, that they are useless because they are going to be late, and that they will lose their jobs because they are going to be late
• Persuade the team that they have no need to talk to anyone who will ever actually use the software they are creating (or in fact to talk to anyone who understands the business drivers behind the software project)... instead give them a pile of documentation to read (preferably written by another team that has since been disbanded)
• Perform all testing after the "development complete" milestone date... even if that milestone slips and the duration of "allowed testing time" is squeezed... Certainly don't provide any functional test data until after "development complete"
• Don't allow testers and developers to talk to each other to reach a common understanding of the customer's needs... and reward testers for the number of "defects" they raise, even if those defects are in fact just misunderstandings
• Leave all users out of any workshops, walk-throughs, or testing before the "user acceptance phase"... and then allow all their concerns to be raised as "critical defects" without effective prioritisation
• Ignore any arguments in favour of "non-standard" hardware or software... or "non-standard" programming languages... even if they might save time or money
• Make sure that the "framework" required by the application is completed before development of the application starts... and have the framework be developed or architected by people outside the application team

This is a deliberately contrarian response to Laurent Bossavit's original post on engineering effective teams. But it was fun to write it :-)