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

211–220 of 221 posts

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

#211

Post by lmm »

sfn42 wrote: post #207
lmm wrote: post #196

Earlier quoted context omitted.

It can be the engineer's fault if it's an engineering mistake. But bad process is the fault of the people who control the process and bad product management is the fault of the people who control the product management.

As a developer I work closely with my managers and designers etc to ensure that our project goes smoothly and that we create a good product. I don't necessarily decide what we build but I have a lot of ways to influence what we build and how. We talk about stuff, we plan stuff, I chip in and people listen. Whenever I see devs complaining about how terrible their project management is I think to myself that the dev is…

In my experience the kind of project management that doesn't value engineering input on technical matters tends to be exactly the kind of project management that doesn't value engineering input on process changes.

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

#212

Post by andrekandre »

godelski wrote: post #210
ccakes wrote: post #209

Earlier quoted context omitted.

I kind of think this is correct but not for the reason you think. To most engineers, users are the annoying thing on the other end of a ticket. They “don’t know how to use the product properly”. I’ve also had great success dropping engineers directly in front of customers. I think it’s just because it humanizes the person behind the ticket

I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When…

  > Honestly, I think the biggest roadblock to this strategy is the constant push for rushing.
ironically, giving more time upfront can make things faster because people now have time to make a proper implementation, so you have less rework/qa cycles...

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

#213

Post by godelski »

andrekandre wrote: post #212
godelski wrote: post #210

Earlier quoted context omitted.

I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When…

> Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. ironically, giving more time upfront can make things faster because people now have time to make a proper implementation, so you have less rework/qa cycles...

I don't think it is ironic, but makes perfect sense. It's about the marathon strategy.

I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing with time is that if you finish ahead of schedule you can just go onto the next thing. It's always better to finish ahead of schedule than behind. But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.

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

#214

Post by mschild »

hinkley wrote: post #126
Eddy_Viscosity2 wrote: post #51

Earlier quoted context omitted.

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.

But after the next release the number of calls per hour the customer support team can answer will drop. Which means no raises for the support people.

Then incentives and (I hate this word) KPIs aren't aligned. That's arguably a somewhat separate problem though.

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

#215

Post by mschild »

Eddy_Viscosity2 wrote: post #51
mschild wrote: post #50

Earlier quoted context omitted.

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.

Yes, fully agree. Like I said: solving a customers problem is top priority but regardless of the solution it should be documented and shared. At minimum it can give pm and engineers insights into common issues and potential improvements.

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

#217

Post by andrekandre »

godelski wrote: post #213
andrekandre wrote: post #212

Earlier quoted context omitted.

> Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. ironically, giving more time upfront can make things faster because people now have time to make a proper implementation, so you have less rework/qa cycles...

I don't think it is ironic, but makes perfect sense. It's about the marathon strategy. I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing…

  > It is hard to predict disaster, but you can prepare for it.
yes, you need slack to deal with inevitable surprises and delays that will occur so that you can actually make it 'in time'

  > But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.
this is counterintuitive for a lot of people and especially for managers under pressure from above

running without slack means every bump in the road adds a delay which makes the manager's troubles even worse when they have to report the inevitable delay (which leads to a negative spiral of rush-and-delay)

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

#218

Post by sfn42 »

lmm wrote: post #211
sfn42 wrote: post #207

Earlier quoted context omitted.

As a developer I work closely with my managers and designers etc to ensure that our project goes smoothly and that we create a good product. I don't necessarily decide what we build but I have a lot of ways to influence what we build and how. We talk about stuff, we plan stuff, I chip in and people listen. Whenever I see devs complaining about how terrible their project management is I think to myself that the dev is…

In my experience the kind of project management that doesn't value engineering input on technical matters tends to be exactly the kind of project management that doesn't value engineering input on process changes.

If I started a new job and it became clear to me that my superiors just wanted me to shut up and do what I'm told, I would be looking for a new job immediately.

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

#219

Post by godelski »

andrekandre wrote: post #217
godelski wrote: post #213

Earlier quoted context omitted.

I don't think it is ironic, but makes perfect sense. It's about the marathon strategy. I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing…

> It is hard to predict disaster, but you can prepare for it. yes, you need slack to deal with inevitable surprises and delays that will occur so that you can actually make it 'in time' > But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead. this is counterintuitive for a lot of people and especially for managers under pressure from abov…

  > running without slack means every bump in the road
I think you ran into maybe a good analogy here (spitballing). To go fast on a bumpy road you need slack, in your shocks. You have to absorb those bumps. But if you have no shocks you just rattle apart.

Sure, a rally car isn't as fast as nascar, but which environment are you in? Super smooth road with only left turns and is built to allow you to go as fast as possible? Or literally anything else.

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

#220

Post by andrekandre »

godelski wrote: post #219
andrekandre wrote: post #217

Earlier quoted context omitted.

> It is hard to predict disaster, but you can prepare for it. yes, you need slack to deal with inevitable surprises and delays that will occur so that you can actually make it 'in time' > But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead. this is counterintuitive for a lot of people and especially for managers under pressure from abov…

> running without slack means every bump in the road I think you ran into maybe a good analogy here (spitballing). To go fast on a bumpy road you need slack, in your shocks. You have to absorb those bumps. But if you have no shocks you just rattle apart. Sure, a rally car isn't as fast as nascar, but which environment are you in? Super smooth road with only left turns and is built to allow you to go as fast as possib…

> You have to absorb those bumps. But if you have no shocks you just rattle apart.

yes, and the real issue is, there are no smooth roads (ime anyways)

> Super smooth road with only left turns and is built to allow you to go as fast as possible?

whats interesting is, from a high-level perspective, riding with shocks (slack) can feel more like nascar than rally even if the day-to-day has bumps.

and of course, aside from slack, there are other things that help get to "nascar" such as good specs, good/easy architecture, low-interruption/async communication, and good management, but even then its just reducing the likelihood of bumps...

Post reply on HN