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.<\/p>\n
The most obvious is that back then PMs were domain experts.\u00a0\u00a0 They had been programmers and were explicitly involved in more of the technical decisions.\u00a0 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.\u00a0 And back then most PM’s, having been technical, could do that.\u00a0 They could understand, share, or drive the technical vision.<\/p>\n
Things have changed a bit.\u00a0\u00a0 Just from the mid 1990’s the certification for a PM has went from a simple “come in and take a class” to\u00a0 needing 3-5 years of proven pre-experience just to get the certification!\u00a0 Depending on the cert.\u00a0\u00a0 Technical schools offer project management career tracks.\u00a0 What this all points to is PMship as a profession, not a career level in a technical path (although it could be).<\/p>\n
PMship as a profession means that you never have to have been technical to do it.\u00a0 Its a separation of concerns.\u00a0 On large projects especially its a full time job to develop the PM artifacts of missions statements, sla’s, schedules, communications plans etc.\u00a0\u00a0 It takes a lot of time. Professional PMs are better at PM-ing, although at a cost of technical savvy.\u00a0\u00a0 The industry has decided this trade off is OK, or there wouldn’t be these types of PMs.<\/p>\n
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.\u00a0 There is dissonance created too.\u00a0 Non-technical PM’s sometimes use their organizational weight to dictate\u00a0 design or prevent necessary technical activities like re factoring or proper testing.\u00a0\u00a0 It puts the technical teams’ credibility and accountability in jeapordy.\u00a0 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.\u00a0 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.\u00a0 The big thing here too is that my sniffer is on for “heads you win, tails you lose” situations.\u00a0 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.\u00a0 A good project structure can help insure this never happens — thus avoiding project failure, or unhappy and migrating team members.<\/p>\n
How can we work through this?\u00a0 We have to all learn that things these days are done in parallel.\u00a0 We all don’t have the same skills and have to trust each other.\u00a0\u00a0 And leadership isn’t appointed, its earned.\u00a0 Management IS appointed though, and management is as much about service to the team as anything else.<\/p>\n
What I do on a new team is drive the accountability artifacts until its where I want them.\u00a0\u00a0 For instance, if there is no schedule, then I make estimates, and give it to the team.\u00a0 The PM can then take it as a starting point.\u00a0 Any of the artifacts, we can all do that — just turn them over.\u00a0 If I am missing a critical state chart and someone cranks one out then by all means let’s use it.\u00a0 Let’s put it in the Wiki or document storage; we are getting paid to make software not compete with one-another.\u00a0 Once these tools (wikis, bug trackers, documents) are in place its amazing how the roles fall into place as well.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/279"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=279"}],"version-history":[{"count":4,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/279\/revisions"}],"predecessor-version":[{"id":282,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/279\/revisions\/282"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=279"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=279"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=279"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}