Hacker News Reader

Comment by conrs | Hacker News Reader

I've had a very hard time with the Product Manager discipline. From the books and podcasts like Lenny's, it all makes perfect sense, but it seems like in practice it is as you described - they've inserted themselves in between and often don't represent either side well. It's lead me to develop product management skills myself, which are honestly incredibly useful in avoiding wasted effort. But it does make me wonder whether the dichotomy is worth it or if product management should be part of a senior engineer's skillset.

View on HN

That makes me think.

I never really worked with a PM that was good at preventing wasted effort. Or even mediocre at it. Most assumptions I saw them making were incorrect, unless it was a VERY SIMPLE product.

To me this is something that engineering should be doing, just like splitting tasks and double-checking designs.

Of course not every engineer can do it, but some of us have been doing it, negotiating deadlines and deliverables our whole careers. So I don't really understand why our industry insists on having us throw away those abilities.

On the other hand, I've seen engineers make unilateral decisions that had completely unacceptable UX or ops impacts, that didn't align to the original design spec, and that they didn't think to tell anyone about until way down the road.

Everyone needs a counterpart to "trust but verify".

At my company, engineering managers are ultimately responsible for the deadlines and deliverables. It's an anti-pattern for PMs to also be the project managers - that is a bad combo and it should either be owned by the EMs or a dedicated role.

Sure, but my point is that certain tasks that people believe to be the responsibility of PMs is better done by engineers, IME.

And your example is also a good one, I totally agree, PMs managing deadlines is also not a good idea.

Yes, I feel like most Product Managers I’ve worked with are more like Project Managers - all about deadlines, largely just accepting requirements rather than refining, etc.

That and having knowledge of the constraints helps us build the best systems. Often I’ll see Product decide an initiative is a 2 quarter affair, then from then on it is always in the backlog, never to be worked on. Meanwhile we could deliver the first increment of value next week with a little strategy applied - had we even been consulted.

Frankly, for me, the best value product managers can provide is being the buffer and/or unblocker. I want other team C to do task X, because it unblocks my team and others, but somehow I can't convince team C to do it. Well, that becomes the product managers job. They _should_ know the path to delivery and understand why this is important and negotiate with team C to drop other stuff to deliver X. And they can tell anyone above team C why this is happening. And I have worked with some product managers like that, but unfortunately they are rare, and most just get bullied by stronger willed (obstinate) tech teams. It isn't an easy job.

I'm quite fortunate that at the moment I have a great relationship with all of our peer teams and we generally sort it out amongst ourselves. We don't have a product manager involved at all for the last few years.

IMO a lot of the product managers inserting themselves and being useless is good old school project managers pivoting to the new thing and doing the same old stuff. Likewise I do think product management should be part of the senior engineers skillset. Its incredibly useful. Conversely, there are also tons of engineers that dont have this mindset and want a PM to tell them what to do and a barrier from the rest of the organization... which boggles my mind to be fair

Yes, a lot of folks really don’t want to have to care about work. I think it’s simply rubric achieving - them playing out the same thing they did in school. Operating under the constraints of their roles only enough to sustain them, so they can enjoy their lives at recess, so to speak. I get it, though - engineering can’t be everyone’s passion, there must be quite a lot of us just here for the lifestyle.

That's an interesting observation. After some thinking, I agree. It was quite hard to get the PM that replaced me out of the "project management" mindset when she joined.

Also agree about engineering needing to have the PM skillset. Especially in startups.

As a PM I've always held the opinion that I'm genuinely not needed for a ton of work if the lead engineer is reasonably product-minded and understands current customers. Most existing customer pains are plainly evident and so long as it's not a wild amount of work, my job is to just give a thumbs up and move on.

Where it gets nasty is the new opportunities. Assuming your system of patronage at a company is a good one, there's a lot of work in finding new opportunities in the first place and testing them out. And often the cat herding of developers who do some of this (great!) but want to just run wild without testing any of their assumptions (not so great!) and trying to balance the excitement and creative forces with whatever framing is needed to satisfy others in the company. That gets most complicated when various stakeholders hold opposing positions on "what we should be focused on", and if you don't have a PM absorbing that damage for you, you're just going to end up doing that all day instead of building software.

One of the functions Product Management is to be an intermediary between the business/sales and Engineering. Sometimes you might have issues working with Product Management, but you don't want to interact and build features for a bunch of stressed sales folks, so they can make their quota.

It would be very hard for a company to build a sustainable business that way.

any concise introduction into those skills you could recommend?

I forgot to follow up here, so apologies for the delay. Honestly, concise is a challenge here. Here is a lot of words, and they barely scratch the surface, but just in case they might be helpful:

- Embracing the idea of a manual valuable process is a great one - as engineers we often want to start by automating and/or building, and dive right in - only to realize later we either didn't understand the product, or our stakeholder didn't and now wants changes once they've seen what it does. (Deeper dives here: "Escaping the Build Trap"[1], "The Minimalist Entrepreneur"[2]

- Understanding negotiation is extremely helpful as you are often operating under constraints, and need to get those across to your stakeholders such that you can both move forward together. Negotiation is basically about aligning two stakeholders with different goals and arriving at an arrangement they can both live with. (Highly recommend "Negotiate without Fear"[3])

- Another excellent concept surrounds the theory of constraints and getting good at recognizing bottlenecks, and subordinating all other processes to them. Essentially, if work is piling up somewhere, look at where it is coming from, and attempt to re-route those efforts to something productive (the bottleneck moves the same speed regardless of how much work is piled up in front of it). The classic book on this matter is "The Goal"[4] but a fun retelling more oriented around an IT department is "The Phoenix Project"[5].

[1] https://www.amazon.com/Escaping-Build-Trap-Effective-Managem... [2] https://www.amazon.com/Minimalist-Entrepreneur-Great-Founder... [3] https://www.amazon.com/Negotiate-without-Fear-Strategies-Max... [4] https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0... [5] https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

Thank you!

Reply on news.ycombinator.com