|
The flip side of this, of course, is that not everyone wants to be involved in support and that sharing around the support burden can lead to a loss of focus within the organization. Often everybody doing everything is indistinguishable from everybody doing nothing. At my last job the support team was a thin abstraction layer that seemed to pass almost everything directly through to my dev team. For a while I enjoyed it -- it is satisfying to see how my efforts could directly help customers, undertand how they were using the product, etc. The type of software I was working on meant that technical configuration problems were showstoppers and people hailed me as a hero whenever I stepped in and resolved their issues. The downsides were insidious and slow to show themselves: lack of time to invest in fixing problems in a systematic way rather than helping customers one-by-one because of time consumed by support, inability to focus on feature work due to support-related interruptions up to 2-3 times per day, the sentiment from leadership that we weren't delivering new features fast enough because of our invisible support labor, the feeling of being "always on" because we had customers with high-urgency tickets around the globe, etc. After two years of that, I was staring burnout in the face. I told my leadership I didn't want to work this way but nothing changed. When a month went by where I only made 3 commits to source despite feeling overwhelmingly busy I knew something had to change, if not in the org then in myself. I told my manager I simply would not participate in support any more and was deleting Slack from my phone, that if they wanted a good customer experience they needed to make the necessary investments. In my mind this ultimatum was the first step toward quitting my job. But an amazing thing happened once I started putting boundaries in place: leadership started talking about the need for better systems, better documentation, the need to prioritize work that would make the product easier to use and support. My productivity on feature work skyrocketed and my product managers were happy because we were over-delivering for their bosses after under-delivering for so long. I was given a large raise a few months later, the kind people normally have to change jobs to get. For myself, I learned it's important not to enable dysfunctional process just because I can excel, for a while, in that process. I learned it's important to set boundaries in my work. I learned that focus is sacred and should be protected. If you are a leader in your company thinking about diffusing the support burden, carefully consider the productivity cost to your most expensive/valuable employees that comes with repeated direct exposure to customers. |
Those Support Engineers are invaluable. They can investigate those requests, decide which ones are legitimate (we get a lot of either one-off minor freak things happening due to network glitches or customers just interacting with the software in really crazy ways and we don't have time to baby proof the software -- I should note that this is internal software, so we only have a couple hundred users), and for the things that do happen from time to time, like a customer accidentally closed something out and needs to reopen it but we don't normally allow that to happen so it doesn't get abused, we provide tools so the support engineer can fix those things without involving the rest of the dev team.
Once those things are taken care of, everything that's left, assuming the support engineer thinks it's important enough, can then be passed along to us. We used to only get a handful of those a month.
Now that there's no Support Engineer I get these requests all the time, and I'm getting burnt out, as I'm effectively working two jobs now instead of one (actually four, as I'm also an Architect now and the director of the phone systems, without the promotion, and basically have four bosses now, who don't communicate with each other and each have their own high priority requests I'm expected to do for each of them in addition to dev and support work, but that's another story....we lost a lot of people and there's almost no efforts being made to replace them).