10,000 Foot Developer

I’ve been re-reading the classic Mythical Man Month and working on a new team with a PM inexperienced in my field and have come up with some compelling observations about how things have changed since the first iteration of MMM had been written in 1975 — some 36 years ago.

The most obvious is that back then PMs were domain experts.   They had been programmers and were explicitly involved in more of the technical decisions.  If you look at the structure suggested in MMM there’s a definite hierarchy that puts the PM, most of the time, at the very top and the Technical director, most of the time, below.  And back then most PM’s, having been technical, could do that.  They could understand, share, or drive the technical vision.

Things have changed a bit.   Just from the mid 1990’s the certification for a PM has went from a simple “come in and take a class” to  needing 3-5 years of proven pre-experience just to get the certification!  Depending on the cert.   Technical schools offer project management career tracks.  What this all points to is PMship as a profession, not a career level in a technical path (although it could be).

PMship as a profession means that you never have to have been technical to do it.  Its a separation of concerns.  On large projects especially its a full time job to develop the PM artifacts of missions statements, sla’s, schedules, communications plans etc.   It takes a lot of time. Professional PMs are better at PM-ing, although at a cost of technical savvy.   The industry has decided this trade off is OK, or there wouldn’t be these types of PMs.

I have worked with a lot of these new types of PMs and found them effective once they realize that they are accountable for their own work , and driving the schedule/communication gives them the management tools they need to drive a project.  There is dissonance created too.  Non-technical PM’s sometimes use their organizational weight to dictate  design or prevent necessary technical activities like re factoring or proper testing.   It puts the technical teams’ credibility and accountability in jeapordy.  Nothing drives me more crazy than a PM that has never been a developer (something I see a lot of now) thinking they can dictate tech actions from derivative experience.  As a tech leader I will advise them of estimates and outcomes; but just as they get to consider (only) my advice for PM issues, so too I have to consider (only) their input for technical issues.  The big thing here too is that my sniffer is on for “heads you win, tails you lose” situations.  This is where people are put into situations where they have no control or input (like design decisions or scheduling) yet are held accountable for the outcome of bad decisions up on the chain.  A good project structure can help insure this never happens — thus avoiding project failure, or unhappy and migrating team members.

How can we work through this?  We have to all learn that things these days are done in parallel.  We all don’t have the same skills and have to trust each other.   And leadership isn’t appointed, its earned.  Management IS appointed though, and management is as much about service to the team as anything else.

What I do on a new team is drive the accountability artifacts until its where I want them.   For instance, if there is no schedule, then I make estimates, and give it to the team.  The PM can then take it as a starting point.  Any of the artifacts, we can all do that — just turn them over.  If I am missing a critical state chart and someone cranks one out then by all means let’s use it.  Let’s put it in the Wiki or document storage; we are getting paid to make software not compete with one-another.  Once these tools (wikis, bug trackers, documents) are in place its amazing how the roles fall into place as well.