[wreath]

I've seen more engineers completely disinterested in anything customer related (and even calling users stupid!) more than I've seen PMs isolating devs. Every time I ask a PM if I could interact with a customer (not asking for permission, but to hook me up) they were delighted. Every single time.

Another way to solve this problem is to have engineers on customer support rotation of some sort. This way, engineers get to see how their software is used in the wild and interact with customers, and PMs get to see how unrealistic expectations and deadlines comes back to bite you in the ass in a form of your engineers being busy fixing half assed crap.

[reader_mode]

I agree about PM/dev/customer part but disagree on dev/support rotation.

This sounds great in theory, in practice working on any non-trivial software means there are parts you know little-nothing about. Having spent time on support duty I'd end up pinging team members for help (disturbing people without having a sense of priority since I don't do support), budding into other people's stuff without the capacity or desire to follow it up long term.

The best way I saw to get devs into customers shoes is to let developers be involved in client rollout - like ship then on-site and see how people use the feature they wrote.

But frankly even then, devs shouldn't be making a lot of these ae user facing decisions, send the UX guy.

[wreath]

I think it depends on how teams are organized already and the size of the company.

Few things I noticed that made this work in practice:

* Engineers pair up for few rotations with other engineers who are experienced in interacting with customers, triaging issues, troubleshooting issues across the system and identifying which internal service is causing issue and ping the team that supports it and/or move it to their support queue.

* The goal is not to fix every single bug or issue in the queue. Prioritize incoming tickets and gather as much information as possible before moving it to some team's backlog. Solve only problems that you think are manageable within the length of your support rotation.

* One engineer per team or owners of a set of services should on the rotation (this again depends on how teams are organized already).

* Pair with customer support or customer success agents when dealing with difficult customers, situations or need help communication-wise in general.

* Bring in these bugs to your team and make sure stakeholders are aware of them. This is important especially when the team ships something and moves on to the next thing thinking they have 100% capacity for the new project. This is another feedback channel that PMs should be aware of.

* Engineers on support rotation are exempt from their team duties while on support. Again, this communicates what capacity the team will be operating on in the next week or two.

I learned so much about other parts of our product and APIs, how users interact with it, and most importantly (for me at least, since that was the new part) working with people in the company who are not in engineering or product!

[krageon]

> disagree on dev/support rotation

I've worked (as a dev) in a customer-facing industry where devs are generally divorced from customers. Working in support has helped me understand the codebase better (because yes, you usually don't know it all that well if you just fix bugs and build features) and helped me to (at the time) connect with the value some people get out of it. That was nice.

What was less nice is dealing with the angry minority of customers. That was I would say significantly more unpleasant than dealing with the happy minority was pleasant. For that reason I would not recommend interfacing with customers for anyone. There is a reason support agents have such a high turnover.