Project Managers: Nurturing vs. Hiring
I’ve come across a very interesting discussion on LinkedIn recently. Someone posted it as a general, thought-provoking question, one of those complex questions that have no finite answers. As it often goes, such discussions receive many comments, and the question was: why are engineers good project managers? Yeah, I know how many thoughts, memories, and personal experiences whirled in your mind at this very moment :) I’ve been there, too, as the more accurate way of formulating this question would be: why *some” engineers make good project managers and *some* don’t?
In this short post, though, I’d like to focus on just one aspect. When you need project managers (or feature owners, as was the case with us) which option is preferable: to nurture them inside your organization, or to headhunt the superstars who have spent most of their professional lifetime at other companies? It depends on your company culture. If acquiring new employees is the domain of recruiters solely, then all you can do is submit a job opening to your HR department, and let them bring in the superstar candidates, luring them by high salaries, compensation benefits, etc. Usually, such job openings are posted on vacancy sites, and come with a lengthy list of technical responsibilities that a desired candidate is supposed to fulfill. It’s largely one and the same list of technical tasks, and quite often communication skills, or people skills, are mentioned only as a plus. A nice-to-have icing on a cake, sort of.
Now, consider this. How often a project or a release blows up due to the lack of technical expertise, and how often does this happen due to the lack of people skills? By people skills I mean anything related to sifting the individual’s technical competence through the grid of this particular business and company environment, in a broad sense. The challenging part about hiring someone from outside is that you never know how this person will perform in the trenches with your other folks, and how will they be able to transmit the common accumulated wisdom of your whole team to the feature or project they’re responsible for. You don’t know what this person is like, and there’s no way you can get to know him or her well enough from their CV. The trial period is of little help either. By the end of the trial period one just starts to merge into the company culture, and all seems to be going well, and you’re so eager to write filling in this vacancy off of your to-do list, thinking that everything is fine. But you cannot be sure as of how the real *people* skills of this person will manifest themselves later, at a challenging moment.
The approach that worked for us, in an agile company environment, as we needed more feature owners, was simple. First off, we called for the volunteers who felt they were apt for this work and who were ready to commit to the responsibilities of owning a feature in TargetProcess. This was the crucial first qualifying round. It must be something that a person wants to do, and be confident enough to stand up and say: yes, I can, I’m taking on this responsibility, and I’m committing to it. The next step for a CEO (or for a master product owner) would be to observe how the aspiring feature owner is actually doing about those very *feature owner* responsibilities. Given that the technical expertise of those people has already been proven in their previous work as developers or QA, and their people skills have also been tested as they’ve been a part of our team for quite a while, and their intrinsic knowledge of the product is in place, all that needed to be verified at that point was their confidence in driving the feature development and their ability to hold the steering wheel firmly.
With nurturing, the rule of a thumb is this: if you’re lucky enough to have aspiring people in your team, let them try to pursue project management. If it works — great, if no — this is less risky anyway than trusting an unverified newcomer with your projects.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)