More evidence that prima donnas (and prima dons) don't help overall achievement

Bob Sutton points to more research about prima donnas, prima dons, and jerks-at-work:

Boris [Groysberg ] wrote me a pair of detailed notes about a series of case studies that he has done that track Lehman Brothers’ research department over a 20 year period. Boris reports that “the rule” [the no asshole rule] helped fuel the rise of the research department there, and then when it was abandoned, was linked to performance problems, and when it was reinstated, performance again improved.

It seems that while we love the myth of the brilliant-but-difficult star, the data doesn't support our belief. Of course, there are exceptions. There are cases where one brilliant person is the pivot point for corporate success. But mostly it's just bad behavior that supresses overall results.

Recognizing the Signs of Design Debt

Dave W. Smith has an interesting post on recognizing the cues that a product is garnering design debt.

all tied up in contracts

I keep running into companies that have set project up for failure by tying people up in contracts.

Here's how it "works":

An analyzst in the client organization writes requirements that are turned over to the vendor. The vendor interprets the requirements and then turns the requirements over to thier own developers. The developers write code.

A vendor representative communicates status to a client representative, who in turn, communciates status to various internal client groups, including the development team who is responsible for the product--and will recieve the vendor code.

When the code is "done," the vendor representative (not the developer or testers) turns the code over to an acceptance group in the client organization. Some wrangling happens here as the internal acceptance group says "It doesn't work" and the vendor representative says "The code passed all the tests specified in the contract." Back and forth, back and forth. Contract wins.

The acceptance group fixes up the code as best they can, then turns it over to development team working on the product. They try to integrate the code, and spend lots of time fixing errors. Much groaning ensues. Progress grinds to a crawl.

When it's clear that the client isn't getting the results they want, an executive demands that the internal people (who are tied up by the contract) "do a better job." Or the contract admistrators add more stipulations to the contract to try to force better performance.

How is this producing valuable results?

It's wonderful, I suppose, if you want to provide job security for the people who write and admisiter the contracts.

It's not producing valuable results for the company--and if you look beneath the surface, it's costing much more than those dry numbers on the contract show.

It's hell for the developers and testers involved--it robs them of pride in work and increase stress as all the external stakeholders demand better performance (while doing nothing to make better performance possible).

Collaboration is impossible under contracts like this. If there are any feedback loops, they are so long and so indirect that they are useless.

The answer is to work in partnership, put the developers and testers in contact with each other and with the customer. Work in short development cycles so that problems are found quickly and people can make adjustments to avoid those problems in the next iteration.

Mary Poppendieck's has some thoughts on different ways to do contracts here.