Hacker News Reader

Comment by superfrank | Hacker News Reader

> I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them.

I hope no one is expecting every individual developer to know the numbers on churn, but I do think it's important that someone on the eng team would know that number. In my experience, some combination of the product manager and the tech lead for the team should have some insight into how the changes the engineers are making affects the customer.

View on HN

If churn is a priority from leadership (and it should be, for any decent sized product), I would expect everyone to understand the factors that play in. You need all your engineers to understand the strategic goals, they are often the best positioned to suggest ideas for fixing them (or can prioritize fixes that are higher impact to priority areas).

And then you have to do the hard thing, which is listen to the engineers (which is why most business folks are fine with keeping the siloing as is.)

I love listening to my engineers. They usually know how to solve something faster and more elegantly then I do.

But I'm someone who will learn enough Node/React/python to understand what can, and can't, be done.

A lot of engineers talk about how business people should listen to engineers.

A lot fewer engineers talk about how they like to listen to business people.

Well, if they dont they get fired :) and I dont like to talk about the business doing things, just working this weekend because they didnt listen for the last six months.

Engineers think (sometimes incorrectly) they could do the job of the business people, in a pinch. Business people know they can't do what an engineer does. This dynamic contributes to why business people respect engineering on engineering decisions, and why engineers don't respect business people on business decisions.

Reply on news.ycombinator.com