19 ms·

This sort of thing is a very helpful exercise - to any of you who manage developers that work on anything customer-facing, consider setting up a day for them to

This sort of thing is a very helpful exercise - to any of you who manage developers that work on anything customer-facing, consider setting up a day for them to spend fielding customer support contacts for your product. It's amazing how myopic you can get after working on a product for awhile. The time spent in contact with ordinary users who are reporting issues helps to bring you back to reality: how do users typically user the product, what common edge cases do you fail to consider, what are common pain points in the UI, etc.

RangerScience 10y ago
This. I went from engineering to sales (solutions architect, woo!) for almost two years. Amazing experience, and one of the best and most informative parts was actually getting hands-on with the people who use the product. Get a much better idea of what matters, what doesn't, and why.
- HeyLaughingBoy 10y ago
  Yup. Same reason the medical instrumentation company I worked for used to try to get developers to shadow medical lab techs for a day. The things we as developers thought were important were often completely irrelevant to our end users and vice versa.
tomjen3 10y ago
I answer second level support. I hate doing it, but it is true that we get to see some of the things that confuses our customers. Plus it is therapeutic, you are never going to feel like you will look stupid to a support person again.
makmanalp 10y ago
At KAYAK we had these red phones that would ring loudly until someone picked them up, and some technical worker would have to answer it and solve a customer's problem. This was controversial to say the least, for many reasons, but it was also extremely educational to see the misconceptions or worries or troubles that people had about the product you create. I enjoyed these even as a backend developer - often a problem or annoyance that manifests as a very surface-level thing to someone has deep code/architectural implications, and it grounded us to the people we were building things for, instead of striving for the perfect internals and architecture in la-la land.
- crooked-v 10y ago
  Even taking the basic idea as a given, the "someone" part seems far more controversy-causing than just having some sort of basic assigned rotation.
digi_owl 10y ago
Or it can harden your view that all users are idiots, as seems to have happened with certain _nix DE devs...
t1o5 10y ago
If we could put those government folks who signs the contracts to build customer facing government web applications through this exercise.
hbosch 10y ago
This is apparently a strongly recommended exercise offered at Amazon. You can shadow a CS rep and follow along with voice calls, chat support, or whatever. I believe they also have an internal program where, for a day, you can relinquish your "normal" duties and spend your time working in a warehouse, or an Amazon Fresh freezer, or on a delivery fleet* - just for the empathetic experience. * Definitely not sure how accurate this info is. Comes second-hand.
- jon-wood 10y ago
  At the food delivery company I work for part of the onboarding process for all new hires is to have them place an order, handle some customer support calls, go out for a shift with a delivery driver, and shadow one of the shops packing orders. In my opinion its one of the best policies we have as everyone goes into the job with at least some understanding of what we actually do. Working remote I don't get the chance as often as I'd like, but even six years in I still learn new things everytime I go out and actually watch people using the systems and processes we design in the office.
iamatworknow 10y ago
Every developer at my company has to go through roughly 3 or 4 months of just customer support calls before they ever write a line of code. I hated the policy when I was going through it (I mean, what did I go to college for?) but I have to admit it did make me a better developer to know our customers and the industry.
- lacampbell 10y ago
  3-4 months is way too long to spend on that. One month i could just about forgive, but 3-4 month doing something that isn't your real job just to start your real job isn't some super cool progressive forward thinking initiative - it's just plain stupid.
  - bitJericho 10y ago
    It would take at least 3 or 4 months to even become good at customer service, if you had no experience. They probably wanted employees to be good at CS, for whatever reason.
    - iamatworknow 10y ago
      The reason is that the industry in which we work is complicated and full of regulations, and the owner believes that if we really understand our customers we can, as developers, better tend to their needs.
  - PhasmaFelis 10y ago
    It's on-the-job training. Most CS degrees don't teach you shit about anticipating the needs of the typical end user.
    - lacampbell 10y ago
      I'm not arguing against on the job training. I'm arguing against 3-4 months of on the job training before you can write code.
  - 10y ago
imrehg 10y ago
On our team at https://resin.io https://resin.io every engineer takes turns on customer support, something like a 5-day week with a 4-hour shift each day (and each day 4 of those shifts distributed across people), and repeat every few weeks. Sometimes it feels it's a big drain on people's time (for those weeks half your time is on support), but the end result is an amazing amount of learning across the entire team. What are the most important issues at any given time, what improvements would have the biggest impact, etc. It also feels that it makes it very easy to ask help across the whole team to debug any issue you find, as people are very open, supportive, and aware of what this "support-driven" approach requires to work. I'm only half on the technical side, but can find me doing support too. ;)
mastazi 10y ago
My company recently changed its organisational structure. As a result, developers now know about issues that the users of our website are facing (before, those issues were filtered by a non-technical manager and only those that were thought to be 'critical' would be notified to the developers). The above is done by simply CC-ing some specific developers into every customer service ticket (which developer depends on what type of problem the ticket is about). Those developers then investigate and, if needed, communicate with the rest of the dev team and coordinate appropriate action. Since the new policy kicked in 2-3 months ago, we had two main results: - The development team discovered (and rapidly fixed in almost all cases) several bugs that were unknown up until that point. Some of those bugs had probably been present for some time. - The UX/frontend devs had significant feedback and redesigned the interface based on it. As a result, we have a more user-friendly website now.

RangerScience 10y ago

This. I went from engineering to sales (solutions architect, woo!) for almost two years. Amazing experience, and one of the best and most informative parts was actually getting hands-on with the people who use the product. Get a much better idea of what matters, what doesn't, and why.

HeyLaughingBoy 10y ago
Yup. Same reason the medical instrumentation company I worked for used to try to get developers to shadow medical lab techs for a day. The things we as developers thought were important were often completely irrelevant to our end users and vice versa.

tomjen3 10y ago

I answer second level support. I hate doing it, but it is true that we get to see some of the things that confuses our customers. Plus it is therapeutic, you are never going to feel like you will look stupid to a support person again.

makmanalp 10y ago

At KAYAK we had these red phones that would ring loudly until someone picked them up, and some technical worker would have to answer it and solve a customer's problem. This was controversial to say the least, for many reasons, but it was also extremely educational to see the misconceptions or worries or troubles that people had about the product you create. I enjoyed these even as a backend developer - often a problem or annoyance that manifests as a very surface-level thing to someone has deep code/architectural implications, and it grounded us to the people we were building things for, instead of striving for the perfect internals and architecture in la-la land.

crooked-v 10y ago
Even taking the basic idea as a given, the "someone" part seems far more controversy-causing than just having some sort of basic assigned rotation.

digi_owl 10y ago

Or it can harden your view that all users are idiots, as seems to have happened with certain _nix DE devs...

t1o5 10y ago

If we could put those government folks who signs the contracts to build customer facing government web applications through this exercise.

hbosch 10y ago

This is apparently a strongly recommended exercise offered at Amazon. You can shadow a CS rep and follow along with voice calls, chat support, or whatever. I believe they also have an internal program where, for a day, you can relinquish your "normal" duties and spend your time working in a warehouse, or an Amazon Fresh freezer, or on a delivery fleet* - just for the empathetic experience. * Definitely not sure how accurate this info is. Comes second-hand.

jon-wood 10y ago
At the food delivery company I work for part of the onboarding process for all new hires is to have them place an order, handle some customer support calls, go out for a shift with a delivery driver, and shadow one of the shops packing orders. In my opinion its one of the best policies we have as everyone goes into the job with at least some understanding of what we actually do. Working remote I don't get the chance as often as I'd like, but even six years in I still learn new things everytime I go out and actually watch people using the systems and processes we design in the office.

iamatworknow 10y ago

Every developer at my company has to go through roughly 3 or 4 months of just customer support calls before they ever write a line of code. I hated the policy when I was going through it (I mean, what did I go to college for?) but I have to admit it did make me a better developer to know our customers and the industry.

lacampbell 10y ago
3-4 months is way too long to spend on that. One month i could just about forgive, but 3-4 month doing something that isn't your real job just to start your real job isn't some super cool progressive forward thinking initiative - it's just plain stupid.
- bitJericho 10y ago
  It would take at least 3 or 4 months to even become good at customer service, if you had no experience. They probably wanted employees to be good at CS, for whatever reason.
  - iamatworknow 10y ago
    The reason is that the industry in which we work is complicated and full of regulations, and the owner believes that if we really understand our customers we can, as developers, better tend to their needs.
- PhasmaFelis 10y ago
  It's on-the-job training. Most CS degrees don't teach you shit about anticipating the needs of the typical end user.
  - lacampbell 10y ago
    I'm not arguing against on the job training. I'm arguing against 3-4 months of on the job training before you can write code.
- 10y ago

imrehg 10y ago

On our team at https://resin.io https://resin.io every engineer takes turns on customer support, something like a 5-day week with a 4-hour shift each day (and each day 4 of those shifts distributed across people), and repeat every few weeks. Sometimes it feels it's a big drain on people's time (for those weeks half your time is on support), but the end result is an amazing amount of learning across the entire team. What are the most important issues at any given time, what improvements would have the biggest impact, etc. It also feels that it makes it very easy to ask help across the whole team to debug any issue you find, as people are very open, supportive, and aware of what this "support-driven" approach requires to work. I'm only half on the technical side, but can find me doing support too. ;)

mastazi 10y ago

My company recently changed its organisational structure. As a result, developers now know about issues that the users of our website are facing (before, those issues were filtered by a non-technical manager and only those that were thought to be 'critical' would be notified to the developers). The above is done by simply CC-ing some specific developers into every customer service ticket (which developer depends on what type of problem the ticket is about). Those developers then investigate and, if needed, communicate with the rest of the dev team and coordinate appropriate action. Since the new policy kicked in 2-3 months ago, we had two main results: - The development team discovered (and rapidly fixed in almost all cases) several bugs that were unknown up until that point. Some of those bugs had probably been present for some time. - The UX/frontend devs had significant feedback and redesigned the interface based on it. As a result, we have a more user-friendly website now.