The story started with my discussion with @Ben on whether or not a project manager should have architect skills. We have different views on this and I'm wondering what others about it.
So, in your opinion, should a project manager have architect skills (know a bit about the application, language it is implemented, the platform it is running on etc)?
I'm a living example of not being a technical expert, instead being a team expert. I have worked across a broad swath of high tech for twenty years and also applied my project skills to very non-technical endeavors.
I've heard the arguments for domain knowledge:
"How will you know if the estimate is false?" - If I can't look at my team and know someone is bluffing, then I'm not serving the team. My job is to know the team and help them. More importantly, my job is to trust the team. Give them trust and be amazed what they give back.
"You need to know what the technology is to understand the project." - I need to know what the value is. I need to know how it will impact the customer and the stakeholders. I need to trust the team that they know the technology. My job is to help the team.
"You can't step into something you've never done before and lead a project." - I had zero manufacturing experience and my knowledge of HDDs was mostly at the level of "unscrew it and put a new one in." I took over all program management for a consumer products HDD group and was fully integrated within three months. I didn't focus on the technology. I focused on the team. That team saw their projects go for four per quarter to thirty, with no new headcount.
"We're a start up, we need to focus" - This only carries so far. If you're engineers are spending half their time on non-coding, then that's a lot of wasted resource. If you have a ten person dev team and need more resources, hiring one more dev will be of limited value (law of diminishing return, time to bring them up to speed on the specifcs of the tech, etc.) You hire someone devoted to all the project aspects (a chief of operations if you will) and you remove most of the non-dev work, then I believe you will get a lot more productivity out of the team.
Caveat 1: The portability of project management (team facilitation, scrum master, etc) does have limits. Crossing a major domain gap (software to bridge building) is not a one to one transfer and in some instances may not be possible. Some domains have very specific requirements, typically related to safety or government regulation.
Caveat 2: You can't be a complete domain virgin. This is similar to Caveat 1, but more talks to your adaptability. I am not a technical expert, I've never coded, likely never will. That is not to say I'm lost in the high tech world. I've worked in customer support, product marketing, product management and project management. I've worked in consumer electronics, enterprise software, consumer software, virtualization, etc. What I am really good at, is learning just enough to understand and trust the team.
The skill, knowledge, and experience of every role on the team is chosen to allow the highest likelihood of success. Every project (even the same type of project done at different times) is different, with differing requirements, a different sponsor, and most importantly a different environment. The analysis of the environment is critical. If the sponsor and stakeholder environment are hostile, you would want a PM who is skilled to be able to cope with that. If he so happens to have some knowledge of the technology, wonderful. If not, who cares; his abilities to handle the customer are what is needed for THIS project at THIS time.
If you are a small company and you need to explode this one project into new business, the right choice in your PM might be someone with demonstrated salesability. If the technology is extremely difficult, i.e., you are doing something that really has not been done before to your knowledge, then a strong technologist might be your guy.
Another factor is project size, which likely has multiple types of technologies. The PM on a case like this will never get his/her hands dirty. They are running a business and need the skills to do that successfully.
The point is, we make these decisions balancing benefits and costs. What does this project need at this time? Those that answer yes or no to this question do so to their detriment. There is rarely a cookbook solution that solves every problem every time.
And think about this: this question is essentially trying to define success against one attribute. That is, all persons with this attribute will be successful and all persons in the null group will fail. The cognitive processes that allow one to answer this question is the same used to disqualify a group because of their age, sex, color of skin, religeous affiliation, etc. It is a very discrete answer against a broad brush question. What makes this more palatable is that no one is born into the group. But don't fool yourself into thinking it is not the exact same set of biases and prejudicial thinking that will yield the exact set of results the xxxisms produce above.
his abilities to handle the customer are what is needed for THIS project at THIS time.
Commented
Feb 27, 2012 at 13:58
Project management is a separate skill to software design so there is no reason why a project manager needs to be able to architect software. However, it does make the job much easier if they have an good idea of what is being built. For e.g. a good construction project manager would probably be able to competently manage a software project but it would be much more work for them than if they knew something about software design. The general project management skills are the same regardless of the project.
Ultimately, project management is about leading a team of people to a single goal. Part of this is ensuring that the project team has the right split of skills to ensure a successful end result. If the project manager thinks of themselves as the expert in any one area, it makes building a good team difficult and makes it more difficult for the project manager to look at the whole project objectively.
In pure PM terms, I suggest that the answer is "no". There is a school of thought that says that a PM should be able to run any project, in any domain, as the role of the PM is to plan, coordinate, and lead the team, while the team should consist of sufficient domain specialists to provide all of the technical inputs, including architecture, design, etc.
In practice, I don't believe that this "purist" model is entirely appropriate or sustainable. The PM has to be able to talk in the same technical terms as the rest of the team, needs to be able to challenge unreasonable estimates - both low or high - and must also have sufficient knowledge to help the team to overcome difficulties. That's why so many PM job ads specify the experience that the successful candidate must have, in terms of architectures, business sectors, and technical areas.
Architecture is just one of the skill areas where some awareness is helpful, but deep knowledge is not normally a requirement. If the PM is fulfilling the role of architect on a project, then it is important to recognise that the role is split, and when doing "architect" stuff, the person is not acting as a PM, and vice versa. This needs careful handling and I would not encourage this approach in most cases, unless there is no alternative. The roles are quite different!
If you take the SCRUM roles as an example, you have a SCRUM Master and Product Owner. These roles are very different and even contradictory and can not be fulfilled by the same person.
One is in charge of the process and schedules and the other is in charge of the vision and the quality of the outputs.
Product Managers and Architects are similar to those two SCRUM roles, in respective order. (Similar but not the same.)
Specifically from your question:
know a bit about the application, language it is implemented, the platform it is running on etc
The PM should know a lot about the application - its requirements, use cases, target platforms.
The Architect should what the architecture is, what technologies are being used in the implementation, how the application is being tested and also the requirements, use cases and target platforms.
--> Your definition of an Architect is in accurate, which might explain the disagreement you have with Ben.
