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.
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.
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.
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.
Without going too far into detail our product and industry are a bit more complicated than most. It's not a phone app or a startup in a new industry. Our software is primarily used by independent contractors who are subject to a lot of federal and state regulations. In fact, I'd say that our support staff spends more time in an advocacy role than actually supporting the software itself.
So I would disagree when you say it's "not really your job" and "just plain stupid". Our job (as developers) is to create a product that helps our clients navigate a very tricky business environment -- one which most people have never experienced before working here. The time frame of the initial support training and continued learning is justified.
That's not to say that our system's perfect, mind you. In the 6-plus years since I was hired the company has gone from around 25 employees to almost 100. My initial training before actually taking support calls lasted about 4 days, then I was thrown into the fire. The current new employees spend like 3 weeks in the classroom before ever picking up a phone, which I think is far too long.
You could probably get a large part of the benefit of that by just having new developers sit within earshot of the customer support people for a while.
That's been my experience when I've sat close enough to hear support calls (although in my case it has always been because of small offices, not because of any deliberate attempt by management to make developers more aware of real customer experiences).
People hate flexible working spaces where you don't have your own desk, but they have at least this advantage: you can sit near the customer support people to hear some feedback when you can, and sit somewhere quiet when you need focus.
Well I'm only speaking out of personal experience, when I need focus I just need any old screen with fullscreen Emacs running on it, extra screen space just invites distractions. I'm probably a bit of an outlier there...
I'll take quiet side room every time. I honestly question our need for giant monitors. The likes of Visual Studio is very wasteful of screen real estate.
Which was absolutely the case for us, at least for my first 5 years here before we opened up a new wing dedicated to people who are only sporadically on the phone (development staff in one form or another). I'm still distracted in this quieter but still open environment, but it's better than it used to be.
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.
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.
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.
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.
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.
On our team at 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. ;)
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.
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.
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.