7 ms·

I did it for 10 years, but more recently have moved away from phone support as much as possible (or delegated to others to do). The main reason - I am a solo d

I did it for 10 years, but more recently have moved away from phone support as much as possible (or delegated to others to do). The main reason - I am a solo developer. And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'. It was basically impossible for me to get into 'flow' state during a normal working day. Even one phone call during the day took me away from my creative, programming mindset and into an empathetic, listening mindset. And the transition between the two were very different. It's like asking a racing driver to knit a scarf each time he came into the pits, before he could go out on the track to drive at high speed again. It also made it hard to plan blocks of work. Most times it was OK, but there were days where I would plan to do about 5 or 6 bug fixes, but I would get a slew of phone calls that meant I got 0 programming done that day, and would have to move other plans. I actually enjoyed support, but in the end I had to decide which of the two parts of the job was moving the business ahead more than the other, and pure development work won out.

gxs 9y ago
Some of the most successful companies in the world, with a reputation for excellent customer service offer single channel support through cases only, because phone support is too inefficient. Kudos to you for staying afloat for so long the way you did.
- cyberferret 9y ago
  Thanks. I did try to coerce my customers away from phone support (by reducing my hours that I would respond to calls) and try to get them to use a ticketing system (Zendesk)). That worked to a certain extent, but still didn't fully eliminate those that were already used to phone support. A ticketing system also helped with another big bugbear of mine - getting back to customers with long support ticket cycles, i.e. where I had to make bug fixes, test and deploy. I was frequently forgetting to get back to them to advise them I had fixed an issue. The ticketing system helped me to keep track of that. Following up with customers was another mind loop that detracted from the freedom of mind I needed to develop good code.
  - friendzis 9y ago
    At my last gig we had three support channels: phone, skype and ticketing. Standard workflow (which clients always tried to circumvent) was: client writes to skype/calls, we decide whether complaint is solved by a quick explanation and respond with a call, or problem requires more investigation/work and client is directed to submit a ticket.
paulryanrogers 9y ago
May have more to do with the pace of the industry your serving and maturity of the software. In a niche that doesn't change much it's probably easier to get dialed in to what most customers want and need.
BurningFrog 9y ago
The obvious solution is to have phone support days or hours. If you only accept support calls at certain times, you can plan to do development at other times.
- cyberferret 9y ago
  When dealing with local clients, that is certainly a possibility (and indeed was the case with me at one stage). But when you have customers all over the world, you have to basically be on call 24hours a day (also the case with me).
  - majewsky 9y ago
    Do you allow clients to shake you out of your sleep?
danso 9y ago
> I did it for 10 years, but more recently have moved away from phone support as much as possible (or delegated to others to do). Somehow you managed to also keep the business going as its sole developer without going insane or bankrupt. If your luck turns bad and you have to find job security at a Big TechCo, at least the prospect of being stuck in an open-office-layout won't scare you :)
- cyberferret 9y ago
  It would probably freak me out TBH! :) After so long working for myself from home, the prospect of being in a busy office with people milling about and a hundred conversations going on at once will probably reduce me to a quivering wreck under the desk! :P
- reaanb 9y ago
  I did my own support as a solo dev for 15 years for an app used by around 250 companies and as much as 1000 users. Then we got bought out and I moved into an open plan office. It's not the same at all. 5 years later I still struggle to deal with the open plan noise and interruptions.
kqr 9y ago
> And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'. This is something I can have trouble with even personally. I have noticed that when I get home from a long day of cold, analytical problem-solving, I mbrain bad at shifting my brain to empathetically listen and provide emotional support for my wifes problems.
- blt 9y ago
  I wrote myself off as "bad at being supportive" for a long time. Eventually I realized that being supportive is a trainable skill just like software development or healthy eating. I am still not great at it, but getting better. I respectfully urge you to examine yourself and try to modify your habits rather than looking for excuses.
  - koliber 9y ago
    Agreed that it is trainable if you are bad at it in general. I don't think the parent was saying that he is bad at emotional support and being empathetic. He said he is having trouble switching from the developer brain mode into the empathetic human brain mode. This is something I noticed myself as well, especially when working from home. When I worked in an office, the commute home provided time to decompress and switch off my focused analytical brain. By the time I would get home, I would be in the proper mindset. I guess you could say that there are benefits to a commute after all!
    - dkersten 9y ago
      > I guess you could say that there are benefits to a commute after all! Absolutely, its forced idle time where your mind can drift. Although, over time, I find myself just getting more and more tired during my commute to the point where anything I do think about is quickly lost now... :/
      - jdironman 9y ago
        Maybe, just for the fun of it, take a different route home one day. Even if it is a good few minutes out of the way. A road you haven't been down yet to re-engage your mind and senses as you navigate that new path.
friendzis 9y ago
Slightly tangential, but important note for management. Every piece of work can be either proactive or reactive. Proactive stuff is planned and possibly scheduled. Reactive stuff is, well, reaction to client call. Note that client call can spawn another reactive task to fix something. If client issue can be converted to proactive task - good, you can put it to backlog and plan. Reactive tasks naturally have higher priority than any proactive task (either contractual SLA, policy to always pick up phone, etc.). Proactive tasks have interesting impact on hour consumption. Lets say client call takes 1 hour to complete. Unless client calls are uniformly distributed over the day, there is nontrivial probability of calls to happening with intervals lower than 1 hour. In order to complete each proactive task 1,5 hour after the call was placed with decent probability, operator can accept something like 3 calls a day (~40-50% load on reactive operator is considered critically high, higher loads inevitably lead to periods with significantly higher reactive load than operator can handle). That is 3-4 hours of work in an 8 hour day. If reactive workloads are intermixed with proactive loads, interruptions caused by reactive tasks significantly prolong time taken to complete proactive tasks. > there were days where I would plan to do about 5 or 6 bug fixes, but I would get a slew of phone calls <...> and would have to move other plans. Evidence based scheduling [1] is a good strategy to avoid moving plans. Even if you do not have fixed phone support hours, you can still try to average hours spent on phone support. If your average week involves 20 hours of phone support, then planning for anything more than 15 hours of proactive work is too optimistic, considering 40 hour week. Once you mix proactive and reactive tasks, your planning periods must be longer - roughly periods where reactive loads average smoothly, probably nothing shorter than a week. [1]: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
erader 9y ago
Hi there! Support manager here. I've been leading support teams for years, led support QA teams, built troubleshooting processes and worked very closely with dev teams. A lot of what I wanted to bring up doesn't apply so much to solo dev's, but I want to vouch for non-devs and anyone that might start working on team. Support brains and developer brains are actually not that different. I see on HN way too often that developers need space and time to think, but other types of people don't. This is myth that needs to be dispelled and everyone should contribute to uphold boundaries that work for everyone. Trust that absolutely I want you to have 'flow' time - it's important that you both be and feel productive. Good code from you is good code for me and for the user. What breaks flow is context switching, which is literally baked into the job description for your average support role. Agents often need to answer questions about multiple/complex products, and who knows if they have access to high quality documentation or internal tools. When something breaks for a customer, agents need to find creative solutions or escalate the issue up do the dev teams. You bet that if there's another call waiting or 20 more emails in the queue, they're not spending a lot of quality time on getting things done right. The bug they submit won't be thorough, and developers won't want to touch those bugs. The workaround they give won't be well explained, and the user won't know how to manage once the call is over. These things wouldn't happen if agents had their 'flow' time too. I would love to give customers all the time they deserve, but obviously there are limitations to how many agents you can hire to make that happen. When a customer team gets burnout from high support volume, it's rarely the volume alone that makes agents hurt. It's the volume AND context switching. 50 phone calls about different things will leave you a zombie by the end of the day. It's totally OK that a support person's time is variable like this, but it's dangerous when the pairing developers time is untouchable. Pro tip: make ground rules for what developers might be "on-call" or have office hours, have rotating schedules for which developers need to help support teams, have dedicated places where agents can escalate engineering tasks without physically bothering someone. Of course, there are so many factors that effect this: how many engineers and support people there are, what kind of issues need to be worked on, what are the priorities for support hours or shipping new code. At the end of the day, just know that we're all people on one team (albeit with very different daily responsibilities). Respect each other's time and needs, and the rest will fall into place.
- 9y ago
laumars 9y ago
> And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'. They can be different but I don't think they necessarily need to be. Thankfully Im seldom customer facing these days but when I am and when I used to be I would "debug" human patterns with the same analytical approach as software development. Even ones that turned out not to be technical queries in the end.
- jrochkind1 9y ago
  Agreed. I don't think they are actually that different mindsets at all. Debugging isn't the only thing a developer/engineer does, but I agree support (for software) is much like debugging, that's a good observation. Debugging is debugging. Yes, you've got to actually be compassionate and considerate when working with humans, and you don't with code. That's not a 'brain mode', it's just a skill or capacity. Some of us have more of it than others, but we all can improve it or get better at it. Most (maybe not all but most) developers are working with other developers (whether teammates or open source maintainers/collaborators), so it's an important skill to develop even for exclusively developers.
ajeet_dhaliwal 9y ago
Over the last couple of years I've had to accept I can really only do one thing at a time, multi-tasking is something I simply cannot manage, I either do one thing or I get nothing done so I agree, I enjoy providing support too and I enjoy coding, but I can only do one or other at one time.
justinmoh 9y ago
I agree. Perhaps that’s also depends on your expertise or stage you’re at. I’d say if I continuously do this for five years, all the positive points described by OP probably not as useful anymore. Your dedication of doing it for ten years amazed me.

gxs 9y ago

Some of the most successful companies in the world, with a reputation for excellent customer service offer single channel support through cases only, because phone support is too inefficient. Kudos to you for staying afloat for so long the way you did.

cyberferret 9y ago
Thanks. I did try to coerce my customers away from phone support (by reducing my hours that I would respond to calls) and try to get them to use a ticketing system (Zendesk)). That worked to a certain extent, but still didn't fully eliminate those that were already used to phone support. A ticketing system also helped with another big bugbear of mine - getting back to customers with long support ticket cycles, i.e. where I had to make bug fixes, test and deploy. I was frequently forgetting to get back to them to advise them I had fixed an issue. The ticketing system helped me to keep track of that. Following up with customers was another mind loop that detracted from the freedom of mind I needed to develop good code.
- friendzis 9y ago
  At my last gig we had three support channels: phone, skype and ticketing. Standard workflow (which clients always tried to circumvent) was: client writes to skype/calls, we decide whether complaint is solved by a quick explanation and respond with a call, or problem requires more investigation/work and client is directed to submit a ticket.

paulryanrogers 9y ago

May have more to do with the pace of the industry your serving and maturity of the software. In a niche that doesn't change much it's probably easier to get dialed in to what most customers want and need.

BurningFrog 9y ago

The obvious solution is to have phone support days or hours. If you only accept support calls at certain times, you can plan to do development at other times.

cyberferret 9y ago
When dealing with local clients, that is certainly a possibility (and indeed was the case with me at one stage). But when you have customers all over the world, you have to basically be on call 24hours a day (also the case with me).
- majewsky 9y ago
  Do you allow clients to shake you out of your sleep?

danso 9y ago

> I did it for 10 years, but more recently have moved away from phone support as much as possible (or delegated to others to do). Somehow you managed to also keep the business going as its sole developer without going insane or bankrupt. If your luck turns bad and you have to find job security at a Big TechCo, at least the prospect of being stuck in an open-office-layout won't scare you :)

cyberferret 9y ago
It would probably freak me out TBH! :) After so long working for myself from home, the prospect of being in a busy office with people milling about and a hundred conversations going on at once will probably reduce me to a quivering wreck under the desk! :P
reaanb 9y ago
I did my own support as a solo dev for 15 years for an app used by around 250 companies and as much as 1000 users. Then we got bought out and I moved into an open plan office. It's not the same at all. 5 years later I still struggle to deal with the open plan noise and interruptions.

kqr 9y ago

> And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'. This is something I can have trouble with even personally. I have noticed that when I get home from a long day of cold, analytical problem-solving, I mbrain bad at shifting my brain to empathetically listen and provide emotional support for my wifes problems.

blt 9y ago
I wrote myself off as "bad at being supportive" for a long time. Eventually I realized that being supportive is a trainable skill just like software development or healthy eating. I am still not great at it, but getting better. I respectfully urge you to examine yourself and try to modify your habits rather than looking for excuses.
- koliber 9y ago
  Agreed that it is trainable if you are bad at it in general. I don't think the parent was saying that he is bad at emotional support and being empathetic. He said he is having trouble switching from the developer brain mode into the empathetic human brain mode. This is something I noticed myself as well, especially when working from home. When I worked in an office, the commute home provided time to decompress and switch off my focused analytical brain. By the time I would get home, I would be in the proper mindset. I guess you could say that there are benefits to a commute after all!
  - dkersten 9y ago
    > I guess you could say that there are benefits to a commute after all! Absolutely, its forced idle time where your mind can drift. Although, over time, I find myself just getting more and more tired during my commute to the point where anything I do think about is quickly lost now... :/
    - jdironman 9y ago
      Maybe, just for the fun of it, take a different route home one day. Even if it is a good few minutes out of the way. A road you haven't been down yet to re-engage your mind and senses as you navigate that new path.

friendzis 9y ago

Slightly tangential, but important note for management. Every piece of work can be either proactive or reactive. Proactive stuff is planned and possibly scheduled. Reactive stuff is, well, reaction to client call. Note that client call can spawn another reactive task to fix something. If client issue can be converted to proactive task - good, you can put it to backlog and plan. Reactive tasks naturally have higher priority than any proactive task (either contractual SLA, policy to always pick up phone, etc.). Proactive tasks have interesting impact on hour consumption. Lets say client call takes 1 hour to complete. Unless client calls are uniformly distributed over the day, there is nontrivial probability of calls to happening with intervals lower than 1 hour. In order to complete each proactive task 1,5 hour after the call was placed with decent probability, operator can accept something like 3 calls a day (~40-50% load on reactive operator is considered critically high, higher loads inevitably lead to periods with significantly higher reactive load than operator can handle). That is 3-4 hours of work in an 8 hour day. If reactive workloads are intermixed with proactive loads, interruptions caused by reactive tasks significantly prolong time taken to complete proactive tasks. > there were days where I would plan to do about 5 or 6 bug fixes, but I would get a slew of phone calls <...> and would have to move other plans. Evidence based scheduling [1] is a good strategy to avoid moving plans. Even if you do not have fixed phone support hours, you can still try to average hours spent on phone support. If your average week involves 20 hours of phone support, then planning for anything more than 15 hours of proactive work is too optimistic, considering 40 hour week. Once you mix proactive and reactive tasks, your planning periods must be longer - roughly periods where reactive loads average smoothly, probably nothing shorter than a week. [1]: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

erader 9y ago

Hi there! Support manager here. I've been leading support teams for years, led support QA teams, built troubleshooting processes and worked very closely with dev teams. A lot of what I wanted to bring up doesn't apply so much to solo dev's, but I want to vouch for non-devs and anyone that might start working on team. Support brains and developer brains are actually not that different. I see on HN way too often that developers need space and time to think, but other types of people don't. This is myth that needs to be dispelled and everyone should contribute to uphold boundaries that work for everyone. Trust that absolutely I want you to have 'flow' time - it's important that you both be and feel productive. Good code from you is good code for me and for the user. What breaks flow is context switching, which is literally baked into the job description for your average support role. Agents often need to answer questions about multiple/complex products, and who knows if they have access to high quality documentation or internal tools. When something breaks for a customer, agents need to find creative solutions or escalate the issue up do the dev teams. You bet that if there's another call waiting or 20 more emails in the queue, they're not spending a lot of quality time on getting things done right. The bug they submit won't be thorough, and developers won't want to touch those bugs. The workaround they give won't be well explained, and the user won't know how to manage once the call is over. These things wouldn't happen if agents had their 'flow' time too. I would love to give customers all the time they deserve, but obviously there are limitations to how many agents you can hire to make that happen. When a customer team gets burnout from high support volume, it's rarely the volume alone that makes agents hurt. It's the volume AND context switching. 50 phone calls about different things will leave you a zombie by the end of the day. It's totally OK that a support person's time is variable like this, but it's dangerous when the pairing developers time is untouchable. Pro tip: make ground rules for what developers might be "on-call" or have office hours, have rotating schedules for which developers need to help support teams, have dedicated places where agents can escalate engineering tasks without physically bothering someone. Of course, there are so many factors that effect this: how many engineers and support people there are, what kind of issues need to be worked on, what are the priorities for support hours or shipping new code. At the end of the day, just know that we're all people on one team (albeit with very different daily responsibilities). Respect each other's time and needs, and the rest will fall into place.

9y ago

laumars 9y ago

> And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'. They can be different but I don't think they necessarily need to be. Thankfully Im seldom customer facing these days but when I am and when I used to be I would "debug" human patterns with the same analytical approach as software development. Even ones that turned out not to be technical queries in the end.

jrochkind1 9y ago
Agreed. I don't think they are actually that different mindsets at all. Debugging isn't the only thing a developer/engineer does, but I agree support (for software) is much like debugging, that's a good observation. Debugging is debugging. Yes, you've got to actually be compassionate and considerate when working with humans, and you don't with code. That's not a 'brain mode', it's just a skill or capacity. Some of us have more of it than others, but we all can improve it or get better at it. Most (maybe not all but most) developers are working with other developers (whether teammates or open source maintainers/collaborators), so it's an important skill to develop even for exclusively developers.

ajeet_dhaliwal 9y ago

Over the last couple of years I've had to accept I can really only do one thing at a time, multi-tasking is something I simply cannot manage, I either do one thing or I get nothing done so I agree, I enjoy providing support too and I enjoy coding, but I can only do one or other at one time.

justinmoh 9y ago

I agree. Perhaps that’s also depends on your expertise or stage you’re at. I’d say if I continuously do this for five years, all the positive points described by OP probably not as useful anymore. Your dedication of doing it for ten years amazed me.