Sunday, January 30, 2011

Aha Moment: Technical People need Project Managers by John Bauer

...even if they don’t want to admit it

Like it or not, technical people need project managers. Yet, ask the average software developer, systems integration engineer or infrastructure engineer about what their company needs more of role-wise and they will almost without a doubt say: “We need more X’s. I’m buried in work!” Feel free to replace “X” with whatever job title applies to whom you are questioning. Software developers indicate they need more developers because the product owners keep asking for more features faster than can be developed. Infrastructure engineers say they need more engineers on their team because they can’t keep up with the growing demand for more storage, more servers to host systems, etc. What you rarely hear is a technical person saying:


“What we really need is a stronger project manager who can work with the project sponsors to prioritize their requests for work so I can focus on the most important requests first as well as a project manager that can remove barriers and align peer resources more effectively and efficient to aid in completing that prioritized work.”

Yet, in an alarming number of instances, this is really what they need. If another technical person was added as a peer, sure, some additional work would get accomplished. Without the prioritization and structured sequencing a strong project manager could bring, my argument is the total output of 2 technical people is less than 1 technical person pared with a strong project manager in a medium to large organization. (I don’t have true small/startup company experience, thus I can’t honestly comment on how much output a project manager adds when the company itself is made up of only a few people.)

If you hang around with technical people, they tend to place perceived value of fellow employees based on their interpretation of those employees’ technical competency compared to their own. Software developers tend to rank others based on elegant code output and depth of demonstrated coding experience. Infrastructure engineers tend to rank others based on proven mastery of multiple vendor hardware and operating system platforms as well as the scope of technical career experiences and environments.

My aha moment in appreciating project management was when I experienced the incredible level of increased team output when a highly functioning technical team is paired with a strong project manager. A surprising outcome was the level of mutual respect that grew between these two almost divergent disciplines. Engineers previously commented: “What does that project manager do everyday besides sit in meetings and tell me to do stuff?” Now, teamed with a strong project manager focused on ensuring their project work was prioritized and sequenced based on their feedback, respect for project management grew. The project manager didn’t just look at the technical team as resources on his or her Gantt chart. The project manager saw value in having a stronger project plan and a higher degree of confidence on the dates by spending time with the technical team members to get into their heads and understand what is really takes for them to complete project deliverables.

The results of this effective teaming: true cross-discipline collaboration was witnessed and the results were impressive in both speedy quantity and high quality.



John Bauer (@jfbauer) is an experienced project solution delivery leader working in medium to large size companies that consume rather than produce technology, adjunct professor and is the author of “Midwest IT Survival.com” a blog focused on the lessons learned in leading technical teams focused on project delivery in such non-IT industries.





Want to help this blog? It's free! Just subscribe using one of the these links or buttons: email, news feed, Facebook or Twitter.




Posted by

8 comments:

Pam Stanton, The Project Whisperer said...

John, great post. As a relatively non-technical PM who has led highly technical teams, I can relate. When I was in consulting, sometimes clients would push back on the value of them being charged for a Project Manager-- they thought only the technical people were doing "real work." One of my best memories is of a particularly resistant client calling me about a month after I left one consulting firm, and he said "I owe you an apology. Now that you're gone, I can see how much you were doing." Apparently the technical team was falling apart without Mama Bear at the helm :)

Pam Stanton, The Project Whisperer

catfood said...

To a certain degree, a really good PM has to regard his or her technical team as a customer of sorts, not just a collection of "resources."

Sure, the PM's role is to use the technical team to accomplish business objectives. But it's also to create an environment where the tech team can do its best work. One feeds the other.

jfbauer said...

Pam,

Thanks for sharing your positive comments. When Luis asked me to consider an ah-ha moment in project management this past experience came immediately to mind. It was truly ah-ha for me when I was able to see a strong PM bring highly technical people together with such credibility as a non-technical person.

By the way, I did my best to secure that same PM on all future projects involving that same technical team. It was impressive to see people quickly self-organize for the new project work due to that shared credibility previously established.

jfbauer said...

Mark,

Thanks for stopping by and commenting. I like your reference to a technical team as a customer to a PM. If in turn, the technical team also perceives the PM as their customer it significantly helps to bridge the communication gap between those focusing on technical deliverables and those marching the greater project team towards the end goals.

Joel Bancroft-Connors, PMP said...

John, I can't agree enough with your words. Hogarth and I tackled this from the PM's perspective in our PMs are SME and I can say I've seen this work very effectively.
The Project Manager has to move slowly at first, as he's often got a higher ramp up to earn trust. Practice the 90 day rule and you are in good shape.

Again, great post!

jfbauer said...

Joel, thanks for stopping by and sharing your thoughts. Also, thanks for providing a link to your thought provoking post. Your ending quoted compliment "I hired you because you don't have twenty years of HDD baggage. I needed someone who would focus on the project." summed your argument nicely. The particular strong project manager I was referring to above fit your conclusion of someone with general not specific experience. Thus, there was the need for trust between project manager and engineer and vice versus. As I stated, once that trust was established, the combined productivity and measurable output was impressive.

YvesHanoulle said...

I only partly agree with your statement.
yes developers need somone who will priorities the work.

That part of the PM's function I call a Product Owner.

A real product owner should prioritize. And if developers work for multiple PO's then you should have someone forcing the different PO to agree on one priority.
You can call this a PM. I don't because a lot of people add more links to a PM function then just the prioritizing role.

jfbauer said...

Yves,

Thanks for stopping by and commenting on my guest post. I think I wasn't as clear as I should have been on articulating the PM versus PO role in prioritization. I definitely agree the PO's role is to determine the desired "business" priority of work for a project they may be directly sponsoring. I believe the PM adds significant value in ensuring each technical resource clearly knows the priority, sequence and desired delivery dates for their work.

The majority of my IT experience is in large, 1000+ person IT organizations. With matrix-ed teams and shared technology assets and interdependent services, cross product project resource mapping can get very challenging. A strong PM can more consistently deliver if they can secure top quality, scarce resources and sequence them against their highest priority tasks.

I hope that was a more thorough explanation of my thoughts around the PM versus PO roles and the value a PM can bring in a larger, matrix-ed IT organization.

BTW, I very much enjoy your blog and have it in my list of blogs to read regularly.