Live data from Hacker News

As a solo developer, I decided to offer phone support

plumshell.com

41–50 of 147 posts

Re: As a solo developer, I decided to offer phone support

#41

Working at the Apple Store as a sales person has helped me IMMENSELY in my career, not only in terms of understanding how human beings approach technology but from a sales standpoint as well. In the first startup I was a part of, every single member of the 3 person team did email support for our school teacher userbase. Do it. Everyone needs to do it. Doing this kind of work is very grounding and humbling. When you b…

Or if you can't switch jobs just yet, and you have time to kill at an Apple store, sit in on one of their daily tech sessions. I once went with my mom to the "Basics: iPad" session and couldn't believe how basic the topics were in the description [0]. But the attendees had even more fundamental issues than could be covered, such as file management, e.g. how to move a photo from the iPad to their home desktop hooked to the printer. I know that is actually not simple (it may even be covered in the Intermediate version of the class), but it's the kind of everyday feature that users expect to be simple.

[0] https://www.apple.com/today/event/ipad-basics-63381241581444...

Re: As a solo developer, I decided to offer phone support

#42

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, pr…

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.

Re: As a solo developer, I decided to offer phone support

#43

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, pr…

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.

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).

Re: As a solo developer, I decided to offer phone support

#44
post #39

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, pr…

> 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 :)

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

Re: As a solo developer, I decided to offer phone support

#45
post #42

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, pr…

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.

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.

Re: As a solo developer, I decided to offer phone support

#46

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, pr…

> 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.

Re: As a solo developer, I decided to offer phone support

#47
Because my startup's tools are used heavily in the dyslexia and ADHD communities, I have found that phone support is a very helpful thing to offer. Some of our users have difficulty reading/deciphering our instructions, but they have no problem once we provide directions verbally on the phone.

Re: As a solo developer, I decided to offer phone support

#49

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, pr…

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-sch...

Re: As a solo developer, I decided to offer phone support

#50

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, pr…

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.

Post reply on HN