Is it the best way to have a "software development project manager" who is a great developer himself?

Question

How does it work in the market? If possible to generalize, is it a critical point to have a project leader to be a developer himself?

If he is not so much in coding, how can he understand what the rest is really talking about. If he is so much good on programming he might have difficulties on leading probably. If you think about the "good" project leaders you have met, how was this balance?

Answer 1

When the project manager understands the workflow of programming everything is well. The project manager doesn't need to code so he doesn't need to understand it either. All he must understand is what kind of things must be done to complete the project with success.

Answer 2

Difficult question.

It actually depends on the size of the project. In large projects, you will often have an overall project lead, and a development lead. Then the dev lead should be developer with good management abilities. Not all devs can do this, so it's important to choose someone with a good balance of technical and organizational/social skill.

If you only have an overall project lead, then it's a bit more difficult. The lead will probably do a lot of customer interaction & organization, so a dev does not make a lot of sense. Then you should probably choose someone as the dev lead (even informally) to liaise with the project lead.

The important thing is to have someone responsible for technical dev questions, and that someone must be a dev.

Answer 3

The successful project leads I've worked with were all former programmers with good people skills and a talent for organizing things. Usually they didn't do coding anymore but had an idea of how that stuff works.

The unsuccessful project leads usually lacked people skills and had little to no talent for leading other people.

Answer 4

I once had project manager who is great developer. He's technically very helpful in the project. But the project failed because he was not paying more attention to deadline, he's so into the code & design.

If all people in the project pay more attention to the code, documentation, etc. who will pay more attention to the project deadline?

Answer 5

Well, It certainly helps if the Project Manager is a developer. But this unfortunately is not near enough.

There is a video with Scott Hanselman and Chris Sells on Hanselminutes on 9 where they "kinda" talk about managing people and time. What I kept from that video, is when at some point Chris Sells said that management is not so much about being productive yourself, but making your team be productive. I think that this is a really critical aspect of an effective manager. Make your people be and want to be productive.

In order to achieve this therefore, one should absolutely have the following abilities in my book:

• Be able to clearly understand the specs and purpose of the project (in this case yes, the Manager should be a developer)
• Be able to delegate the tasks at hand to the team effectively, which is only done rightly if he/she truely knows his/her team.
• Be able to monitor the progress of the project, i.e. understand the implemented code
• Be able to give advice to the team when needed
• Be the kind of guy/gal whom the team will not hesitate to approach when in need of assistance
• Be able to effectively communicate issues at hand from the team to management and from management to the team

As you can see, for some of the points I mention, the manager being a developer is a must, for others not so much.

Answer 6

I think there are a number of ways to be a good project leader. I currently have 2, both of them excellent. One of them is a software engineer who likes to argue with me until we have the best solution to something. I enjoy the arguments and our software is better for it (he also likes the chance to think for a change instead of writing TPS reports).

The other is, for all intents and purposes, his boss. When I have discussions with the "boss" he has NO understanding of software engineering - he does, however, realise I do. If I tell him something will take yae long, or is not doable, he doesn't argue - he tells the customer and takes the hit instead of trying to pressure me to do the impossible. This approach allows us to build fantastic, highly stable software that is a world leader in its field. Our software would not be as good as it is if we had to constantly "hack" to please customers. Obviously sometimes we have to hack, and when we do we all work 18 hour days for a week until what needs to be done is done. I for one wouldn't do that if the normal management style was "get it done when I tell you".

I guess what I'm trying to say is - it probably doesn't matter if you have a background in engineering or not, as long as you know what you don't know and allow the engineers to do their job without interference.