Most engineers turn up at meetings with product managers with two major problems:

1. They assume they know more than everyone else. Got a guy who has had a problem for 5 years and tried 20 different solutions? The engineers will spend 10 minutes thinking about it, come up with a solution (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot. I've done it myself (which I'm embarrassed to admit), and I've seen it at every level from junior to Staff/Principal in companies large and small. The lack of modesty in software engineering teams is perhaps my #1 peeve with the industry. As a result, they often end up designing terrible solutions.

2. Once they understand a problem and a solution, they are frequently awful at thinking through the solution from the user perspective unless they themselves have experienced the problem. This isn't unusual, it's hard to build detailed empathy for how something should work unless you try it yourself. It can be very challenging to get buy-in for a UX or a UI from engineers without it, so sometimes it's useful to get them sat in the chair trying to do the work themselves.

I'm a TPM (former engineer and engineering manager), who has to regularly wear the "product manager" hat. I can not understate how hard it is to get engineers to read a scope document, understand it, accept that the thing needs to be built, that it needs to be built a certain way from a functional perspective, and while they have free reign on architecture and how it's built, it is not their job to rip each detail to shreds assuming the users, PMs and everyone else involved up to that point isn't a completely brainless moron.

This solution is relatively elegant. He got them to talk to users about the software they built and made them realise they were focusing on the wrong details. That's good. It doesn't mean the engineers can become product managers though.

You still need the PM to own the product long-term, and to deal with the customer relationships as the thing gets built. I will also guarantee that those engineers proposed changes the PM had to push back on because of constraints outside of the engineering team's heads (legal, compliance, needed by customer X, and so on).

Edit: read down into the thread, and this company doesn't have product managers. So he's just hoping engineers can figure it out. Fair enough, the only way to develop that muscle though is to get them in front of customers regularly.

▲

NamTaf 4 days ago | parent | next [-]

> They assume they know more than everyone else. Got a guy who has had a problem for 5 years and tried 20 different solutions? The engineers will spend 10 minutes thinking about it, come up with a solution (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot.

I call this the load-bearing 'just' - as in, 'oh, why don't you just...'

If I catch myself saying or writing that word, I kick myself and think about why I'm doing it. Usually I stop and reapproach my input.

▲

9rx 4 days ago | parent | prev | next [-]

> I can not understate how hard it is to get engineers to read a scope document, ...

Ironically, it is hard because it doesn't consider the user. Scope documents likely seem reasonable for the author living in their own little bubble, dismissing it as something "trivial", but if they actually had to use it like those on the receiving end they would soon realize how horrid and ill-conceived it is. Much like was learned in the original link, once you stop with the bad practices, things become much easier.

▲

PaulRobinson 4 days ago | parent [-]

For my scope documents I spend hours questioning users and validating each step and asking “why don’t you just…?”, and try and boil that down.

Doesn’t matter if you drive VS Code every day though, because that means You Know Better (tm), and to hell with the discovery process.

I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage. Come out without asking many questions and seemingly haven’t listened to a thing.

It’s like engineers just think it’s all beneath them, (and I accept I was a bit like that when I was engineering), so forcing them to do the calls isn’t an awful idea.

	▲	9rx 4 days ago \| parent [-]
		> I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage. I know not everything comes across in a short HN comment, but that truly sounds like a "Why don't you just...?" solution. What does the user of your work actually need? > It’s like engineers just think it’s all beneath them Well, are they wrong? You seem to recognize — and I wholeheartedly agree — that when an engineer throws a "I just did..." solution in front a customer and the customer finds it to beneath them to use, it is the engineer who has failed. The customer is completely justified in pushing back on something that isn't right. They shouldn't have to accept slop just because that's what you delivered. But it seems you aren't willing to hold yourself to the same standard?

▲

strken 4 days ago | parent | prev [-]

> The engineers will spend 10 minutes thinking about it, come up with a solution

This is fine if coupled with a dose of humility. Coming up with obvious solutions then researching why they don't work (or asking an expert) is a good way to understand the domain.

> (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot

This is obviously bad, but engineers often have imperfect people skills. I like to think they're aiming for the first but accidentally end up doing the second.

> it is not their job to rip each detail to shreds

It is an engineer's job to ask questions during planning when they're confused. This feels like it might be bad people skills again, because "ask questions" and "rip each detail to shreds" are in the same direction.