Comment by hnthrow0287345

15 hours ago

I've had good PMs answer most of this themselves. Only if there's a technical detail they don't know about do they then ask specifically.

OTOH other PMs throw vague jira-shit over the fence because they know how to take advantage of seniors who have been taught to reflexively work out the details even though it should be PM's job, just like this right here:

>So we end up with “senior” engineers who can reverse a binary tree on the whiteboard but freeze when the spec is half-baked.

The story here should be "the senior engineer is senior because they tell the person responsible for the specs to not half-bake their specs", not "senior engineer is senior because they fixed someone else's incompetence", but even then, there is likely a manager that should be demanding that before the senior does.

Some of you senior engineers are less senior than others, and what I've continually seen is early senior engineers covering for other people (like half-baked specs). Eventually they learn that maybe a PM/Design should put some effort into a spec and covering for them means more work without compensation, and they stop fixing the laziness.

If you have PMs answering the how of issues such as "we need to improve performance" or "we should probably think about scaling", then the senior engineer on the team is the PM, not you.

The list of example questions at the bottom is clearly not exhaustive.

  • Sure, those two specifically can be handed off because they involve basically no user journeys for the product and a PM can't reasonably be expected to know the technical details of performance or scaling. But any PM or engineer should be able to at least ask "is the performance bad everywhere, or only specific things"?

    But a PM absolutely should be diving deeper to get more details on "users are complaining about the onboarding flow" and figuring out what should be fixed or what the ideal onboarding flow should be before involving an engineer. The exception of course is the onboarding flow has errors or is slow, which again the PM is not responsible for.

> fixed someone else's incompetence

This is basically a full-time job for many senior engineers. It may as well be the job description. Thing is, most of these 'leaders' are not capable hiring competent engineers - as if they're capable of identifying competence. You do not want to end up at one of those organizations - but they are everywhere.