Where is the PM ?

This thought came to my head when I was talking to my friend Abhishek Parolkar.

I found an interesting scenario amongst set of people i speak to. Most of junior engineers have a different impression of what role a Project Manager plays. In a usual Software development team, there will be a set of development engineers, testers, designers and one or more project managers. Each and every role is critical to the success of the project. However, this team work can only sustain on the foundation of trust, caliber and communication. One other important aspect is the sense of respect and empathy of each other's role and contribution to the success of the project. In most of the failure stories of project, its not just the result of incompetent technical team, technical bottlenecks and crappy management, but also the absence of this sense of respect and empathy. Partly the responsibility of this absence is the lack of understanding the importance of the role of a contributor. And this absence is prevalent in most of the teams i have seen. I understand the source of this problem : lack of initiative from the team management to make sure each and every member understands the importance and challenges of all the roles : tester, developer, designer and PM. But my focus in this post is not about solving this problem. The point i want to make is how a PM role is understood by the other team members. Most of them are junior engineers / testers who have a little or no knowledge about the PM's role. The impression that they get is that a PM is more of a interruption rather a boon for the team. We know the role of a PM is amazingly critical. It includes resource planning, estimation, risk assessment, delegation etc., and makes sure that team is well on the way for on time delivery.

However, a friction gets developed, when the PM and delivery team do not go well together either on delivery timings or estimations. This friction not only divides a team but jeopardizes the delivery. The insight into understanding these differences is important for all teams.

A leader is respected when the team is aware that the leader understands each and every one's work, not just in theory, but has been there, and done that. This means, the source for respect for a leader, in a knowledge based world, is only possible when a leader has experience in most of the functions that he leads. Take example of Army, a Leader in defense wing is respected only when the junior officers are aware of the accomplishments or experience of the leader. This brings in the confidence in the officers about decisions made by the leader. And creates an atmosphere of trust and empathy, so critical in the functioning of the unit.

Coming back to my point, I prefer a person who leads my team to be someone who has a field experience in various functions of a Software team, and is one who empathizes the challenges faced by each and every role. With that, I advise my fellow team members and people whom i mentor to always strive for multi-functional role. Whether it is Support, or Testing or Development, or any other role, each one brings value to the table, and hence to grow as a leader, it is advisable to have hands full with experiences from all around. There are many examples in industry that makes this point evident by following it religiously. However, there are scenarios where individuals are not exposed to other facets of job, but that requires initiative from the individual too. We all have to start knowing in detail, or at least empathize the various roles. This will bring out the best in us, and give us all the support to lead in this knowledge centric economy.