The eternal conflict of tech management.
How do you know how much authority to delegate?
In the book Peopleware, a doctrine for leading technical projects is laid out: hire great people, give them total authority over their project, remove obstacles to their success and hope for the best. Don't tell them how to do it. Don't let anyone else tell them how to do it. Just identify causes of bad morale and eliminate them.
Best practices specify courses of action that will give a project better results. Advocates of these practices and processes recommend that managers make their use mandatory. Sometimes they are right, for example, source code control is not optional. You must use it. Don't argue.
Do you see the conflict here? How can you give a project leader total authority over a project but at the same time specify that the whole thing be done using source code control and the Unified Process? How can the project leader give total ownership over some module to a developer but tell him he had better write use a 4GL and pair programming?
The answer is: require as little as possible, only the tried and true practices, and leave the rest alone.
I think that there is a close analogy here to the central problem of civil society. We want to live in freedom, unfettered by rules, but hard experience has taught mankind the importance of a few immutable laws: Don't murder. Don't steal. Etc. Thousands of years of often horrifying human experience have shown that trying to create a society that is all rules and no freedom (like a strict all-encompassing Methodology), or all freedom with no rules (like scoring a zero on the Joel Test) is ghastly folly. There must be freedom with respect for certain ancient laws of human interaction. Beyond that, most societies experiment with additional, less fundamental laws tailored to particular situations, much as we try out new practices in our work. Our field is still very new, so once in a while, we have the pleasure of seeing the birth of a canonical law. A best practice - having been used on countless projects to unmistakable advantage - is declared indispensable. Joel adds it to his Joel Test, and in ten years we reminisce about the chaotic bad old days when most projects didn't follow it.
If you are reading this site waiting for the final balance between imposing best practices and delegation, don't bother. There will never be a final One True Way answer, any more than there will someday be a perfect legal system. There are only a few universal rules, and a bunch of best practices that may or may not be useful for your project.
Joel has developed a such a following in large part, I think, because he has brought the Peopleware doctrine and indispensable best practices together and thrown them into an arena (the discussion groups) to poke at them (with his weblog postings) and watch them fight.
Tuesday, January 8, 2002
Your point is well taken here.
I still think that the value to be added in managing these projects is in objectively evaluating the results and suggesting opportunities for improvement. Think of it as "guidance" or "optimization" rather than management. The best resources need some direction, and even the best people are open to questions, suggestions, etc.
If the manager is not qualified to be a member of the development team this approach will not work. If the manager is qualified, then this approach can take a good team and make them even better in my experience.
Tuesday, January 8, 2002
> How do you know how much authority to delegate?
Delegate authority according to ability and desire.
Wednesday, January 9, 2002
Two points regarding the eternal conflict:
First of all, hire people that agree with you on the basics, i.e. if God the Programmer (your potential hire) tells you bug trackers are for sissys, and you believe that bug tracking is a good thing DO NOT HIRE HIM. While it is true that a manager should "stay out of the way, remove obstacles etc..." as much as possible probably the most crucial task for a manager is to hire people that can work together to get a project done!!!
So perhaps there is another item to joels hiring criteria- smart, gets things done, is "religiously" compatible
Second issue, and this has more to do with nitty gritty type stuff rather than broad religious issues this has to do with persuasion vs coercion. Going back to the bug tracker example: You hired 2 programmers who believe in bug trackers, now the battle is Track vs PVCS! If it really doesn't matter the good manager wont interfere. But if it does (and it usually does) the manager should try to convince rather than to order one course over the other- i.e. "I know PVCS supports feature X and Track does not, but all our bugs are in Track already..."
So, perhaps even more important than the "religious: compatibility factor, is the religious tolerance, i.e. I know we currently use VB, and Candidate X likes VB, but if we switch to Java will candidate X rebel? will he listen to reason on why we are switching to java? etc...
Tuesday, January 22, 2002
Fog Creek Home