It is now eight years and counting that I've been involved in managing Software & Systems Projects as Projects / Programme / Portfolio Manager, enough time I suppose, to have built up at least some experiences that might count as pearls of wisdom, that I could impart on fellow young Project Manager newbies entering the role; or to young engineers doubting the usefulness & effectiveness of the various Projects Manager roles.
I started off as an EIT (Engineer-in-Training), following the usual technical ladder reaching the point of Senior/Principal Engineer. I could have stayed on the technical path (I enjoyed writing code, wrote some really good code too [it's a great feeling when a consultant comes to you after your code has been in circulation for three years saying "your code is one of the most beautiful pieces of code I had to extend, it was really well written, a pleasure to maintain"]) but I always intended to learn everything about the Software business and so couldn't see myself inclined to writing code, debugging, doing maintenance, support or integration forever. I also did not want to become a traditional Line Manager that gets to look after lots of people (although I could) doing appraisals, managing performance and dealing with Administration & HR issues, not to mention Office Politicking. So I delved into Technical Project Management, just around the time that Agile/XP practices were gaining strength and coming of age.
I felt that Project Management touched on a variety of aspects of the business of Software, Management, Business, Execution & Delivery - so I wanted to experience it. The role includes managing stakeholders up and down the business, engaging with engineers directly, doing demos and exhibitions, dealing with customers and third parties, setting up contracts, commercials and strategic planning, interacting with sales/marketing and also contained (to my pleasant surprise) a lot of coaching, mentoring and up-skilling project team members -- so pretty much touching on all areas of the business, a little more exciting than being just a Software Development Manager IMHO...
Quite recently, a young graduate newbie once called me a Pseudo-Technical Manager, inferring to someone who has dabbled in Technical/Engineering and just wasn't cut-out for the Techie nitty-gritty stuff. A young Project Manager would have been outraged at this insult of this arrogant young-fool, child of the Y generation - challenging the new PM in the first week of the job! Alas, I just smiled at him for his passion in being an engineer and for his naivete in not understanding the bigger picture. I could have pointed this graduate software engineer to all the code I've written and products delivered that was light years ahead of the current company's portfolio - but instead I let it lay (He will grow in time, and besides, PMs have a thick skin - we don't get offended or take things personally)...
Projects Managers, whether they come from a Technical (Software Background) or not (Construction, Mining, Psychology, Finance), regardless of the new buzzwords that come and go, are here to stay because the role offers value. Plain-and-simple. Scrum Master, Product Owner, Product Manager or not, there is still a need for a role to provide the Map, a Path to get to the Destination, clearing the Path, removing Obstacles and ultimately Executing & Delivering the Project through its People. Although, having said that, I have been biased, perhaps a little prejudiced against Project Managers assigned to a Software/Systems Project that have really never experienced the art of Software/Systems Engineering before, first hand, in the trenches. That is, I used to say "If you ain't written code before and delivered real software products, then you're ain't managing my project". In the same vein, I was also not convinced that you can be a CTO or CEO of a Technical Organisation, having never been technical yourself (a post for another day...). But through my own personal growth I have come to work and appreciate a Projects Managers from variety of backgrounds, even those of whom have never written a line of code, deserving of my appreciation...
Coming back to point, a Projects Manager is a much needed (but sometimes undervalued) role in an organisation. One of my first PM mentors stressed upon me that a PM is really a Service Provider: PMs provide a service to the project team/engineers. That concept did indeed take some time to warm up with me, as will most PM newbies experience. The first inclination of a young PM is to be misled or disillusioned with power, that "with great power comes great responsibility", "I am Project Manager now, I call the shots, I drive the plan, crack the whip!", "I set my meetings around my calendar, people must just commit because I commit", etc, etc. On the other hand, another early mentor gave me this advice "If you ain't pissing people off, you're not doing your job as a PM. A PM asks difficult questions, follows-through, pisses people off. I measure your progress by the number of complaints coming back from people - you're being a hard-ass PM!"
Young Project Managers must start off slowly, beware of jumping into the role with the wrong attitude as if you're in charge, as a PM, you have to earn your stripes, work with and through people to gain respect, build relationships and ultimately become influential and a driver, through action and taking the lead. A PM must build up a level of Emotional Intelligence (something which I at first was wary of), understand the nuances of Cultural Dynamics and Neuroscience, working with and through people...Building relationships and effective communication skills are probably the two most important soft skills you will need as a PM...
So this Project-Manager-as-a-Service spiel stuck with me for a long time, and continues to do so today. Recently, I was playing with this metaphor that a Project Manager is really a Shepherd, as in a shepherd of a herd of livestock/cattle. I googled for a bit for similar metaphors but couldn't find anything that related to the message I had in my head. So I decided to write about it here as a first attempt, hopefully it will grow and mature over time depending on public feedback.
I started off as an EIT (Engineer-in-Training), following the usual technical ladder reaching the point of Senior/Principal Engineer. I could have stayed on the technical path (I enjoyed writing code, wrote some really good code too [it's a great feeling when a consultant comes to you after your code has been in circulation for three years saying "your code is one of the most beautiful pieces of code I had to extend, it was really well written, a pleasure to maintain"]) but I always intended to learn everything about the Software business and so couldn't see myself inclined to writing code, debugging, doing maintenance, support or integration forever. I also did not want to become a traditional Line Manager that gets to look after lots of people (although I could) doing appraisals, managing performance and dealing with Administration & HR issues, not to mention Office Politicking. So I delved into Technical Project Management, just around the time that Agile/XP practices were gaining strength and coming of age.
I felt that Project Management touched on a variety of aspects of the business of Software, Management, Business, Execution & Delivery - so I wanted to experience it. The role includes managing stakeholders up and down the business, engaging with engineers directly, doing demos and exhibitions, dealing with customers and third parties, setting up contracts, commercials and strategic planning, interacting with sales/marketing and also contained (to my pleasant surprise) a lot of coaching, mentoring and up-skilling project team members -- so pretty much touching on all areas of the business, a little more exciting than being just a Software Development Manager IMHO...
Quite recently, a young graduate newbie once called me a Pseudo-Technical Manager, inferring to someone who has dabbled in Technical/Engineering and just wasn't cut-out for the Techie nitty-gritty stuff. A young Project Manager would have been outraged at this insult of this arrogant young-fool, child of the Y generation - challenging the new PM in the first week of the job! Alas, I just smiled at him for his passion in being an engineer and for his naivete in not understanding the bigger picture. I could have pointed this graduate software engineer to all the code I've written and products delivered that was light years ahead of the current company's portfolio - but instead I let it lay (He will grow in time, and besides, PMs have a thick skin - we don't get offended or take things personally)...
Projects Managers, whether they come from a Technical (Software Background) or not (Construction, Mining, Psychology, Finance), regardless of the new buzzwords that come and go, are here to stay because the role offers value. Plain-and-simple. Scrum Master, Product Owner, Product Manager or not, there is still a need for a role to provide the Map, a Path to get to the Destination, clearing the Path, removing Obstacles and ultimately Executing & Delivering the Project through its People. Although, having said that, I have been biased, perhaps a little prejudiced against Project Managers assigned to a Software/Systems Project that have really never experienced the art of Software/Systems Engineering before, first hand, in the trenches. That is, I used to say "If you ain't written code before and delivered real software products, then you're ain't managing my project". In the same vein, I was also not convinced that you can be a CTO or CEO of a Technical Organisation, having never been technical yourself (a post for another day...). But through my own personal growth I have come to work and appreciate a Projects Managers from variety of backgrounds, even those of whom have never written a line of code, deserving of my appreciation...
Coming back to point, a Projects Manager is a much needed (but sometimes undervalued) role in an organisation. One of my first PM mentors stressed upon me that a PM is really a Service Provider: PMs provide a service to the project team/engineers. That concept did indeed take some time to warm up with me, as will most PM newbies experience. The first inclination of a young PM is to be misled or disillusioned with power, that "with great power comes great responsibility", "I am Project Manager now, I call the shots, I drive the plan, crack the whip!", "I set my meetings around my calendar, people must just commit because I commit", etc, etc. On the other hand, another early mentor gave me this advice "If you ain't pissing people off, you're not doing your job as a PM. A PM asks difficult questions, follows-through, pisses people off. I measure your progress by the number of complaints coming back from people - you're being a hard-ass PM!"
Young Project Managers must start off slowly, beware of jumping into the role with the wrong attitude as if you're in charge, as a PM, you have to earn your stripes, work with and through people to gain respect, build relationships and ultimately become influential and a driver, through action and taking the lead. A PM must build up a level of Emotional Intelligence (something which I at first was wary of), understand the nuances of Cultural Dynamics and Neuroscience, working with and through people...Building relationships and effective communication skills are probably the two most important soft skills you will need as a PM...
So this Project-Manager-as-a-Service spiel stuck with me for a long time, and continues to do so today. Recently, I was playing with this metaphor that a Project Manager is really a Shepherd, as in a shepherd of a herd of livestock/cattle. I googled for a bit for similar metaphors but couldn't find anything that related to the message I had in my head. So I decided to write about it here as a first attempt, hopefully it will grow and mature over time depending on public feedback.