As I was sitting here this morning a link was IM’d by my coworker
Darin, one to a discussion called Rule
Number Four: Great People Can Manage Themselves from Joel on
Software. This discussion comes from the fact that Google more or
less lets developers manage themselves. My take on this is right in
the center of opinions of what has been expressed on their thus far. I
think the best way to manage developers is this: you clearly specify
everything you care about (the software must do this, must work on
these platforms, must use these libraries that we have already paid to
license, must be ready by this date, whatever.) Every single thing you
don’t specify, you don’t care about. Once you’ve told them what you
need, they do it and how they do it is not really your concern. It is
true that you can’t do this with undisciplined slackass bastards, so
the best way to deal with that is to not hire them or to fire them
once you realize they can’t work this way.

If the product is structured this way and you get something back you
didn’t like it comes down to one of two cases: did it meet what you
asked for or not? If the latter, the engineering team failed you and
you deal with that thusly. If the former, it is your fault for not
asking for what you wanted. I call that a “Requirement/spec bug.” It’s
really unreasonable to expect to get back products that meet
specifications that one is too fucking lazy or too fucking incompetent
to express to anyone, but I see it happen every day. This
unreasonability is never realized as a failing of management but
always interpreted as a failure of engineering. In the cases where I
have been on teams given clear requirements and cut loose, we have
always turned out better product faster than when we are
micromanaged. In the first case, we are on board and our goal is to
achieve, in the second everything is fiat and our goal is to game the
system to give the minimum that meets what weird input we get. Which
case do you want your developers (ie, and your money) going towards?