Wednesday, August 07, 2013

This is a sad reflection of what is reality in much of the big corporate world

Monday, August 05, 2013

Should project managers have domain expertise?

I wanted to write this post as a comment to a LinkedIn discussion, but found that I was way over the character limit.  Therefore, I'm posting it as a blog post here.  The question was whether IT project managers should have programming experience.  While my post is specifically related to software project management, I think my concepts in general apply to any project where the work needs to be carried out by people with specific and unique technical skills.  The domain of expertise could be anything from IT to construction to military missions.  Here's the post.

First of all, I should comment that it's not absolutely necessary for an IT project manager to have coding experience.  There are lots of IT projects in this world that are managed by project managers with zero coding experience.  Therefore, I'll assume that the discussion is not about whether coding experience is necessary, but rather that it is about whether coding experience is preferable.

And of course, in IT projects that have nothing to do with software (for example, datacenter projects, desktop deployment projects, etc), coding experience would add less value than for software projects.  So I'll assume that this discussion is only for software projects.

I can think of several good reasons why it's a good idea for software project managers to have coding experience.  The below points assume that a project manager's understanding of coding is better if he/she has actually experienced coding.  It is like saying someone understands how to ride a bike better if they actually have ridden a bike before.

1.  Increased communication efficiency
Software development has lots of unique terms and processes that are very important.  If understood and used properly by skilled people, you can make high quality software.  If you have a project manager who has zero coding experience, that communication becomes inefficient because the project manager is not able to keep pace with the conversation.  It is like trying to manage workers who speak a foreign language.  Yes, it is possible, but the workers must slow down their conversation speed by 50% in order to translate the conversation to the project manager.  Time is money.  In this situation, an employer is saving money by spending time.  If it's not an equal or positive tradeoff (and it usually isn't because delays can be expensive), the employer's decision may end up being very expensive.  If there are difficult problems, then the conversation speed needs to drop to 75% in order to make sure that the problems are understood properly.  And we are not talking about only meetings.  We are talking about conversations that happen in bug tracking databases, long email chains, escalations, etc.

2.  Increased decision quality
The project manager is in charge of the day-to-day management of the project: tactical direction and execution.  As such, there are times when the project manager must make decisions about what to do and what must be priority (though in some project management styles, project team members can receive a lot of freedom).  The point is that the project manager must make decisions.  If the project manager has no coding experience, he/she will have a more difficult time understanding the issues and status updates provided by team members (see point #1 about communication efficiency).  Therefore, a project manager with zero coding experience would be in a position where he/she has great power and great responsibility, but lack wisdom about how to use it.  This is because real-world wisdom is gained mostly through experience, not the classroom.

It is true that the project manager can rely on the feedback of the team to make decisions.  But why do that if it is more inefficient (needs more time), more costly (needs more people), and still prone to error and poor decisions (poor understanding in leadership positions)?  Besides that, the risk from having a project manager with poor understanding is infinite.  Would you want the project manager of a building construction site to have zero construction experience?  People's lives would be at risk.  People's lives may not be at risk for most software, but there are other types of risks.  As Yishan Wong notes, "A skilled non-technical manager can get a pretty good idea, but all other things being equal, they will be outperformed by a similarly-skilled manager who has a technical background."

3.  Respect and Teamwork
If the project manager has coding experience, the project manager is more capable of understanding and communicating with the project team.  This is important because then the project manager will find it easier to get the respect of the team.  Technical people are usually very smart.  Nobody likes to work under someone they think is stupid and not qualified for being in a supervisory or management role for their particular line of work.  If the project manager is able to gain respect from the team because of being able to understand the team (again, we assume that coding experience makes it easier for the project manager to understand and appreciate the team's real issues), the team will naturally be more motivated and able to work together better.  Such natural motivation and teamwork is always more preferred than not.

One final point I'd like to make is that people often say a business (or non-technical) person is necessary to talk with the customer and understand the customer.  Yes, this is normally the role of the project manager.  I am not saying that communication skills, customer service skills, scope management skills, budget management skills, big picture vision, etc are not necessary.  These skills are very necessary.  What I am saying is that if the project manager has these skills AND coding experience, the project will have a much higher chance of success, no matter how you define project success.  I find that people often say if it's not necessary, then there's no point in having it.  The question shouldn't be whether it's necessary.  The question should be if it's preferred, and if the customer can live with the risks that would exist if you do not make the preferred decision.