I have 3 years of programming/development experience in mid-scale applications, and I do not have any project management experience. I'm thinking of taking the PMP as a stepping stone so that I can transit to a project manager role in my next job hop. Is 3 years of experience enough, or should I wait out to fortify my technical skillset first?
Currently holding a Bsc, and I'm 25 years old, if that matters.
To answer the question literally ("how much experience is required..."): none whatsoever. I know project managers who has had no technical experience and are dealing great with their jobs.
If you asked me whether I require technical experience when hiring, or working with, PMs, my answer would still be negative.
Having said that, technical experience in vast majority of cases is an advantage. Understanding what is happening under the hood definitely helps. Most good and great PMs I know have technical background.
So the real question is how much one should invest in building technical skills. Well, if the choice to transit to project management is made I would advise to make it as soon as possible. When you land in the new role, your new craft will be project management and not software development, so much of your current skill set will become irrelevant. It's much better to focus on project management skills as this will be you bread and butter soon.
You can be a decent PM without technical skills. You can't without project management skills.
Whether you are a traditional PM or an agile practitioner, project management is about managing process. Like any knowledge domain, the deeper your understanding of the underlying processes and procedures you're dealing with, the better you will be able to manage process flow and identify risks and impediments to your process.
With that in mind, you could theoretically manage a Mars mission with zero technical background, but having sufficient domain knowledge to understand the details within the project you're managing is more likely to lead to a successful outcome for the project.
If hire-ability is your key metric, then the only correct answer is "whatever the hiring manager needs to see on the resume to give you the job." If percentage of successful outcomes is your key metric, then you're asking the wrong question.
In my personal experience, a company that manages projects out of a PMO tends to favor process experience over technical experience. Most PMO-managed projects use non-technical PMs, so while they may not be indifferent to technical skills, it has never been a hard requirement for any company that I've worked for.
On the other hand, jobs that advertise for a "Technical Project Manager" or require technical leadership for a given project tend to look for process experience first, but often look for sufficient domain experience to ensure that the PM can lead the project on a technical level without having to defer all estimates to members of the team.
None of these differences are really formally defined. A good, non-technical PM won't take long to figure out whose six-week estimates for embiggening widgets are wildly off-base; it's just a process tracking issue. On the other hand, a strong technical leader may have a harder time determining why widget-embiggening takes two months to move from development to QA, because it may not be a technical issue at all.
Like much in life, and in project management in particular, it just depends. Technical skills are always valuable if they apply to your current problem domain, but they are not the key skills necessary for successfully shepherding processes.
I'm biased, because I have a developer background, and say that you'll need the technical skills in order to be a software project management. I'm not saying that you have to know the architecture and development environment better than anybody else from your team(s), but you have to understand the basics.
Time to time, you'll have to talk to developers and testers - hopefully these discussions will happen on a daily basis - and you must understand what they are talking about. If you just nod and take everything as they say, you'll be in trouble: they'll know that you have no idea what they are talking about - no respect - and sometimes they tell you something because they want and not because it is good for the project.
Let's take the classical rewrite example. Developers will tell you all the time that the product has to be rewritten and they'll have very good arguments. This action is a challenge for them, but a huge risk for the project. If you the basics of software development, you can challenge them back using the existing architecture.
The other tricky area is the estimations and planning. You won't estimate the projects by yourself, but this doesn't mean that you have to accept the estimations you receive. I'm not saying that you have to question all the numbers, but sometimes it is good to know what they cover. You need a basic knowledge and understanding on the practical things. For example, setting up a database is not a week job, and merging code is not an hour.
On the other hand, my old boss said that a good manager didn't have to know anything about the area he was managing. I still believe that he was wrong, because he hired somebody based on this principle and that guy almost killed our project, but what he advised that to have a technical guy who you trust and let him handle the cases I mentioned above.
Looking at the question in another way, the disadvantages of emphasizing technical expertise when thinking of transitioning to a PM role are:
Check the PMI website to go over the training and experiential pre-requisites for the PMP certification. Three years in position may be enough but you will need a fair amount of PM training. Be aware that PMI does audit some proportion of applicants to make sure the experience and education reported is accurate.
The answer here really depends on the company you work for, how they utilize their PMs, and what the company culture is like.
I think in many/most situations, you'll find that Pawel's answer ("none") is correct. If a company is utilizing their PMs strictly for managing projects, then the project management skills vastly outweigh any concern for technical ability.
In those situations where PMs are used for more than just managing a project, the technical skills might be more important than otherwise. But they still need to take a second-fiddle role to the project management capability. And more importantly, you need to make sure to trust those with more technical experience.
There are some places where having the technical skills will increase the trust that the development team is willing to place in you, knowing that you won't sign them up for something unobtainable. However, that kind of trust can still be built by those without technical skills, it might just take a little longer.
In any case, it is important to realize that whatever technical skills you have when you make the leap, they will quickly be outshone by the developers working on your projects. Development is what they do day-in and day-out, so if you aren't able to rely on them to make the technical calls, there is something wrong (most likely in your perspective of your own skills, though possibly you just have some new developers).
As a side note, I would strongly recommend getting some actual project leadership experience (or even PM experience) at your current job before trying to jump into a project management role at a different company. No amount of training is going to be as important as actually experiencing things first hand. If someone came to us with PMI certification and no actual PM experience (or even project leadership experience), it would be tough for us to bring them in.
There are many skills and knowledge areas necessary or good to have to be a decent project manager, one of which is technical skills and knowledge. The absence of one of these many skills will not cause imminent failure. In addition, projects are unique and one project may require the presence of a certain skill over another for that project at that time, meaning the weights you apply to each skill will vary.
To get hung up on one attribute is to put blinders on. There are many flavors of PMs, each with a set of benefits and a set of costs and penalties. Look at the bigger picture.
