Tactical Leadership : Weblog

Tuesday Dec 12, 2006

A field handbook for engineering project leaders

For years I've wanted to write a book on project leadership. Not one of those lofty, written for CEOs by ghost writers, with lots of inspirational cheerleading and little practical substance. When I was a young engineering project leader, what I really needed was a reference manual for leading projects, a field handbook so to speak. I've accumulated tons of notes over the last two decades, and an outline, but I've never had the time to sit down and start writing. And of course, in the words of E.L. Doctorow:

Planning to write is not writing. Outlining, researching, talking to people about what you're doing, none of that is writing. Writing is writing.

So clearly the way to start writing is to start writing, and a blog is a way of converting my notes and thoughts into semi-cogent prose, giving the world an opportunity to review and critique my work as it is written; editors willing to work for free. So please follow along, and let me know what you think.

Posted at 09:49PM Dec 12, 2006 by Robert Hueston in Sun | Comments[1]

Comments:

Bob, This is a great idea and I hope you can find the time to write the book. Is this going to be focused on project leadership at Sun in particular (targeting Sun employees) or is it intended to be more general for engineers at any (large?) company? Some obvious topics that come to mind (I admit this may have a hardware bias to it, since that's where I live) ... - how to keep geographically dispersed team focused - brainstorming - how to do it, how not to do it. how to involve all members of geographically dispersed team, how do you know when you're done, etc. - how to quickly ramp up new members of team (at all points in project, especially at the point when most are heads-down writing code, etc.) - controlling feature-creep and RFEs; process for approving RFEs - dealing with conflicting requirements (in hardware design, for example, it's sometimes RAS vs. performance) - writing specs - what makes a good spec., common mistakes, the lifecycle of a spec. - when is it "safe" to begin implementation (coding) - consequences of starting too soon or too late; overlap of implementation phase with spec'ing and architecture definition phase - common pitfalls - architecture vs. implementation (especially as it pertains to specs.) - spec. and code reviews: do's and don'ts, especially for dispersed teams - dealing with dependencies on external groups (i.e. industry protocol working groups whose works affects project) - dealing with change in the midst of project (i.e. "redirection") - for example, switching to new bus technology when 50% of code is already written - mothballing a project (I was recently involved with an ASIC project that was canceled, then resurrected 4 months later) - post-mortems Incidently, I recently read _The_Pentium_Chronicles_ by Bob Colwell, who was the project manager and lead architect for the Pentium Pro processor (Intel's first processor in the Pentium II family) project. Intel and Sun have much different cultures of course, but I think the book has some general wisdom about principles of project management, leadership, etc. You might find it interesting and entertaining.

Posted by John Feehrer on December 13, 2006 at 08:19 AM EST #