Hacker News Reader

Comment by taylodl | Hacker News Reader

Absolutely true - but at the end of the day some one has to be vested with making the final decision. That's what Product Managers are for, they're vested with making the final call. As you point out, good Product Managers won't be overbearing overlords just like good engineers aren't simple order takers.

View on HN

Which decision?

How a feature UX should work based on the PM having a fair bit of expertise in the field? Maybe.

What task you work on next? Maybe not.

You see the problem with letting someone who's not an expert in the work decided the work goes both ways. The PM is in charge? Good luck getting patching on the backlog. Don't consult the PM? Good luck getting the functionality right.

My takeaway is the PMs often aren't the experts in writing, maintaining, or running a production system, thus they probably shouldn't actually run the backlog. But said production system is pretty useless without market fit, so you want to strongly align with whoever your version of a PM is.

If you can't get a fix into the backlog either the details of the bug aren't explained well enough or the fix isn't as important as you might think.

I can relate to my first job out of college. I had my first triage session and I was shocked by how many bugs we wouldn't fix. I wanted to fix them all - in fact I stood up and said, "how can we not fix these, these are real bugs!" I eventually learned that the job of SW isn't engineering purity. It is to apply available resources to maximize impact for the customer (and if this is at a for-profit company, to maximize profit). I think sometimes developers can get stuck on just writing the best code possible, and forget the actual reason there is someone giving them a paycheck.

I'm not sure, there's something good from that fresh perspective: why do we have software that's that broken and why do we think this is normal?

We've given up on logical systems and we deal with so much complexity that we're dealing with kind-of-biological systems where reasoning about the system is not possible anymore.

The Product Manager owns the what?, they don't own the how? or how long?. They're getting feedback and directing the sales team, the marketing team, the engineering team, the UI team, the QA team and the support team. It should be easy for a competent engineering team to get patching on the backlog - after all, that's table stakes. Organizations struggling with the mundane is the very definition of dysfunctional.

But very common.

Which goes back to the point, maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate, but not direct the others groups, whom are the actual experts of their respective areas.

maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate - absolutely agree! However, there are many teams involved and sometimes they have conflicting priorities and/or proposed directions. Some one has to be responsible and make the call. That's the Product Owner's job. Maybe this needs to be said, you can be the perfect Product Owner but that doesn't mean someone isn't going to be butt hurt over a decision you made. It just comes with the territory of being a leader.

Sure, but again, why's my _leader_ the non-technical person?

Listen, I've been around the block and I understand it's quite common for the PM or other similar softer roles to be given leadership.

I've seen this to the point where they both recruit and promote the techs themselves.

What I'm saying is it doesn't have to be like this. If the PMs job is to find and articulate value, and the Engineers job is to produce said value, on a well performing team, it's a match made in heaven.

A poor PM with dominance over tech will happily torpedo the Engineers career with little emphathy whilst doing so, so why do we assume tech leadership should be in a different department?

My opinion is align the Engineer KPIs with value, which aligns them with strong PMs, but allow them the autonomy to say no when it makes sense to.

Just an opinion tho :)

Reply on news.ycombinator.com