I felt that this was a good article. One thing that may not be evident from reading it is that PM as a discipline has a wide range. Some PMs spend an enormous a

I felt that this was a good article. One thing that may not be evident from reading it is that PM as a discipline has a wide range. Some PMs spend an enormous amount of time in the weeds with engineers doing technical design work, even if there's little coding as their output. Some have practically zero interaction with engineers. But both ends of that spectrum are important. As a PM working on technical products and collaborating mostly with engineers, I'll offer up an opinion on "good" vs. "not so good" PMs that an peer in engineering told me one. In his opinion, a good PM is someone who an engineer may not be able to easily point at specific things and say the PM accomplished them (e.g., some technical breakthrough), but there is an overwhelming feeling that without that PM involved at every step of the way, the team would just not be as successful. Since then I've made it my goal to be viewed in a similar light by engineering partners (though perhaps with more "I can tell you what they accomplished"). Another one that feels missing but it critical when working in large organizations: great PMs can turn a "it's silly we're not doing this, but it's complicated" situation into "I'm so glad we're finally doing this". Big organizations have enormous political barriers to getting things done and the best PMs in those orgs can steadily cut through that bullshit to make something happen.