It's been a bit different in each of the companies I've had it, but fundamentally it's about using product expertise, general tech skills, and problem-solving to help the people who are using the product. Sometimes there are planned/scheduled/proactive projects, but the primary responsibility is responding to and helping with whatever issues customers are running into. This means the job can be unpredictable, because on any given day you don't know what's going to come up, but I like that - it keeps things new and interesting.
Support requests come in through whatever channels the team uses (every team I've been on has used email, some have also used Slack/phone/videoconference/etc.) and include things like bug reports, questions about best practices or how to do something with the product, and sometimes feature requests. As a support engineer, I take ownership of the support requests and do whatever is appropriate to drive them toward successful resolutions for the customer.
Because software products can change quickly, this often involves learning new features or systems. I often get support requests about tools or workflows I've never seen before (or that have changed significantly since the last time I looked at them) and have to quickly get up to speed on them. I learn best when it's in service of a goal, so this works well for me - I'm trying to help the customer accomplish their own goal and that motivates me to dig in and learn.
If it's a bug, I also investigate and try to reproduce the reported behavior. Sometimes the issue isn't what it appeared and the problem was that our documentation or UX was unclear, in which case I clarify things to the customer and file a ticket to fix the docs/UX. (Or just fix it myself - the amount of direct work I've been able to do in the docs/product has varied between companies, based largely on their size.) Sometimes it is a bug, in which case I'll try to come up with some alternate way for the customer to do what they are trying to do and then also file a ticket to get the bug fixed (with clear repro steps and getting as close to the root cause as I can, depending on how familiar I am with that part of the code base).
I also try to be proactive and serve as a customer champion - in most companies I've seen, product support has the broadest view of what issues are coming up for customers, and that can be valuable signal for the product team on how to prevent issues before they happen.
That's it in a nutshell. :) Always learning and applying expertise to help people succeed. I think it's a great fit for people who don't need to be in the spotlight but like knowing they've helped individuals and who work well in a rapidly-changing environment. (I think it might actually be kind of a dream role for technical people who have ADHD.)
I'm not sure if you're looking for stories of moving away from tech, software, or just development, but I did the latter.
I started as a web developer, but I realized that my favorite part of the job wasn't building new pages/apps but helping my colleagues when they ran into roadblocks. I got a reputation as a problem-solver and people would come to me with their thorniest bugs or browser compatibility issues and I loved it - the detective work of investigating and diagnosing the issues, the creative solutions to work around browser limitations, and the satisfaction of helping people achieve their goals.
Then I met a product support engineer at my friend's startup and heard about that role, and realized it was an entire job made of what I loved most about my previous jobs. I joined the team and was on it for years, and have been working in technical support for software products ever since (about twelve years now). I still build websites as a hobby, but I wouldn't want to do it for a job anymore. I'm very happy in product support.
For me, what helped was paying attention to what I liked about my work and leaning in a direction that emphasized those kinds of tasks - though it was kind of just luck that I found a job that let me do that.
I got my start in web development because I had picked it up as a hobby and (at least at the time) it was a good way to get reasonable money without a degree. But my favorite parts were learning new techniques/technologies (I started out without a team to steer me toward best practices so I did a lot of experimentation, self-teaching, and reinventing the wheel - probably made my projects take longer but meant I learned a lot more) and then using that expertise to help my colleagues (once I did have a team, my deeper understanding meant that I was the one to go to when something didn't work right in IE6 or something).
At one point, I was having dinner with a friend at his startup and happened to meet one of their product support engineers. She explained that the role involved becoming an expert in their highly-technical, fast-growing product and then using that expertise to help customers (internal and external ones). I realized that was an entire job made of my favorite parts of my previous job. I applied to join her team and I've happily worked in product support for tech startups ever since. Before this point I never would have considered product support, because I just had a stereotypical vision of it as sitting in a phone center reading from a script. The ideal field for you might be out there without you realizing it exists.
I still try to identify the things I like doing and spend more time doing those things. Sometimes that means spending time working with folks on other teams - not all companies are flexible enough to allow this, but I think healthy ones will because the added perspective usually will make you more valuable to the company as well. Making sure to have these varied experiences and keep learning new things has been a great way to keep up my engagement over time.
The takeaway I have is basically what you said - stressing about something may make you feel like you're working harder, but really just burns up your emotional energy. From the end of the article: "When I notice that I'm all stressed out about something or driving myself to exhaustion, I . . . try dialing back my effort by 50 percent. . . . [H]alf of my effort wasn't effort at all, but just unnecessary stress that made me feel like I was doing my best."
Stress and anxiety can be a signal that you need to take something seriously, but if you're already taking it seriously, it's not helpful. If you can drop it while still responding to the situation appropriately, you'll be better off. Focus, don't obsess; progress, don't stress.
This is something I also learned in my time working technical product support - at first, when emergencies happened with the product, I would panic and scramble. But I eventually realized that didn't actually help and just made things less pleasant for me and anyone interacting with me. Everything went better if I took the emergency seriously but calmly, and just handled it without reacting emotionally.
I work in technical product support and I find this to be a useful framework that captures some important considerations I've dealt with.
When I interview candidates and give them a troubleshooting exercise to test their diagnostic skills, some candidates will use what I call the "shotgun" approach - list out a bunch of tests and things to check, but in such a way that the tests don't build on each other and could be performed in any order. This is the sort of approach that works for "tier 1" style support where you're just running down a checklist.
The best candidates will use what I call the "iterative" approach - try a test, understand what the outcome implies, and then try another test based on that new knowledge in an act-learn-repeat loop. This shows me that they will be able to handle novel product issues that haven't been seen before and aren't on any checklist.
I knew that the latter approach required a stronger mental model, but now I think a more useful framing is that the shotgun approach is about Recognizing and the iterative approach is about Generating. Having this framing is likely to improve my candidate review process and reports.
Also, because we only hire folks who demonstrate the capability to use the iterative approach, when I find someone on my team using the shotgun approach with real customers, my assumption is that their mental model of the product/tech involved is insufficient and my response is to help them build up their understanding. I think now I'm also going to try framing this to them as upgrading from Recognizing to Generating and see if that helps.
Support requests come in through whatever channels the team uses (every team I've been on has used email, some have also used Slack/phone/videoconference/etc.) and include things like bug reports, questions about best practices or how to do something with the product, and sometimes feature requests. As a support engineer, I take ownership of the support requests and do whatever is appropriate to drive them toward successful resolutions for the customer.
Because software products can change quickly, this often involves learning new features or systems. I often get support requests about tools or workflows I've never seen before (or that have changed significantly since the last time I looked at them) and have to quickly get up to speed on them. I learn best when it's in service of a goal, so this works well for me - I'm trying to help the customer accomplish their own goal and that motivates me to dig in and learn.
If it's a bug, I also investigate and try to reproduce the reported behavior. Sometimes the issue isn't what it appeared and the problem was that our documentation or UX was unclear, in which case I clarify things to the customer and file a ticket to fix the docs/UX. (Or just fix it myself - the amount of direct work I've been able to do in the docs/product has varied between companies, based largely on their size.) Sometimes it is a bug, in which case I'll try to come up with some alternate way for the customer to do what they are trying to do and then also file a ticket to get the bug fixed (with clear repro steps and getting as close to the root cause as I can, depending on how familiar I am with that part of the code base).
I also try to be proactive and serve as a customer champion - in most companies I've seen, product support has the broadest view of what issues are coming up for customers, and that can be valuable signal for the product team on how to prevent issues before they happen.
That's it in a nutshell. :) Always learning and applying expertise to help people succeed. I think it's a great fit for people who don't need to be in the spotlight but like knowing they've helped individuals and who work well in a rapidly-changing environment. (I think it might actually be kind of a dream role for technical people who have ADHD.)