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

141–150 of 221 posts

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

#141

Post by Nadya »

wahern wrote: post #129
Nadya wrote: post #119

Earlier quoted context omitted.

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…

> I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And e…

> In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head.

A joke exists about how developers will never be displaced by AI because that would require clients and/or project managers to accurately describe what they want the AI to build. On one hand that is extremely egotistical of developers. On the other it is also factual.

To my understanding of the story the developers had designed what was being communicated to them by someone who described what customers asked for and not what the customers actually wanted or needed. Nothing to do with what the engineers thought customers wanted and everything to do with what project managers had expressed to the engineers about what customers wanted. Speaking with the customers directly gave them a better idea of what was actually being asked for. So they built that instead.

My takeaway from the story is to fire the project manager. Not to make devs call clients.

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

#142

Post by ilc »

jacquesm wrote: post #75
ilc wrote: 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…

Yes, god forbid that an engineer would be contacted directly to solve a problem they have. The thought alone.

Yes, god forbid people escalate their issues properly so they go to the right people. The thought alone.

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

#143

Post by lavelganzu »

hinkley wrote: post #124
trevor-e wrote: post #110

Earlier quoted context omitted.

You can never rely on support reps to escalate UX issues to product teams for a couple reasons. First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind. Second, it's not in their interest to report UX issues. They are mea…

Perverse incentives. They are judged by how long the call takes, and every time they escalate a common problem that the devs could fix, now their numbers will go down and they'll get punished for their good work. Dell at one point pulled the plug on outsourcing their tech support. They spotted this moral hazard partway through the process and decided it was better to keep it in house.

On the opposite side of moral hazard, early in my career I worked for a large web security company in tech support. We were not permitted to escalate to engineering at all. Often this meant the only solution was to apply our own, unofficial code changes!

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

#144

Post by uberduper »

I worked at a place that made a robo-calling sales crm and they thought it would be great if during an offsite they had everyone use it to cold call places and run through some script they'd prepared. They didn't seem to understand nor care about what sort of anxiety that could cause not-sales-people. That's when I decided to start looking for another job.

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

#145

Post by wahern »

Nadya wrote: post #141
wahern wrote: post #129

Earlier quoted context omitted.

> I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And e…

> In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. A joke exists about how developers will never be displaced by AI because that would require clients and/or project managers to accurately describe what they want the AI to build. On one hand that is extremely egotistical of developers. On the other it is also factual. To my…

Product and project managers can have similar issues of perspective as engineers, chasing trends in the industry or losing the forest for the trees (feature checklists, etc). But, yeah, having devs talk directly to customers can be problematic. If you give a customer a direct line to an engineer, sometimes they can monopolize the engineer's time (they feel they can leverage an "inside" contact) or skew their priorities. Having engineers work closely with tech support is a good middle ground, such as by fostering 1:1 relationships with support or even fielding tech support tickets themselves (tech support tickets have more finality than, e.g. sales support issues). That way they can get a broader perspective on pain points and potential new directions. It can really help refine a product beyond what can be achieved by lobbing feature and bug tickets over a fence or through formal group meetings (which often can be either too structured or too chaotic).

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

#146

Post by toss1 »

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…

Don't blame it on the PMs (except to the extent they are separating the engineers from the customers).

The closer you can get the engineers to the users, the better your product will be, and this goes all the way to the backend and architecture.

This is true no matter how skilled and well-intentioned are the PMs or sales reps.

I've seen one single layer between the builders and users to help modulate high and constant user demand can help.

Beyond that, even two layers can strangle a project. One project my company was doing for IBM was moving along nicely with the developers talking to the actual users every few weeks as progress was made & delivered. I moved off the project, then IBM inserted a manager to "consolidate the communications" (take all the users' input and boil it down), and a manager at my company (not the engineers) talked to him. The project became one of those endless slogs of feature creep, yet no great success — ultimately deployed for some years, but not the resounding improvements in workflow efficiency they hoped and saw in the beginning.

Absolutely EVERYONE on both teams was competent and really wanted the project to be a great success. But adding the intervening layers, while it seemed more efficient, had only the opposite effect.

Seriously, it ALL happens where the rubber meets the road. Get your developers as close to the end-users' keyboards and screens as possible. Talking directly to the users is great. Even better if you can arrange to have them BE a user for a day or two.

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

#147

Post by codyb »

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…

Engineers being completely out of touch with the macro picture of the end user experience is the norm, and it's bad.

Engineers work micro features which are sliced out of micro picture epics with maybe a vague Northstar.

Sitting engineers with users is a key thing I'm driving at my work since we're on internal tooling. Pretty much to a tee every participant comes out and goes "Wow... I had no idea that's how people were using our product"

Building user empathy results in greater connections within our organization, puts names to faces in our support channels, and results in more well rounded engineers who develop software with both technical and end user experience concerns in mind.

I mean, there's a reason most software interfaces are still shit, and often physical products too. It's cause we take tons of input from people who haven't extensively thought about user experience a day in their lives

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

#148

Post by tdb7893 »

m463 wrote: post #19

All the negative responses. I have been at countless places where the engineers are out of sync with the product. And it might be something silly like their coworker added something they didn't know about and the UI is now confusing. Could even be the website started proclaiming something that didn't align well with the product. Another factor is that the [product -> PM -> bug system -> engineer -> fix -> QA -> produ…

Yeah I think having engineers understand product is important as I think it's the harder to get right than the basic engineering. Most of the products I've worked on have failed for product reasons so just from a logical standpoint it makes sense to focus on making sure that's a strength for a team.

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

#149

Post by mathattack »

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…

My experience is every layer between the communicator and the recipient adds noise. It's like the game of telephone we played as kids. Some PMs are terrible and are 100% noise. Even the best are only 50% signal.

Give an engineer a clear understanding of the end need, and you have a tremendous gain in efficiency. I think there is a 10X benefit here that's similar to the 10X benefit from stronger engineering skills.

You still need PMs, though it's a different job that passing papers back and forth.

Post reply on HN