Technical Project Managers - Get Out Of The Way
From the pmStudent Blog
by Josh Nankivel
Ranting and raving about project management and systems engineering.
Recent Posts
The Problem with Project Management
The Problem with Project Management
The Problem with Project Management
LinkedIn Recommendations Are Easy
The Catch-22 of Project Management Certification and Experience
Categories
Agile,
Career Development,
Certification,
Change Management,
Communications Management,
Cost Management,
Documentation,
Earned Value Management,
Education,
Integration and Test,
Kanban,
Leadership,
Lean,
Lessons Learned,
Methodology,
Misc,
Multitasking,
New Project,
Operations,
Planning,
PMP,
Productivity,
Professional Development,
Project Estimation,
Project Leadership,
Quality,
Requirements Management,
Risk Management,
Schedule Management,
Scope Management,
Software,
Systems Thinking,
Tools,
Video,
Work Breakdown Structures (WBS)
Date
I've been guilty in the past of transitioning from a technical lead role into project management and continuing to make technical decisions that should have been the responsibility of the new lead who replaced me.
I did this for about 6 months without even realizing it. People on the team were used to coming to me for advice and decisions on technical aspects of the projects, so they kept doing so even after the transition.
We all want to be helpful, so I continued to answer their questions and provide technical leadership.
I only directed people to the technical lead sporadically...if I was confident about my position on the matter, I just answered the question.
Signs of Trouble
Then I noticed my technical lead wasn't really doing all the things a technical lead should do...at first I thought perhaps they weren't 'stepping up' as much as they should to lead the team from a technical perspective.
Then I realized it was ME who was crippling their ability to be a leader on the project.
After that, when people would come to me for technical input, I would direct them to the lead to ask their advice. Rather than make decisions about implementation details, I would defer to them.
Let me tell you, the difference is tremendous.
A Technical Foundation Is Important
I still firmly believe that every effective project manager must have a foundation of knowledge and experience in the domain they are managing.
But when you empower your team (leads and all your team members) to take responsibility for most of the technical design and architecture, it makes everyone feel better about their job and frees you up to focus on strategic aspects of managing projects well.
Right and Wrong Approaches
Furthermore, you and your technical lead may have a different opinion about the "right" way to implement something.
Sometimes it's not a choice between "right" and "wrong" though, just two or more different possibilities that have their own pros and cons.
If you as the project manager take the decision making power away from your lead and team members, you risk undermining them for no good reason.
Even if you prefer option A, it's likely that option B is just as good.
I'd rather let the team choose their own path as much as possible and only intervene when I have compelling reasons to believe one approach is far superior to the other.
Get Strategic - It's Your Job
Sometimes as the project manager you can spot dependencies and additional risks that one approach will create that your team members don't see.
Things like code maintenance and other product life cycle considerations may not be at the forefront of your team member's minds as they do their day-to-day work, but as the project manager that is part of your responsibility.
Empowering Leadership From Your Team Members
Even in that case, whenever possible I like to educate the team about the risks I see and let them still make their own decision after getting all the facts.
People who are actively involved with making decisions about the work they do have higher job satisfaction, are more productive, and a pleasure to work with.
Share your experiences and thoughts in the comments.
Technical Project Managers - Get Out Of The Way! <-- Click to Tweet This
Posted on: June 22, 2012 11:30 AM |
Permalink
Comments (12)
Please login or join to subscribe to this item
Vincent Fong
Program Consultant| WorkAware
Sydney, Nsw, Australia
Cannot agree more. I just had a disconcerting moment when my operational SME's waited a whole night for me to request enterprise DBA support to remedy something as simple as re-establishing a database link between two databases. Needless to say I responded and made the request. However, having done so, I replied to my SME's letting them know that they have always had the authority to make the request in the interest of project expedience.
One SME replied that she waited because the originating communication wasn't directed to her hence she requested me to do it, assuming my "authority" as PM would make a difference. This is one of those fallacy moments when your project team presumes project management authority without realising that subject matter expertise easily strips any PM authority when it comes the matter of expedience.
When will people learn that PM's are not guard masters and that we are there simply to execute the authority of our executives and more importantly that we rely on collaborations with SME's who must also at times be able and willing to prosecute their own authority.
Shoaib Ahmed
Program Manager| Eagle Technology Group
Wellington, New Zealand
Cannot agree more. Good summary. Very similar to mine. http://prince2msp.com/2011/07/17/do-project-managers-need-technical-background/
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Thank you Shoaib and Vincent.
That's a great point Vincent, many times we have to educate our teams this way because the company culture or their past project managers give them the impression that all authority lies with the project manager.
This is unhealthy and disempowering. I really liked your example, it illustrates the problem clearly.
Andrew Brown
Project Manager| eTelligent Group
Springfield, Va, United States
This is good advice, not only as a wake up call to former technical leads who find themselves in a PM position, yet undermine the team's effectiveness by refusing to give up old responsibilities; but also to the non-technical PM who self-indoctrinates by reading a few articles or takes a class or two in order to give them the "cred" to justify their micro-managerial tendencies. They are out there, and should be called out, even if it means calling out yourself and your own management style.
Sure, domain knowledge is key to being an effective Project Manager in any given field. But those who want to "dabble" in the dirt of the technician, and then want to use this as a justifiable excuse to "help" the development team, must remember that it is usually an unconscious (or conscious) attempt at self-aggrandizement, command and control, or egocentric commandeering of team success; which ultimately leads to the team pathology alluded to above, e.g. lack of initiative, lack pride in the work, etc.
As the principles of the Agile Manifesto and the The Declaration of Interdependence for Modern Management both allude to, it is the empowered team, sense of ownership, trust in the individual, and a supportive environment that unleashes creativity and innovation.
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Couldn't agree more Andrew.
It may be a little different if you have some technical responsibilities too (I have some implementation responsibilities now along with my team mates).
However, I think the key roles of the project manager involves facilitating the communication, processes with which the team works, and removing obstacles wherever possible.
The technical background gives you a foundation upon which to base your activities as a project manager, not a foundation for taking implementation decisions away from the team and trying to exert control.
I think control is actually an illusion - most people who seek it and think they have it really dont; they are just putting roadblocks up in front of their team and they perceive that as control.
Andrew Brown
Project Manager| eTelligent Group
Springfield, Va, United States
You sound like a committed Agilist, Josh. :)
I was recently on a discussion board that surveyed and discussed what expertise a project manager should have. The highest rated answer was "The ability to integrate (all of) the above (areas of expertise)" ... which seems to me a loaded choice, since the ability to integrate is part and parcel of a Project Manager''s skillset. Kind of like choosing "the ability to manage" as the best choice from a list of what a manager should be able to do.
That said, of the selections given, the single choice of "mainly technical expertise" rated the lowest in this discussion - significantly lower than "mainly organizational" and "mainly interpersonal" expertise.
This was a general project management discussion group, and not Agile-specific; so I wonder if, barring any obvious "best answer", technical expertise would be rated higher by a group of Agilists.
I think that since Agile principles have been traditionally followed in IT environments, perhaps projects that never depended on functional management for anything other than securing a contract, the evolution of the APM was founded on the re-definition of "technical lead". That is, someone who, by default, had techical expertise (a senior developer or technical lead), became recast as a Project Manager - of sorts. You seem to have a similar view as I do, and see the APM role less in functional terms, but more as just another member of the development team; only charged with the extra responsibility of being a facilitator.
However, in the big picture, I see APM evolving ever further, and eventually becoming indistinguishably amalgamated with traditional Project Management processes and responsibilities; redefining roles like XP Coach and ScrumMaster in terms of a truly cross-domain, comprehensive and integrated Agile Project Management Body of Knowledge; and eventually superseding "traditional" Project Management altogether.
The growing pains with this sometimes difficult, but inevitable and necessary approach (in my opinion), is that we find the traditional Project Manager seeking to become more knowledgeable of the technical side in order to better faciliate and communicate; but still retain the command and control, directive-oriented disposition, so that the chimerical sense of predictability, certainty and control can be maintained.
This is where we discover the kink in the wire - to be truly Agile is to embrace change, not futily strive for complete control. As one of the priciples of the Agile Manifesto states, "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." This is something that the evolving APM should remember!
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Very well put Andrew.
I''d actually bet some of the things I value most highly in a project manager weren''t even on there... attributes like empathy, ability to facilitate diverse groups of people, and think strategically.
I''m actually delving deeply into lean architecture now, because I have been shifting the culture at my organization over the last few years and hope to make a larger shift soon. But what people don''t often realize is that in order for this to work, you can''t just slap a management methodology or whatever on top of what you''ve already got.
No, I''ve got to win the hearts and minds of management, stakeholders, and team members in order to convince them to change our paradigm. I''ve already identified that an overhaul of how we approach software architecture is necessary, because trying to slap any lean/agile process on what we currently have just isn''t going to work out very well.
My point is, a project manager with no clue about the product wouldn''t see this at all. And I don''t want to force people to my way of thinking here, rather I want to engage all of the technical leads and users to leverage their ideas and skills to bring this about. I have to think strategically and this takes some technical know-how, combined with management skills and leadership ability.
Josh Nankivel,
pmStudent.com
Naomi Caietti
Senior Project Manager | ePMO | Higher Education | Healthcare & IT| Linkedin.com/In/NaomiCaietti
Ultimately, it will be your new role to lead, follow or get out of the way.
Transitioning from a technical lead to a Project Manager is challenging. It's a shift in your personal leadership skillsets and it may take some time for you and your team to adjust to. In many cases, your team will see you first as the technical expert and not the PM. It will be your role to coach and mentor them through this transition; be prepared for their resistance. Also, it's good to collaborate and partner with your superstar tech leads; your go to experts.
I'd also suggest you get a mentor to also assist and guide you through this transition. You may also wish to consider the type of projects you choose to get your feet wet operational, strategic, local, regional, global, Agile, Waterfall, etc.
It's hard not to want to roll up your sleeves to do the challenging techical work but your new great tools in your toolkit will be your listening, conflict, negotiation, emotional intelligence and leadership tools.
Thanks for the article.
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Thanks for your insights Naomi!
arlene trimble
Assistant IT Director| Local Government
Alamo, Ca, United States
My initial thoughts....
I agree. Being a Project Manager is more about people management. Being a Project Manager means leading, inspiring, and coaching the team members towards the successful completion of the project goal.
Wearing two hats (PM and Technical Lead) may be quite confusing for both the PM and the Team Members because there is really no clear line of sight on how issues are going to be communicated and addressed. Having two hats may also lead to conflict of interest as the PM who is the technical lead may inadvertently sway the project direction "towards" a more technical viewpoint not the customer/stakeholder viewpoint.
If there are available resources, there needs to be a succession planning so that there will be opportunity for promotion in the organization to become a Technical Lead. That way, the PM can focus on the collaborative and customer care aspect of project management.
Well, I disagree somewhat, and am going to use the typical "cop out" answer of "it depends". If the PM needs to get technical and wade into the details of the project, it''s probably not a good thing, but if that''s what it takes for the project to succeed, then that''s what''s required. After all, the responsibility for the project lies primarily with the PM. As I said, it''s probably not a good thing if the PM is working at low levels of detail (unless it was planned that way), and such are things that need to be related in project status reports, project postmortem reviews, and other such documentation as appropriate.
I''ve been in both positions. On one project, my boss, the Dir of Proj Mgmt, specifically told me to stay at a high level, stay out of the weeds, and let the staff work out the details. Of course I complied, but I did send some advice to the tech leads which they acknowledged. On another project, I was working for a consulting company, where project team members often wear many hats. While I was the PM, I was also the Data Architect and QA Manager (Test Case writer).
Like so many things in project management, there are no hard and fast rules. Almost everything "depends" on something(s) else. But the PM is ultimately responsible for the project.
Priya Patra
Delivery Director| Capgemini India Technology Services Ltd
Mumbai, India
Get Strategic - It's Your Job. Love this part. We should never forget the role we are supposed to play.
Please Login/Register to leave a comment.
|
"It is best to keep your mouth shut and be presumed ignorant than to open it and remove all doubt."
- Mark Twain
|
