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.

  • Main question and inner question are not the same. 3 years of project experience are not enough to qualify to write the PMP. That is more than enough to write the CAPM however. Commented Mar 28, 2019 at 14:02

6 Answers 6


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.

  • 4
    +1 - Love your comment "You can be a decent PM without technical skills. You can't without project management skills."
    – M0N4K0
    Commented Aug 13, 2012 at 11:16
  • "Without technical skills" is a bit vague and probably overstating it. I'd prefer to say "without deep domain knowledge" But, in most cases, you still need to do things like manipulate data in Excel or be reasonably competent with Outlook (or comparable programs). Commented Oct 25, 2014 at 4:00

Project Management is Process Management

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.

PMO vs. Technical Project Management

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.

It All Depends

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.

  • 2
    I disagree with this so much. If a PM is expected to make all the calls in a team (what to rewrite, how to adjust estimates, etc.) their technical skills are the least of the problems. I'd start with trust within the team, people involvement, responsibility and accountability and finally their skills and practices. Commented Aug 13, 2012 at 8:38
  • 1
    @Pawel, where did I say that the PM makes all the calls? I said that as a PM you have to understand what is going on and be able to communicate with the colleagues.
    – Zsolt
    Commented Aug 13, 2012 at 8:40
  • 1
    In your examples: you don't trust developers with refactoring calls and expect a PM to double-check these, want a PM to challenge estimates and deciding which ideas are good for a project and which only for people involved but harmful to the project. "All the calls" was an exaggeration, but these examples are very strong. Commented Aug 13, 2012 at 12:31
  • I think I got your point, and my answer can also be interpreted as you did, but based on my experience those projects went much better where the PM had technical background. Is there a way to talk to those PMs - without technical skills - that you were referring in your answer? I'm really interested how they do their business. I may use that knowledge to help the PMs here who lack technical skills.
    – Zsolt
    Commented Aug 13, 2012 at 13:34

Looking at the question in another way, the disadvantages of emphasizing technical expertise when thinking of transitioning to a PM role are:

  • Lack of PM skills. Assuming there are only so many hours in a day to work on your entire skillset, emphasis on being a good developer will take away from developing the skills necessary to be a good PM. I think a there is a strong argument that PM skills are more difficult to learn than technical ones because key PM skills are "soft" (leadership, motivation skills, etc)
  • Too much technical expertise. If you are a good developer then at some point you are going to be assigned a developer that isn't as diligent/experienced/good as you. There will be an overwhelming desire on your part, or expectation on your boss' part, to jump in and do work that a PM should not be doing.
  • Lack of realistic job expectations. If you are a developer first and a PM second you may be getting into a situation where you don't really know what you are getting yourself into.
  • Lack of transferability. PM skills are transferrable, much more than technical skills. And I'll bet you that PM skills won't become obsolete like many/most technical skills will. Be prepared for a dream job that comes along in an area different enough that you will have to rely on your PM rather than technical skills.

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.

  • Thanks Kyle for the comprehensive reply! From what I see here in my team, I find it almost impossible for me to take up any lead roles as the positions have been well covered and I dont see them leaving anytime soon. Would it be better for me to make a jump to a technical role where I have more lead possibilities to get more PM experience?
    – Wayne
    Commented Aug 14, 2012 at 1:31
  • Have you talked to your leads about helping them out? If you haven't already, I would suggest talking to your leads to better understand what they do and whether they would be willing to have you take on some of what they do. I wouldn't suggest making a jump elsewhere unless you've had that talk already.
    – Kyle
    Commented Aug 14, 2012 at 16:26

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.