Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I forced every engineer to take sales calls and they rewrote our platform

old.reddit.com

Post reply on HN
Print view View original

151–160 of 221 posts

Re: I forced every engineer to take sales calls and they rewrote our platform

#151

Post by strken »

PaulRobinson wrote: post #26
dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

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…

> 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.

Re: I forced every engineer to take sales calls and they rewrote our platform

#152

Post by Bender »

I've seen something like this before. A monitoring team said that front-line engineers should be opening tickets for every alert that came in. There were upwards of 10,000 unique alerts per hour. Critical issues had been missed due to all the noise. The directors and VPs got an earful enough times that they forced the monitoring team to open tickets for all the alerts and troubleshoot them. The next day the system was down to about a dozen unique alerts per hour after excluding informational alerts and the remainder were eventually closed out. It was the first time the boards had all been green for real this time vs. painting them green for the media and the Gartner Group.

Re: I forced every engineer to take sales calls and they rewrote our platform

#153

Post by neilalexander »

sillywabbit wrote: post #66
general1726 wrote: post #52

Earlier quoted context omitted.

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

God forbid an engineer should have an opinion on UI/UX.

I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge them, which is essentially what talking to your users achieves.

Re: I forced every engineer to take sales calls and they rewrote our platform

#154

Post by rstuart4133 »

perrygeo wrote: post #33
dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

Yep, notice there was no mention at all about why the original software was so ill-designed in the first place. Not even a curiosity as to why. Your conclusion is more valid, though I wouldn't necessarily place the blame on the PM. Agile/Scrum rituals, where blame is diffused and developers are forced to sprint quickly through poorly-designed tickets, yields poorly-designed software. Who could have guessed? Feels lik…

> Yep, notice there was no mention at all about why the original software was so ill-designed in the first place.

All software is ill designed in the first place. Even software I write to solve my own problems will usually do a poor job of solving that problem on the first iteration.

There is a reason old engineers say: "Plan to throw the first one away. You will anyway."

Re: I forced every engineer to take sales calls and they rewrote our platform

#156

Post by matheusmoreira »

general1726 wrote: post #52
dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

> People around Desktop Linux could write a complete book about dismissing user's complaints.

On Linux we enjoy flexible systems that empower us to change the things we don't like all by ourselves without any need to involve any "project managers" at all.

And it's completely fine if Linux systems are built around the needs of programmers and power users. It's not like normal users are paying us. Linux users should focus exclusively on themselves and their own needs.

Re: I forced every engineer to take sales calls and they rewrote our platform

#157

Post by yAak »

> Because they finally understood who was actually using our product.

Yes!!!

> The biggest problem with most engineers is actually over-engineering.

Err, wait, go back to step 1. Over-engineering is sometimes a byproduct of not understanding the customer use cases. That lack of understanding is the biggest problem.

So, I’m an “engineer” —- my most common frustration with other engineers is their lack of interest in understanding of the actual product being sold. In my experience, sometimes the reason is job-fit issues, sometimes it’s ego, but usually it’s a combination of culture and incentive.

Re: I forced every engineer to take sales calls and they rewrote our platform

#158

Post by uberduper »

Nadya wrote: post #119
general1726 wrote: post #52

Earlier quoted context omitted.

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor? I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't design…

> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?

Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.

Re: I forced every engineer to take sales calls and they rewrote our platform

#159

Post by [deleted] »

general1726 wrote: post #52
dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

[deleted]

Re: I forced every engineer to take sales calls and they rewrote our platform

#160

Post by 9rx »

PaulRobinson wrote: post #139
9rx wrote: post #37

Earlier quoted context omitted.

> 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 learne…

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…

> 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?

Post reply on HN