Early in my career, I had the incorrect impression that interacting with customers was beneath me.

I had this perception because I was at a large company and standard corporate hierarchies encourage that mentality.

Photo by Petr Macháček

As a result, it has become a pretty widespread idea in our profession. Even if people don’t say it, they act like it.

Later in my career, I was asked in an interview how I would handle relations between support teams and software development teams. The answer is probably what cost me that job, but I wouldn’t change it.

Software developers should do support rotations.

The way it works is every week, have at least 1 developer on your team pair up with someone on the support team and go over the hardest issues they’ve had to deal with.

It doesn’t have to be for a whole day. Just 1-2 hours makes a huge difference for everyone involved.

First off, you end up getting better software. Even in the most obnoxious waterfall processes, there will be decisions developers have to make that are not in requirements. Software is too complex to write down everything in requirements (and I’ve written 500 page requirements documents).

Those decisions are often small such as an error message for an edge case. Or adding a loading state for people with slow internet connections.

Sometimes those decisions are large technical decisions, but are invisible to the user most of the time. Unfortunately, when users do notice them, the results are often extremely confusing for both users and support staff. How you handle concurrency falls into this category.

These decisions are often not talked since they’re either overly technical or there are a huge number of them. While each individual one is usually not a big deal, in aggregate they have a huge impact on the overall UX of your application.

Pairing up with support teams gives developers more exposure to how their software is actually being used. It not only creates empathy, but also provides critical context needed in making those hidden decisions.

The result will end up being better decisions, better UX, and ultimately better software.

You also end up with better internal tooling. A lot of support tickets often require looking things up. Some of those things may not be easy to query.

Developers hate spending time manually doing the same thing over and over. I know I do. This will result in them building more internal tools to make those queries easier. This makes your support team more effective and solve issues faster, which will end up making your customers happier.

Lastly, having developers pair up with your support teams is the best training your support teams can get. Most of them get what, 1 maybe 2 weeks of “training” in how the product works? Then they get thrown in the deep end answering customer questions.

No one can reasonably expect them to be experts in the product in that time. The result is a larger number of support tickets being forwarded to the development team. Engineering managers try to stem this tide with more process, but they’re just kicking the can down the road. Users need answers eventually.

A regular 1-2 hour session every week with developers is going to be extremely effective in training your support teams. They’re going to learn how the product really works and be more independant when resolving issues.

The long term effect of this? Developers spending less time investigating bug reports.