Organizational Anti-Patterns

Found a great list of social pathologicals on wikipedia at http://en.wikipedia.org/wiki/Anti-pattern#Organizational_anti-patterns, I've reprinted the list below but the links are much more functional on the Wikipedia page.

• Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
• Cash cow: A profitable legacy product that often leads to complacency about new products
• Cost migration: Transfer of project expenses to a vulnerable department or business partner
• Crisis mode (a.k.a firefighting mode): Dealing with things only when they become a crisis, with the result that everything becomes a crisis
• Design by committee: The result of having many contributors to a design, but no unifying vision
• Escalation of commitment: Failing to revoke a decision when it proves wrong
• Management by neglect: Too much delegation
• Management by numbers: Paying excessive attention to quantitative management criteria, when these are non-essential or cost too much to acquire
• Management by perkele: Authoritarian style of management with no tolerance for dissent
• Management by wondering: Expecting a team to define their own objectives, and then wondering what they're doing
• Milk Monitor Promotion: A pseudo promotion (a better sounding title), with no additional responsibilities or pay increase, which is given as a quick and costless way to make the employee work harder.
• Moral hazard: Insulating a decision-maker from the consequences of his or her decision.
• Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure)
• Stovepipe: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
• Vendor lock-in: Making a system excessively dependent on an externally supplied component
• Violin string organization: A highly tuned and trimmed organization with no flexibility

• Death march: Everyone knows that the project is going to be a disaster - except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang")
• Smoke and mirrors: Demonstrating how unimplemented functions will appear
• Software bloat: Allowing successive versions of a system to demand ever more resources

• Cage match negotiator: When a manager uses a "victory at any cost" approach to management.
• Doppelganger: A manager or colleague who can be nice and easy to work with one moment, and then vicious and unreasonable the next.
• Fruitless hoops: The manager who requires endless (often meaningless) data before making a decision.
• Headless chicken: The manager who is always in a panic-stricken, fire-fighting mode.
• Leader not manager: The manager who is a good leader, but lacks in their administrative and managerial ability.
• Managerial cloning: The hiring and mentoring of managers to all act and work the same: identically to their bosses.
• Manager not leader: The manager who is proficient at their administrative and managerial duties, but lacks leadership ability.
• Mr. nice guy: The manager that strives to be everyone´s friend.
• Proletariat hero: The "everyman" worker who is held up as the ideal, but is really just a prop for management's increasing demands and lengthening production targets.
• Rising upstart: The potential stars who can't wait their time and want to forgo the requisite time to learn, mature and find their place.
• Seagull management (hit-and-run management): The manager flies in, makes a lot of noise, craps all over everything, then flies away.
• Three-headed knight: The indecisive manager.
• Ultimate weapon: Phenomena that are relied upon so much by their peers or organization that they become the conduit for all things.
• Yes man: The manager who will agree with everything the CEO says, but changes mind away from his presence.

• Napkin specification: The Functional/Technical specification is given to the Development team on a napkin (i.e., informally, and with insufficient detail) which is fundamentally equivalent to having no specification at all.
• Phony requirements: All requirements are communicated to the development teams in a rapid succession of netmeeting sessions or phone calls with no Functional/Technical specification or other supporting documentation.
• Retro-specification: To write the Technical/Functional specification after the project has already gone live.