|
|
|
|
|
by reader_mode
1777 days ago
|
|
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. |
|
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!