The Project Leader

Since the beginning of the year, I've been trying to distill some lessons from some of my failures on KnowledgeTree.  Part of this process has been doing a lot of reading about development - to make sure that I'm not seriously out of step with my underlying beliefs, and to see how I can improve on what I've done before.  Most of this reading, strangely enough, about project management.

I've reread the staples on the subject - The Mythical Man Month and Peopleware - with a deeper understanding and finding greater resonance in this reading - I assume due to increased experience.  And I've also read some more recent texts; the latest is Scott Berkun's The Art of Project Management, which Brad recommended.

This isn't a review of the book, but I feel I must say that this book is probably the most succinct instruction book on how to get a team to deliver a project, no matter what technologies they use or what development methodologies or business processes exist.

I like how Berkun starts by defining his use of "project manager" as being "whoever is involved in project leadership and management activity", and offers that some people might want to translate it as "person thinking about the project at large".

To me, it seems the project leader is the person who lives the project - the one who has the clearest idea of what the vision of the project is (and probably the goals), and who keeps this in mind in approaching every decision that is made.  The leader is the person who cares the most about the project, and who seems to make the most cogent arguments about the project as a whole ("Which feature should we drop?", "How do we best fulfil the spec in this case?", and so forth), and to whom these questions tend to become asked of first.

This person doesn't have to be a project manager or the "lead" developer.  It could be a designer, for example, who feels excited by the prospect of delivering something worthwhile to the users of the project.  This person instills this excitement and/or caring, in some small way, to the rest of the team, and provides a degree of reward (it feels nice to make someone happy in addition to just doing your job).

Excitement and attachment, though, have their downside.  If the de facto leader is restricted from providing such leadership (even if it is only a perceived restriction) by the de jure management (for example, a project or line manager), problems start to appear that are hard to diagnose.  Things that "just happened" stop "just happening".  It becomes harder to make decisions or reach concensus about the project.  Things that were decided are forgotten, arguments about previous decisions start up again, and so forth.  Mostly, morale goes down.

My current experiment is trying to understand who holds the de facto leadership power in situations, and to understand my own role in things in terms of non-granted (ie, earned instead of granted) power - both in the past and going forward.  Even if I'm not right about defining the "project leader", this exercise has had some interesting results so far.