Why are PMs at technology companies often the corporate drone types that only pretend to add value by retweeting status from the people who really know what's going on? Without understanding, they play a destructive game of telephone and buzzword bingo.
Shouldn't engineers with leadership gifts lead more projects where engineering plays a major role? Am I being too engineering-centric to think that suitably gifted engineers could grok the non-engineering aspects of a project better than a spreadsheet pusher can understand the engineering component?
You have never worked with a good PM. I've worked with incredible PMs. I've seen these PMs walk into meeting with senior developers and architects, and pretty much be the only person asking the right question regarding how to get the product shipped.
And that for me has been one of the defining characteristics of a strong PM. Good questioning ability. Ability to skip to the chase. And they have a suprisingly strong grasp of dependencies. When architect A says, "this is coming in a bit late" they almost instantly are getting the PMs and architects from team X, Y, and Z in the room because they know theres an indirect relationship to these teams also.
I've only worked with one bad PM in my life. We fired him after two months. The difference in productivity, confidence, and general life enjoyment between an bad and good PM is pretty enormous.
> pretend to add value by retweeting status from the people who really know what's going on?
They are communicating, while you are coding. This is of course unbalanced.
But personally, the last thing I want to have to do is to update any random person on how things are going, while in the middle of a crunch towards the deadline.
The dark side it that I have to deal with a PM who doesn't understand the deep technical aspects and is the 'key' player of the decision process.
> Shouldn't engineers with leadership gifts lead more projects where engineering plays a major role?
Some very talented soft engineers that I know are trying their best to stay away from project management. It's how things are.
Like others mentioned, I've also come across more bad PMs than good ones. It's tainted my general view of PMs, and I rarely recommend that anyone go into that line of work. It's all too easy to fall into ineffective roles as a PM, and many dysfunctional orgs exist that actively encourage it.
That being said, there are a few good ones, but they mostly come from Agile organizations.
Here are the qualities I've found in the good PMs:
- Strong technical background and highly intelligent. They went into PM not because they were weak engineers, but because they wanted a change.
- They know when to get out of the way of the engineers when they need to. They provide a healthy amount of autonomy rather than being glorified taskmasters.
- They can provide effective "air cover" for the engineers when other groups start hassling them and slowing them down. They view the removal of obstacles as their most important role.
- They know progress is best demonstrated by working applications, not specs, spreadsheets, or charts. They strive to have something demonstrable to the project stakeholders at the end of every iteration.
- They are generally low ego, and don't play political games. They strive for results above all else.
Totally agree.
Would add one more: when there is a problem, they never hide it or ignore it. They face it in a very hands on way and clearly articulate it to all involved in the project.
More likely than who? Anyone else in an organization?
Also, the elaboration of "Providing deep domain knowledge" explains it as deep domain knowledge of product management. The is akin to saying the engineers have deep domain knowledge of engineering, and doesn't explain why project managers are more likely to be lynchpins than other positions. But then again, he didn't mention what these other positions were.
[+] [-] rkuester|15 years ago|reply
Shouldn't engineers with leadership gifts lead more projects where engineering plays a major role? Am I being too engineering-centric to think that suitably gifted engineers could grok the non-engineering aspects of a project better than a spreadsheet pusher can understand the engineering component?
Maybe I've just never worked with a good PM.
[+] [-] kenjackson|15 years ago|reply
And that for me has been one of the defining characteristics of a strong PM. Good questioning ability. Ability to skip to the chase. And they have a suprisingly strong grasp of dependencies. When architect A says, "this is coming in a bit late" they almost instantly are getting the PMs and architects from team X, Y, and Z in the room because they know theres an indirect relationship to these teams also.
I've only worked with one bad PM in my life. We fired him after two months. The difference in productivity, confidence, and general life enjoyment between an bad and good PM is pretty enormous.
[+] [-] adn37|15 years ago|reply
They are communicating, while you are coding. This is of course unbalanced. But personally, the last thing I want to have to do is to update any random person on how things are going, while in the middle of a crunch towards the deadline. The dark side it that I have to deal with a PM who doesn't understand the deep technical aspects and is the 'key' player of the decision process.
> Shouldn't engineers with leadership gifts lead more projects where engineering plays a major role?
Some very talented soft engineers that I know are trying their best to stay away from project management. It's how things are.
[+] [-] hkarthik|15 years ago|reply
That being said, there are a few good ones, but they mostly come from Agile organizations.
Here are the qualities I've found in the good PMs: - Strong technical background and highly intelligent. They went into PM not because they were weak engineers, but because they wanted a change.
- They know when to get out of the way of the engineers when they need to. They provide a healthy amount of autonomy rather than being glorified taskmasters.
- They can provide effective "air cover" for the engineers when other groups start hassling them and slowing them down. They view the removal of obstacles as their most important role.
- They know progress is best demonstrated by working applications, not specs, spreadsheets, or charts. They strive to have something demonstrable to the project stakeholders at the end of every iteration.
- They are generally low ego, and don't play political games. They strive for results above all else.
[+] [-] carusen|15 years ago|reply
[+] [-] ganjianwei|15 years ago|reply
Also, the elaboration of "Providing deep domain knowledge" explains it as deep domain knowledge of product management. The is akin to saying the engineers have deep domain knowledge of engineering, and doesn't explain why project managers are more likely to be lynchpins than other positions. But then again, he didn't mention what these other positions were.
[+] [-] techdmn|15 years ago|reply