Hacker News Reader

Comment by sunir | Hacker News Reader

My experience says that if you're responsible for building a product, it's way cheaper to be directly in touch with the end customer so you can fix what you're building. It's better than having a legion of product managers, sales people, business owners in between you and the user.

If you're a developer who is oriented around building products that sell and are loved by customers, it's pretty addictive to talk to customers to find out what they think of what you built.

View on HN

I disagree quite strongly. In theory it works like you suggest - developers see problems, and they're motivated to fix them in a permanent fashion so they won't ever have to deal with them again. In practice, there are multiple equilibria. The good equilibrium is what you describe and what I've summarized above. The bad equilibrium is that the team is short staffed and developers are too busy putting out fires to actually implement the architectural changes required to prevent the fires from starting in the first place. If you're building an organization where developers are expected to do operations work, you have to think about the latter case. If you don't, you can very easily fall into a trap where your core infrastructure stagnates because developers are too busy coming up with the next hack to fix the ongoing outage to step back and think about broader changes that will make the entire system less painful in the future.

In fact, this is one of the things that Steve Yegge cites in his famous essay [0] about how Google, organizationally, is better than Amazon:

    And their operations are a mess; they don't really have SREs and they make 
    engineers pretty much do everything, which leaves almost no time for coding - 
    though again this varies by group, so it's luck of the draw.

At a small company like Olark, they may be able to get away with this because their product is small, their team is small, and so by necessity they have to do everything. But once their product grows, or their customer volume grows, it's very easy to get sucked into a very painful trap by having your engineers be your ops and your customer support.

[0] https://plus.google.com/+RipRowan/posts/eVeouesvaVX

As they say, there are an infinite ways to fail but only a few paths to success. If your engineering is so out of control you're constantly in crisis mode, you have more important problems than customer empathy. I think that's an orthogonal issue.

It's not about asking engineers to do support because you don't have any support capacity. At Olark, we also have a dedicated customer support team. Same thing at FreshBooks where I used to work that also does all hands support. These teams are professionals, and are responsible for ensuring we have world class support practices.

So, we don't ask the engineers (or marketing or design) to be on support because no one else will do it. It's just the way we keep everyone close to the customer.

The Jeff Bezos story in Steve Yegge's post is exactly the reason why I like working at companies that keep engineers close to the customer. It cuts down the BS of opinionated product people thinking they know what customers want when they don't have real experience with customers.

My experience is that it's a magnitude cheaper to have the developer talk frankly (no managers, marketers, lawyers in the room with them) BEFORE the product is designed.

Reply on news.ycombinator.com