Project Practitioners > Input Requested.......

Input Requested.......

By Margaret de Haan

I, as many of us are, am currently looking for a new full-time opportunity - a new long-term position where I can hang my hat. As I go through the motions of reviewing job-descriptions and requirements I have noticed two very different trains of thought on hiring Software Development Project Managers, the "business track" and the "technical track". For those of us that have been responsible for hiring additional Project Management peers, these different skill set requirements seem very strange to be placing as requirements for any true Project Management role. So, as I always do when I don't understand something, I'm going to ask the question…..if I am to manage a software development Project, why does it matter if I can produce code or not?

In the technical camp there are those that appear to want numerous years working in a "Cold Fusion" environment, or having had "10 years of programming experience", and I have to ask, what is the wisdom behind this request? I would think that if you have a strong development team, that knowing how to actually code encourages an environment of micro-management on the part of the PM and is going to get in the way of progress. Now, this is obviously assuming that your company is large enough to have defined roles between Business Analysts, PMs, QA and Development, but if each role is defined and there is a delineation of responsibilities why is this important? I, as many of us have, have been in roles that require us to jump in and help with testing, requirements gathering, even janitorial duties if that's what it takes to get the Project back on schedule, but as a primary requirement in a large company with a PM that is managing the Scope, Budget and Schedule? I must be missing something.

When I have hired I have focused on a few specifics to make sure that I get a great fit. The first is the company culture if I am in a very fast-paced environment and I meet someone who is very low energy, well, bad fit. Obviously the majority of the team is going to have to be able to get along with this new team member (I say majority because we all know that it gets hard to get consensus if you have a lot of people in the mix) so their input is important. As well it helps that they have a drive towards results and can manage themselves under pressure, and that they aren't "rutted" (a term I use to describe technical stagnation, someone that hasn't kept up with learning and is just biding their time hoping that they don't have to learn anything new). You want a past PM role (preferably a PMP) with proven results and someone that is a good communicator, committed to keeping the customers happy (as much as possible), and someone that is confident with great detail orientation. So is coming up through the technical ranks of QA or programming really required? Even methodologies vary between organizations with one having an "Agile" environment that is nothing more than short timelines on Waterfall and others with a full ScrumMaster role. Every company has different processes for documentation, different rules for escalation, etc., so there is always a ramp up period of assimilation for anyone coming into the organization, right? In my experience we all have the ability to understand something technical without having to have done it, OK it is easier if you have actually done it yourself, but if you do the research to understand it, you have enough insight to make good decisions.

In my world there are very different personalities that gravitate towards coding versus those that manage processes and people, and many times they aren't interchangable. I see it in many cases akin to having a tree trimmer performing brain surgery. So help me out people, what am I missing? Isn't a cultural and behavioral fit more important long-term?

Margaret de Haan

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Yes - I think so; however, the person must be able to perform the actual job functions. As a software development PM myself, I personally think the ideal person has a stronger business background. You can't accomplish business improvement without understanding business implications. I also think you need to have a sound understanding of concepts and what goes into a software or IT project. In order to properly manage, estimate and control you need to understand what makes up the project, what could go wrong, and other indicators of project health.

Ann, you have reiterated my point better than I think I did. I have always believed that being part of the team meant that to an extent we need to allow the team members to do their jobs. We can, obviously, learn about the perils and problems of IT projects without having to have been in the trenches, coding, and testing. I agree with your assessment totally. Thanks for your input.

Ms. De Haan,

Thank you for your article and thank you for asking the question that you have; it is relevant not only to the role of project management but also to the broader role of manager/leader. Throughout my career, I’ve worked in leadership capacities where I have been surrounded by a wide range of technical gurus. These are people who have been formally trained, intensively focused in the organization, and well developed through their experiences in a very specific area of knowledge. They are the experts, the engineers, accountants, estimators, product technicians, marketeers, contract administrators, and so on. While I am not an expert in any of these fields, I have always made it a priority to respect and understand their particular capabilities and skillsets as well as the importance of their role on the team.

History is full of examples where experts in a given field have risen to positions of leadership to take on responsibilities that go far beyond their own area of expertise. There are also examples where great and admired leaders have succeeded without having had any particular set of technical or functional skills. How, then, could any of these leaders succeeded if they were not expert in all of the finite functional and technical areas of the organization that were outside of their own area of professional expertise? The answer has everything to do with your point. Clearly, they knew enough about the importance and relevance of the various experts with whom they surrounded themselves and were committed to understanding how best to organize, orchestrate, guide, direct, channel and focus the individual and collective capabilities of their team. In short, they were experts in the practice of leadership.

Project teams are excellent examples of cross-functional organizations that are comprised of a variety of functional and technical experts. Successful Project Management has much less to do with the ability to perform any of the specific technical or functional skills that the team members provide. Instead, it has very much to do with the ability to draw upon the right strengths at the right times and in the right manner to consistently achieve the larger goals of meeting the technical, cost, and schedule constraints of the project. Brava! I look forward to reading more of your work.


Thank you Karl. It nice to see that at least in this instance, I'm not on the wrong track!

I too see these sorts of limiting job descriptions all of the time. Unfortunately not all hiring managers know what success looks like, so instead of seeking out key personality traits and aptitudes, like you were so able to do, they end up with long laundry lists of qualifications. It serves neither the employers nor the candidates, but in the end I think the loss is the employers.

From a job search perspective, I typically avoid such jobs altogether. Even though I know I am probably qualified, it doesn't make sense to invest effort in trying to change the perception I'm not. So I focus my efforts on job descriptions that make good sense and fit my qualifications.


Margaret, you touched a very interesting subject, so I decided to pull an expert, who has WAY more experience.
He had a lot of great things to say, ("Just like a doctor, even if you have your MD, I’m not going to let you touch me unless I know you have the experience to back it up..." so I decided to post it on our blog, and hopefully spark more discussion!

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.