Live data from Hacker News

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

old.reddit.com

61–70 of 221 posts

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

#61
IMO this stuff happens frequently because the layers between engineers and users (IE product, project management, executive leadership) are crap and blaming the engineers for it.

Not that engineers can't be problematic. But product people who aren't technical enough and badly manage trade offs they don't understand or invent out of thin air outnumber engineers who are pigheaded know it alls more obsessed with technical minutae than product success.

Another one I see in the same ballpark is hiring a bunch of outsourced coders and then wondering why velocity and quality goes down. (Because you're multiplying the mythical man month effect by the skill difference between a day laborer from Home Depot and someone with significant skills/domain knowledge like a welder or electrician.)

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

#62

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

That has been my experience in multiple occasions, the moment i can sit with a customer and clearly discuss what their needs are and see them operating the tools, it makes the real user experience and workflow issues much easier to fix.

Glad I'm at a place where i can talk directly to people instead of having to go through layers of indirection. I takes away from my engineering time but now i'm always building the right thing, so it is much more productive.

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

#64
post #55

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…

Assuming your PM is for product manager not project manager. I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault? I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE…

There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course):

- The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements.

- The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear.

In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.

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

#65
post #41
post #34

Earlier quoted context omitted.

I wonder if LLMs might be replacing these type of PM jobs where they gather up feedback (usually it's mostly in text form anyways), and translate and summarize so engineers can cut out some noise and confusion from PMs.

Ok, LLM translated and summarized. Then what? Someone needs to look at it and push important points. Sometimes it's hard to push engineers, until they visit some calls and push themselves.

Sure, I know there's companies like that, but just as often in my experience engineers are spoon fed tickets without broader context. In many cases are also treated like an interruption if you want to discuss to root issues etc with PMs

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

#66

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

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

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

#67

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

Sadly, I've seen a significant number of engineers who simply don't trust what PM's say about what the customers need.

They think PM's don't provide value, so they ignore what PM's say.

It's only when they hear from customers directly that they go... oh, so these needs are real? I thought it was just PM bullshit.

In a healthy workplace this doesn't happen. But sometimes engineers need to talk to customers to trust that the stuff their PM has been telling them is actually true. And then the relationship becomes more collaborative and trusting.

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

#68
> The rewrite took 2 weeks. We removed 60% of features. Added a simple progress bar. Built Slack integration for questions. Created "done-for-you" workflows.

> Our support tickets dropped 70%.

If this isn't fake something is extremely wrong with this picture.

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

#69
post #42

As an engineer, there's only one reason I don't want to be on customer calls: Once a customer knows the person who actually builds the product, they will short cut: - Customer Service - Product Management - Any other sane defenses you put in to protect a developer's time. And just contact me directly. Then what do I do to get them off of me without losing a customer? ... That is why engineers don't get on support cal…

personally I think the customers and I both get some value out of our interactions. but I normally don't sit on customer calls. why? because half of the time I screw up the sales aspect by saying

   - the salesperson told you what? no, we don't do anything like that
   - oh, yeah, this is easy, you don't really need our product, just use X
   - yeah, we have vague plans to do that, but no real schedule. its gonna be a major lift
   - once we finish coding and testing that, its gonna be great!

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

#70

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

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

Post reply on HN