6 ms·

This is in pretty stark contrast to yesterday's article about devops: > Somewhere along the way, however, we tricked ourselves into thinking that because, at a

This is in pretty stark contrast to yesterday's article about devops: > Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once. > What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (while doing less, less useful work) and lower-level positions simply don't exist. > Large companies love this, as it means they can hire far fewer people to do the same amount of work. In the process, though, actual development becomes a vanishingly small part of a developer's job. http://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/ http://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-t... I certainly wouldn't be happy with a developer position that made me do tier 1 customer support. That stinks more of "absurdly cheap" than "connecting with customers."

sunir 13y ago
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.
- chris_mahan 13y ago
  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.
- quanticle 13y ago
  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 https://plus.google.com/+RipRowan/posts/eVeouesvaVX
  - sunir 13y ago
    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.
bcx 13y ago
Brian great comments, but I think there are a few things to think about from Jeff's comments. Having an engineer respond to level-1 support is actually incredibly expensive. Especially, given that you could hire someone else who had a job specifically to respond to those issues. In the cases where companies do choose to put engineers on frontline (once they've scaled to the point they can afford to hire dedicated support), they need to make a choice about the kind of organization they want to build. The organizations Jeff is talking about and the one you are alluding too sounds like a pretty horrible place to work, where people are overworked, and resources are not allocated where they need to be to move the product forward. Building a great organization is a challenge, and we choose to build an organization where everyone on the team has a strong connection to the customer. We do this with a strong understanding of how our team wants to grow and specialize. When done right, all hands customer service can work really well to align the team around the customer. But you point is well taken, at many startups this idea that engineers should be doing "one more thing", when they are already responsible for "all the things" could be overkill. My advice would be to first figure out how to divide up responsibilities so people could focus, and then have teams interact with their customers every once in a while to remember what it's like to use their product. I think you'll be surprised at how many engineers actually enjoy talking to the people they are building their product for.
varkson 13y ago
I feel the opposite. I'm a dev who is also support. I don't generally get the 'please reset my password' kind of requests, as we don't get them very often, but help users with our system and work on fixing bugs they report. I find you get a different perspective on what customers find easy and hard and this helps me develop my projects in a way that our customers will understand.

sunir 13y ago

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.

chris_mahan 13y ago
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.
quanticle 13y ago
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 https://plus.google.com/+RipRowan/posts/eVeouesvaVX
- sunir 13y ago
  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.

bcx 13y ago

Brian great comments, but I think there are a few things to think about from Jeff's comments. Having an engineer respond to level-1 support is actually incredibly expensive. Especially, given that you could hire someone else who had a job specifically to respond to those issues. In the cases where companies do choose to put engineers on frontline (once they've scaled to the point they can afford to hire dedicated support), they need to make a choice about the kind of organization they want to build. The organizations Jeff is talking about and the one you are alluding too sounds like a pretty horrible place to work, where people are overworked, and resources are not allocated where they need to be to move the product forward. Building a great organization is a challenge, and we choose to build an organization where everyone on the team has a strong connection to the customer. We do this with a strong understanding of how our team wants to grow and specialize. When done right, all hands customer service can work really well to align the team around the customer. But you point is well taken, at many startups this idea that engineers should be doing "one more thing", when they are already responsible for "all the things" could be overkill. My advice would be to first figure out how to divide up responsibilities so people could focus, and then have teams interact with their customers every once in a while to remember what it's like to use their product. I think you'll be surprised at how many engineers actually enjoy talking to the people they are building their product for.

varkson 13y ago

I feel the opposite. I'm a dev who is also support. I don't generally get the 'please reset my password' kind of requests, as we don't get them very often, but help users with our system and work on fixing bugs they report. I find you get a different perspective on what customers find easy and hard and this helps me develop my projects in a way that our customers will understand.