A PM's guide to communicate effectively with software engineers

Re:A PM's guide to communicate effectively with software eng... by kungito on Monday February 21, 2022 @04:55PM (#30421151)

Half my company has this much talky talky time and its horrible for efficiency. I work on internal tooling so requirements are more clear, I spend 2-3 hours a week in meetings and I'm 3x more productive than them. My feeling is the biggest issue for the engineers spending time in meetings is that PMs are very bad at seeing technical challenges in what they are selling so there needs to be a lot of time wasted of more technical people helping them finalize the spec. In Micosoft PMs had a lot more technical background/former programmers so way less dev time was wasted in meetings

[ Parent | on HN ]

Re:A PM's guide to communicate effectively with software eng... by TameAntelope on Monday February 21, 2022 @05:05PM (#30421251)

I can imagine the time may seem wasted to a developer if your focus is on personal productivity (which seems to be the case since you cite your productivity rather than your team's productivity), but the lost value is in making sure what you're building is aligned with what your customers need.

The fact that you're talking about "spec" here, in addition to your focus on individual productivity makes me wonder if what you're doing fits in with what's described in what I linked (the Agile Manifesto).

Agile isn't for every team, and you can succeed despite not communicating, but there are risks and costs involved that, if made explicit, would not likely create costs you or your team would actually want to pay.

[ Parent | on HN ]

Re:A PM's guide to communicate effectively with software eng... by nicoburns on Monday February 21, 2022 @06:03PM (#30421911)

I totally agree that aligning with customer need is more than worth the time taken, but that shouldn't be taking 50% of developers time. More like 20% in my opinion. Internal collaboration between devs can take another large chunk of time, but that depends on how experienced (and how good) the developers are.

I've worked on teams with all senior developers where the dev collaboration was mostly covered within that 20%, and minimal synchronisation was needed because we were all on the same page. I've also worked on teams with lots of junior developers, and that did require a lot more detailed planning and discussion that probably did take us close to 50% discussions overall. It was probably a necessary evil, but I wouldn't call it efficient, and it certainly isn't necessary in all cases.

[ Parent | on HN ]