How technical should a Project Manager be?

Question

Consider a software project involving a bunch of developers of mixed experience. The PM has the delivery responsibility for the project, but undertakes this through the team members.

When the developers give an estimate for a technical task, how important it is for the PM to know what is being told to decide if is reasonable?

When the developers specify a technical impediment, how much involved should the PM be to resolve it?

Hope you get the drift of the question. Obviously there is no right or wrong answer, just thoughts.

Answer 1

Technical skills is always nice-to-have trait for project manager but in vast majority of cases they aren't crucial. If project manager has the best technical skills in the team why is she managing the project and not building the project?

If PM has to double-check every estimate he gets from the team there's some basic problem with trust in that team.

PM is one of team leaders (note: usually not a manager who has direct power) who can influence team members. But it doesn't mean PM should be the most knowledgeable and most experienced person in the team. It's like with leading any other entity - when your knowledge is short find people who are knowledgeable enough and you trust them, no matter if you deal with an estimate or a technical issue or whatever.

And when we are on estimates, gather historical data: both estimates and time you really used. You'd be able to tell how optimistic your team or a specific member typically is.

Answer 2

From my experience, some technical knowledge is necessary. The PM has to at least be able to speak the the language of the technical people on the team. I have also seen that technical people get more respect from the people on their team. I was on a team at a previous company and the manager knew nothing technical. His main role was just to make sure everything was on schedule and under budget. He was not respected in meetings and people gave him unreasonably long estimates for tasks, because they knew he didn't know any better. Some of these issues were a cultural problem with the organization, but a more technical PM, would have been able to see the ridiculous estimates.

Answer 3

I've had good managers that were non-technical, and ones whose technical skills were dated. It's certainly nice to have first hand knowledge yourself about the tasks you're assigning to others, but remember that you're managing a team. You should have several people in your group that you can run estimates by for feedback on how reasonable they are. You might also be able to compare notes with other managers in your organization. In short, it definitely helps to have a technical background, but I don't think it's 100% necessary if you have a good group and your other skills are there.

Answer 4

High-tech projects are ideally staffed by creative, educated, opinionated professionals. A PM who understands the technical aspects of the project will be more likely to gain the respect of the project team - but it's not the only way to gain their respect, it's just a way.

Another advantage to a PM who has a technical understanding of the project is that they will be able to communicate effectively across all levels of the project. One of the key roles of a PM is to facilitate communication amongst all project stakeholders. A technical PM should be more effective at communicating complex technical information. A non-technical PM would need to defer some of that communication to someone on the project team. Not bad, but just different.

I agree with pawelbrodzinski's answer. If the reason you seem to need a technical PM is to second guess or double-check every decision made by the project team, you probably have a trust problem on the team.

Answer 5

I feel that having technical skills gives me an advantage of being able to communicate about the project with the members of the team. It's easier to bounce ideas back and forth if there is programming experience. Many times have I suggested a solution or architectural pattern and many times have I been a sounding board for engineers looking for a solution themselves.

In my experience, the time estimates are typically under-estimated, and my experience has helped me tell the difference.

Since the project manager is responsible for the overall success of the project, he/she should get as involved as necessary to see the project through. There are times where it's important to dig into the code to either help get things started, choose the right technologies, deploy a solution to a client, or to understand the project from a technical standpoint.

Some might argue that choosing the right technologies borders on the "how" part of the project and not the "what", but this is a big decision that has a profound impact on the project success, and PM's should be involved in this decision and then leave implementation details to the development team.

Answer 6

I would say that a basic technical knowledge is necessary to talk and understand both, your team and the customer.

On small teams I think a technical background is more important, because the PM will be more involved to the impediments.

On bigger teams there will be team-leaders and technical-coordinators above the team, so the PM role will be less technical and more on people and project management.

Answer 7

I think subject-matter experts make the best PMs, however, that's not a prerequisite for selecting a PM.

1. Estimating definitely improves with experience as a PM and as a SME but is heavily influenced by company/culture and the process being used (waterfall, agile, wishful). A SME PM is better able to challenge estimates - but isn’t responsible, by role, for producing the work - so not always in a position to challenge those estimates. A PM in that situation could propose alternatives to improve estimates or challenge with estimates from a 3rd-party.

2. There will be impediments; typically a result of changed conditions or a root-cause in the project set up. All projects that fall behind do so in the beginning. allow for ramp-up at the start. This is really a matter of getting the core, essential, measurable goals right in the beginning and applying reasonableness to the plan before starting.

Answer 8

This is a great question! It inspired me to take action and do some research of my own. I interviewed one of my techie colleagues, and I wrote this blog post titled Monday’s interview – Tech Talk with Ciprian. I asked some more questions related to the same issue: "how much tech is too much tech in PM" :). I hope this helps!

Here's a snippet from the interview that helps further answer this question:

Dana: When the developers give an estimate for a technical task, how important it is for the PM to know what is being told to decide if is reasonable?

Ciprian: Extremely important. The project manager needs to have a clear understanding about any technical task being estimated. Deciding whether or not the estimate is reasonable, the PM needs to have a very good an honest relationship with the developer (or designer) giving the estimate. The PM needs to ask a lot of questions to try and understand fine aspects of the task, trying to keep in mind any technical roadblocks that might throw off estimates. One last point is that the PM must clearly report estimates particularities to client service or directly to clients so that they will have a clear understanding about what are they paying for.

Being technical as a PM basically can help improve the relationship between the PM and developers/designers, since they'll speak the same technical language.

Dana: When the developers specify a technical impediment, how much involved should the PM be to resolve it?

Ciprian: PM needs to be aware of any technical impediment, especially ones that will affect overall architecture. The PM and developer (or designer) must work together to come up with a reasonable solution. The PM must not rule out getting advice from other technical persons or anybody who can provide consultation on the issue.

Check out the rest of the interview for more information.

Answer 9

Technical skills are a plus, of course. But a project manager should understand that any information received from his/her technical team member has to be double-checked by another technical specialist. Management should always stay a bit away from implementation.

Answer 10

We live in the era where no mangerial work can run alone, it do need some supporting engineering background. In other work, project management is a iterative process in every phase and sub-phase of product management. Of course, that needs a surface understanding of technical knowledge and there is no + or - advantage of it because to run the process you need to understand it first, so, technical knowledge [basic] is required to manage and run the project process.

When you said team of developer with mixed experience you must seek for the Participative leadership which involved each team member to provide input and you have the authority to give the final output.

It's always a misconcept when people start comparing talent with experience. When you said mixed experience it doesn't mean that a developer with less experience can't code better or faster than experience one. Study them and come up with a strong plan which will help you in deciding that who should involve with you in decision making, in participative leadership.

Answer 11

"How technical" could manifest in different forms. Based on my experience in project management and development management, a project manager must be technical in the sense of competent in problem solving in the domain of the project. It usually requires past experience of development in the related domains, for example, for software/hardware development, such problem solving skills could come from being a senior architect, senior software/hardware engineer, etc. The key is not the detailed knowledge of particular subject, but the maturity acquired from having solved complex enough problem before.

In another sense, being technical could mean more on the meta level, a good project manager should be an explorer, and researcher to abstract out of chaos of unknown to define the right problems for the team to solve. By this definition, such good project manager may not be expert in the domain, but expert in problem solving in unknown domains, expert in defining the right problems for the other experts to solve. In this regard, I witnessed many math major could do very well as project manager.

Sometimes, a good project manager can take advantage of being not too technical in a particular aspect to see the big picture, and earn the excuse to ask "stupid" questions that the experts overlook, or are afraid to ask.

So in conclusion, project manager got to be very technical in project management! I see the danger of some project managers behave as a secretary, or administration assistant.

Answer 12

It always helps but it isn't crucial. What is most important is that the project manager is a critical and logical thinker. Here is an interesting quote from Paul MacCready who built the first human powered airplane with little knowledge about airplanes:

"I have no background in aircraft wing structure. Thus, in my naiveté, I started from first principles (with some insights left over from building indoor model airplanes in the 50s and hang gliders in the early 70s), pretended I never saw an airplane before, and came up with the Gossamer Condor approach that permitted a 96’ span vehicle to weigh only 55-70 lbs. The British engineers also knew about indoor models and hang gliders, but they knew so much about their specialty that an easier approach was not apparent.”

More here:

How nature and naiveté helped Paul MacCready build a human-powered airplane in only six months

Answer 13

The project manager should have a good understanding of the technologies involved in the project. Not that they can code, but understand how the pieces fit together from a high level. Leadership and communication are more important qualities.

Depending on the process, there may be procedures built in that help verify task estimates. For example, agile’s planning poker help a team of developers come to a consensus on a task estimate. Additionally, any developers with high or low estimates can make their case to the group.

When a developer identifies a roadblock, sitting down and interviewing them is the best way to resolve the issue. Ask questions to make sure you have an understanding of what the issue is and the constraints. Brainstorm solutions to the problem with them and clarify the next steps in the plan of action.

Answer 14

While I have seen projects completed successfully with non-technical PMs, I've also seen a lot of disasters. (That's one of the pushes I had to move from programming to PM.)

One point I have not seen mentioned in the other answers, is the Big Picture aspect of the project.

While we hope we have people we can rely on to give us accurate information (or best-try guestimates), there are often areas that belong to the Big Picture.

One classic example is integration. While each individual developer will give you his best guestimate, few, if any, will remember integration, or have any idea how important it is to scheduling. That's where the technical savvy of the PM is important.

How would a non-technical PM know if and when integration is needed?

Another example would be the Use Cases. How does a non-technical PM know how to write proper use cases, especially those that cover the corner cases, or extreme circumstances. Even if others write them how would the PM know if all bases are covered?

(Some of this is a repeat of my blog post Why a technical Project Manager?.)

Answer 15

The requirements for a project manager always go out from a project profile. Check DPCI for instance. You can use risk profiles as well.

More technical experience:

1. Small - you just won't have enough administrative tasks to do, so you better write code with others. You can always back your guys in case sick leaves. And sometimes it's just simpler to fix the bug then create a ticket, and describe the story behind it.
2. Short period - you don't have time to wait for SME, you need the solution here and now.
3. Limited resources - you can't get more developers to it, so it's time to get hands dirty.
4. Clear objectives and scope - there's no need to work on specs and with stakeholders, you just need to make the things to happen.
5. Simple organization structure - there's no need for advanced workload management, you don't need to participate in internal politics, you can rearrange team flexibly, everyone works for the one project, and you know to whom address the issues raised. The only thing you need to do is to code.
6. Adequate and engaged stakeholders - stakeholders share one culture, tech level and product vision with you, they know what they want they are nice guys to work with, you don't need to negotiate, contract wars and try to guess they expectations.
7. New technology - it's always a huge risk, so you need to be an expert to mitigate them.
8. Junior team - someone just have to mentor Juniors.
9. Risk-free environment - you don't need to model scenarios, create risk charters and risk mitigation strategies, just code.

Less technical experience:

1. Big - you just don't have time to code.
2. Long period - there's always a time to ask someone who knows more than you.
3. Unlimited resources - you don't need to think about workarounds and tradeoffs just make it the better way.
4. Unclear objectives and scope - someone need's to clear this mess, engage stakeholders, achieve and maintain crystal clarity through a project.
5. Complex organization structure - in big and complex structured company PM should be an ambassador of a team, know the right persons to get what's needed to keep things smooth and running.
6. Inadequate and unengaged stakeholders - I was lucky enough to work with exceptional customers, but most my colleagues don't. You need a master smooth talker and a king of crooks to deal with customers who try to cheat you.
7. Mature technology - you don't need a spark of genius to google for a solution.
8. Mature team - when you manage all-stars senior+ team you just need to sit back and watch the show.
9. Risky environment - while tech pm can focus on implementation on risk-free env., in risky env. you need to have a broad look on all aspects, to be a night watch for a project seeking for a wolf-pack of troubles trying to get your project down.

Why not have both? Scrum divides the PM on TeamLead, basically a technical expert, SM as a process expert and PO as a product and customer engagement expert.

I have also noticed that there is a two extremes for tech knowledge of PM's. One is you need to know enough to speak one language with the team and understand basic tech concepts, the other is that you should be the best developer in the team. Everyone in between tends to propose implementations that fall below teams capabilities.

Answer 16

To me, the Project Manager should be technically good in terms of applications. If otherwise, the team can easily make him/her stupid in terms of estimation & many. It is not the only factor but one of the major factors to be a good Project Manager. What happens in business, if the guy running in, doesn't have much technical knowledge of the same, resulting in failure in the course of action or application. Be Technical Be Safe!!!

Answer 17

In my experience, the most effective PMs have both a technical background and an understanding of the business model of the domain of their project. Otherwise their ability to participate constructively in planning is limited and they cannot effectively question developers or business owners about the relative value and priority of features – something that must be done on many projects.

I have seen PMs operate without technical and business knowledge but in my experience their value is limited to being a scribe and a facilitator.

Answer 18

In management, you have strategies and techniques. A strategy is a ensemble of techniques coherently used to achieve a goal; a technique is a mean, an ensemble of tasks. Usually the word technique or technical is used for computer science and/or computer programming : a technician applies in his tasks the orders of a project manager; he or she (the technician) do not decide the way the tasks are done; he or she do them. A project manager should hire technicians.

Answer 19

As a Program Lead, I always take personal responsibility for the program success and guarantee that the resulting solution does meet business needs. It does require a proven delivery approach, technical expertise/ profound knowledge of technologies in additional to project/program management skills, people management and program governance. Technical background helps not only to validate the estimates, or solution architecture. PM is the one who must be able to deliver as promised, who decides what is the best solution to meet business requirements, and who guarantees the return on investments. PM as a true Leader must be able to step in and support the team with any challenges. Your team will appreciate it and will be well motivated by your support. Otherwise, PM becomes a PMO person, who does not influence the delivery process, but report on status and calculates costs.

Answer 20

I believe that a PM does not need to be "technical" per se. However, a key factor is how many times a PM has delivered the same project. Like some others on this thread I believe the PM does not need to be technical and should trust in their tech team. However, if the PM is at all competent, they will gain experience and best practices around the process and the best practices for executing a technical project.

So, for instance, when standing up a new Active Directory infrastructure, I would not expect a PM to understand the nuts and bolts of how to design and execute a new AD Infrastructure. However, I would expect that PM - if this is not their first project - to have best practices gathered around what a typical timeline for a project like this should look, what general questions are needed during discovery and how long that will take. Other technical dependencies (such as a working network or clean and rationalized user data) that need to be in place prior to standing up the AD infrastructure so they can help provide that air cover that is so important for keeping a team moving forward.

This is why it is critical for organizations to develop resource "pipelines" for PMs as much as any other discipline. You need to give younger PMs the opportunity to shadow or otherwise experience these projects and learn the ropes.

Answer 21

As noted in other answers, it is always valuable for the PM to have some technical background, yet on my experience is not always mandatory to have it in order to have a good PM within the team.

A competent PM will be able to ask the right questions, translate and understand the technical side to other language domain (e.g business) so that all parties involved in the project are on the same page, even when it is not the detail. This includes being able to "translate" estimates, blockers, impediments and identify risks within the team, and at the same time track these to make sure they are being tackled. This is why communication is the key part of the PM role, failing to understand at least the basics of the technical aspect, overlook or ignore comments from the team for estimates (or giving a green light to everything just because the team estimated so) and impediments (a 5 Whys session could be more than enough to get to a root cause that everyone can easily understand) can lead to problems within the project (imho).

More than anything, a savvy yet non-technical PM would have a technical lead or a technical right hand within the project that could advise on these type of complexities. I wouldn´t expect everyone on the team to be able to translate technical jargon to a non-technical PM, however more than often a technical lead is able to provide such help.

Overall, the PM role as described by PMI mentions that:

They have a broad and flexible toolkit of techniques, resolving complex, interdependent activities into tasks and sub-tasks that are documented, monitored and controlled.

These techniques known by the PM need to be able to resolve and mvoe forward technical inquiries and impediments within the team, with/without having the technical knowledge for it.

Answer 22

A while ago I asked one of the senior developers working on a project with me what would he rather have; a PM with zero techical knowledge, or a PM that used to be a developer a long time ago, who thought they knew everything about code and how much effort goes to each task.

Granted, my question only gave bad decisions IMHO, but I wanted to know which was considered a worse choice by a good developer (IMHO again).

His answer was that the second choice is the worst PM imaginable, and that some time ago he actually had had that type of "technical know-it-all" PM in a project, which ultimately caused him and a few other developers to leave the project and the project failed miserably.

So I guess if you want to have technical knowledge that you can use to aid you in managing a project, it should be as up-to-date as possible, and used in good intentions in the right situations. And it is always smart to not step on any toes (of developers and why not others as well) and respect the entire team and their skills while working on the project.

I don't know if I gave any new content to the other good answers out there, just wanted to share the story that happened to me related to this question :o)

Answer 23

It’s not necessary to have a technical background to become a successful product manager in a technical field. But it will help, often significantly if you can display some technical prowess in your PM role. And the great news is that, even if you have no prior technical experience or training, you can pick it up yourself today more easily than ever.

Answer 24

A Project Manager should have a solid understanding of the technical aspects relevant to their projects, enough to communicate effectively with the technical team, ask the right questions, and make informed decisions.

However, they don't need to be deeply involved in the technical details—the focus should be on leadership, coordination, and ensuring the project aligns with broader business goals.