Live data from Hacker News

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

old.reddit.com

51–60 of 221 posts

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

#51
post #50

Earlier quoted context omitted.

I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting…

I think a mix of both is best. If support can quickly solve a customer issue they should. But they also should make note of it and pass it along.

If it was the case the customer support simply knows an undocumented work-around that they can solve the problem and provide that to the customer. I mean that works, but a better solution is for that problem to get back to engineering and be fixed once and for all.

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

#52

> 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 knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster.

From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.

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

#53
Once upon a time I was doing some custom enhancement for what was probably our largest customer. The CEO and CTO both gave me different descriptions of what the customer wanted. Neither made any sense. I was out of the loop for this whole discussion, but I did get a forward of an email chain at some point that included the customer, so I ended up emailing him directly with stories for those two descriptions plus a third. The customer replied he needed the 3rd story, the one I came up with. This took at least two months to implement, so that was a lot of waste avoided.

The amount of information that gets lost in hand-offs can be incredible. People directly involved in developing the product really need to be more involved with the customers, but I personally have had only bad experiences with organizations enabling this. Those responding here that they get to in some manner, I'm jealous.

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

#54

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

This story is so close to Office Space I just can’t be sure if this is real life anymore https://youtu.be/m4OvQIGDg4I?si=0wLjJArlXXql33vS

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

#55

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

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 they're in the line of fire.

That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.

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

#56

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

It's one thing to be told (by a PM). It's another thing to believe.

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

#57
My former company used to have engineers sit on sales calls regularly too.

While it was interesting to see what companies wanted and how they were sold our product, it wasn't extremely illuminating.

The features that customers wanted were already on our roadmap, we had one feature that customers found confusing and hard to use, but it was written that way to meet the needs of our largest customer.

Engineering wanted to streamline it but then it wouldn't have met that customer's needs. Eventually we wrote a "lite" version of the feature that was easier to use and turned that on for everyone but the big customer. (but that didn't come about because of engineers sitting on sales calls, we all knew it was hard to use but couldn't change it until it was on our product roadmap.

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

#58
When I was just getting started in programming, the best education I got came from the operations manager at a fossil fuel generating station. Russ Reynolds had a quite pragmatic view of computers as tools. Once I had written the system they wanted, he brought someone in from the plant and carefully explained that he was testing the system I built, and not them. He said "anything that goes wrong is his fault" pointing at me. He also told me to just be quiet and watch.

User looks at system, doesn't know what to do... I say oh, just press F1 for help (it was back in the MS-DOS era), Russ says.. "how is he supposed to know that?"

I was then enlightened.

Every screen after that had "Press F1 for help" on it either on the top or bottom line of text

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

#59
post #18

> 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 could be the case, but I work in a mechanical engineering group as the only person on the team who can write code or automate things with it. We're in a large corporation with a sizeable IT support group that builds a decent chunk of the software in-house, and our team views much of it as terrible. So, I've rewritten applications or supplemented the "terrible" but irreplaceable software with tools to make our jo…

There's 2 ways you can get to working software

1. Professional software engineers that can listen to learn about the problem space and are willing to come to understand that. This takes humility.

2. The people experiencing the problem. They might not write perfect code and it might not be maintainable long term. But their understanding of the problem and pain points is so good that they can solve just that and not write 90% of the code the professionals wrote...

I've seen this over and over again and can only tip my hat to the people that fixed their own problem. Just like for a dev, that means going into an unfamiliar domain and teaching yourself

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

#60
My best projects have been where I code side by side with the actual users or subject matter experts. Built a small business loan approval app for a bank, sat right beside the underwriters. Airport billing system, worked one door down from accounting. They came to standup everyday, you take breaks with them, gradually they feel like they own the product.
Post reply on HN