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.
> 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.
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.
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!
> 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... :/
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.
The daily transition from work to home is difficult for many couples and this problem has existed since forever, but it has _nothing_ to do with "being analytical" at work and then having to "be empathetic" at home.
It doesn't matter what your job is or if you're a husband or a wife, there's a period of time after coming home from work that is beset with opportunities for arguments. Lots of people experience this, not just rocket-scientists and developers :-)
There's no sure-fire solution, but a little bit of buffer time seems to work, followed by deliberate accommodation for the needs of the other.
> "it has _nothing_ to do with "being analytical" at work and then having to "be empathetic" at home."
[citation needed]
I doubt you (or anyone, for that matter) can make such a claim with scientific rigor. You are responding to a statement of someone's personal experience - for them, it very well may have something to do with switching from an analytical, critical state to a more empathetic one.
For my part, I recognized after I got married that I was coming home and applying the same mental model I used at work in conversations with my wife: I was there exclusively to solve problems. My wife just wanted me to listen while she told me about her day. This definitely increased the surface area for arguments, because in my years I've found that generally, wives want you to shut up and listen and empathize with what they're complaining about, and not rattling off "answers" to the problems. I did have to train myself to adapt to the transition. It did cause problems specifically because of the mental model I brought home from work.
> My wife just wanted me to listen while she told me about her day...
Yes. Totally this...just listen to her...turn off all that problem solving stuff and just look her in the eyes and keep your mouth shut, no matter what she is saying.
She is strong...she can solve her problems, but she needs you to hear her vent and offer emotional support.
It took me a long time to get this right too. I came across this amusing page and realized I wasn't a bad person, because there is a lot of truth to this.
This page is very silly, it basically says 'men get to do what they want when they want'. I like how the longest rule is about being 'single-minded', which is basically just an excuse for not taking part in all facets of your relationship.
Here is another perspective which you may find equally dumb:
Note that this comic is coming from a totally female perspective (scary!) but it really applies either way. For instance, in my marriage I am the one who feels like the chore-czar, while my wife is the one who tends to feel like the planning-czar. If we both realize this and try to meet in the middle it makes things go a lot more smoothly.
This is assuming they both want the same thing. Society pushes us into marriage and getting kids, not just into gender roles. I think greater equality will lead to more single people, not more men doing house work. Because people will realize they actually have a choice. Most people don’t want to clean and administer the same stuff every day. And although nobody would prefer that thir kids were never born, people would not feel like they are losing out if they never get kids. Developed countries have people get fewer kids later in their lives. Maybe it is because of the economy, but kids could help their parents with money, so i dont think so, i think it is by choice. You could call it people getting more selfish, i say it is people getting more rational, or «analytical» if you will.
I prefer humor, but it's obviously not for everybody. Also theres a slightly different version of the one I posted above on this page, but I couldn't find a directly corresponding one for women's version. If you do please share- I'd like to forward it to my wife.
> Different needs. Both parties are likely to be in different mental and emotional states with differing sets of personal needs, and while this may seem self-evident, it’s striking how many couples forget this when they walk in the door.
My mother worked in a psych ward, and would come home stressed. She asked that, every day for the hour after she got home, she not be bothered with anything. She just wanted a break between the (inevitable) difficulties of work life and the (potential) difficulties of home life.
So no, not analytic related and not gender related.
I've found that repeating a little mantra of what to expect of myself exactly at that moment of switching helps. For me that moment is getting out of the car, hungry and with a full head, after a long commute. Diving head first into family life with small children is hard, but they deserve my fullest attention before bed time even before my own needs (food, rest, possibly work some more). Just breathing and repeating that works for me. (Apologies if this goes too far into the spiritual.)
Erm, I would call spiritual something different ...
What you do, is just helpful, applied psychology ;)
edit: spiritual, I would more call, praying to whomever, to fill you with love, before going into your family life ... which can also work, wheter for psychological or divine reasons ...
I've found that a short (20 minute) commute can help a lot with this.
I'm actually serious -- the commute is like a palate cleanser between work and home. It helps even more when I ride a motorcycle, as the concentration on my safety totally wipes the coding from my brain, and I walk in the house with a clean slate.
Yeah I've seen some people that work from home mention this - the ritual or transition of going from work to home is something they miss. To a degree of course, I mean 20 minutes isn't too bad, for me it's often more than an hour which is a bit much.
This was the biggest reason I switched from working as a programmer and spent some semesters becoming a high school teacher teaching mathematics and programming.
I feel I can be much more available for my (to be) wife and my friends now.
(it's paid less oc but I have been lucky and don't need so much).
that's one of the reason I walk home, so I have time to disengage from work. (edit: I also live close-by now, but before it was public transit, for the same reason)
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.
> 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.
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.
> 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
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.
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.
Thanks for your thoughtful reply, but I think there are a couple of points that you may have missed in my original post.
> Support brains and developer brains are actually not that different.
Agreed. I wasn't talking about intelligence or analytical skills per se, but rather the 'mode' that you think in when in either situation.
When developing code, my mind is racing ahead and planning out things that are far beyond what I am working on. In essence it is multi tasking, and juggling several tasks and ideas at the same time. I am 'ahead of the aircraft', to use pilot speak, and I am constantly trying to anticipate problems that may occur and critical tasks that I know I will have to complete. Complete with all this is jumping around between several editor, terminal, browser, emulator windows etc.
However, when doing support, I have to be completely and utterly present with the person on the other end of the support call. I can no longer 'free wheel' and distract myself with other tasks. I have to display full empathy with the customer, and ensure that I am accurately picturing in my mind what they are trying to say.
If the customer is a slow talker, or non technical, then I have to kick in extra energy to make doubly sure I am being effective in providing the best possible support experience.
My analogy above about race car driving and knitting is not outside the mark. Both are skilled tasks, but they both require a completely different mode of thinking and presence of mind to be able to execute to the best of your ability.
"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."
I do a lot of helpdesk. I've found out most of the time there is a huge difference in information availability between support desk and the rest of the company. Support people spend a ton of time and frustration finding out what the hell a client is talking about, who promised them things and where or what the hell the service level agreement is.
I made a lot of (account) managers very very angry by stating well written documentation and procedures should available to the entire support team. It should be a milestone of EVERY project or else there is NO finished project. People should not be held responsible because of lack of supplied information. Especially when they've asked for it a gazillion times.
This is one of the reason these teams hate each other so much in big companies.
It’s support’s job to focus on one thing at a time, meanwhile it’s a coder’s job to try and keep dozens of things in mind at a time. Context switching IS hard regardless, but like you said, one of the roles has it baked into the job description.
The crux here is that Programmer committed to X work done by the end of the week, and Support is effectively subtracting their time to accomplish X. This is a managerial problem, and not an easy one, because it’s not predictable.
My estimate, if you’re a programmer working 40h/wk on a live product, 8h of coding is a good week. Expect the majority of your time to be spent planning, reviewing, and supporting. If you’re sacrificing one of those to get more concentrated coding time, make sure that is communicated. YMMV.
In any case, if you don’t have managerial support to get engineer resources to fix problems, then it’s not support - it’s therapy. Sometimes that’s the best you can do.
I would hardly say it's supports job to focus on one thing at at time.
Most people that reach out to support are calling about a specific question or problem. Yes therapy calls do happen. They're not terribly common, but you'll hear about them because they are funny/egregious examples.
When a customer calls about their 1 thing, I can definitely look up the 1 answer or do the 1 fix for them. This is bad support though.
A good support team will listen to that customer, understand what they're needs are and fix that thing while make sure they are set up for success in the future. This means I'm checking different account/user statuses, feature usage, and billing history. I dot his while talking to them, but never letting them know I do this.
If I can understand their 1 question AND know who they are holistically, I can set them up for success and prevent more support tickets down the road.
If you've ever had a user or a profile sent to you in a bad/extreme state, you can bet that a series of 1-off support solutions could have lent to that.
Maybe other support organizations are different or maybe I am busier than normal, but the concept of one thing at a time is foreign to me.
To outline today:
Left comments on ~15 net new cases to jump start the troubleshooting by the technicians assigned to them
Help led a morning meeting reviewing cases where people are stuck
Researched whether an old (7y) version of the software had a piece of functionality
Made comments helping ~5 different technicians globally on their cases
Helped a colleague craft a SQL query to help replicate an issue then talked over strategy
Logged into a colleagues VM where they had an install problem
Had a call with the pre-sales brass about trends in the support organization
2 walk ups:
- Intermittent reload issue when triggering things via API
- How to setup a reverse proxy with IIS
Assigned cases for initial responses to meet our contractual obligations
- Left 5-10 public facing comments to meet SLA to assist the team
Emailed some devs about whether a customer can run using the latest version of the database which underpins our software
Responded to 3-4 different issues in the Slack for our Consultants on-site with customers
Came up with a PowerShell script to work around a bug for another tech at the behest of our Escalations folks who walked up
Caught up on a case that I'll be covering for next week which has Executive VP visibility (ultimately making things right after the initial tech botched a system)
Personal cases:
- Install problem on a server with FIPS
-- Then get thrown under the bus on a customer facing email about the further issues
-- After bypassing that there was a user rights assignment problem; emailed some devs about why we require it / work-arounds for a locked down government server
- Reload of data problem due to the permissions for the service account
-- On the call discussed:
--- Architecting for high availability
--- Long-term maintenance activity to ensure stability
- Reviewed 2GB of logs for an intermittent issue
- Worked on reproducing a client side bug
- Called / left voicemails / sent emails for 3 customers trying to get a remote session scheduled
- Alleged security vulnerability. Called / emailed the customer asking for more clarity; stood up servers to reproduce and researched how to capture the data needed to confirm
All while constantly monitoring email / 3 slack instances / 1 Microsoft team instance / my queue for fires to put out
In some sense, that's a slew of single things, but it's uncommon for me not to be moving onto the next task as I am winding down the previous one. Nor is the work-flow all in the same vein.
Wow what an incredibly insightful comment! As someone who has worked in support, dev and management I’ve developed practices to mitigate the issues you’ve mentioned - namely rotating devs “on duty” availabe for support tasks and have a dedicated channels for communication where people are not left “talking to the hand” - their words :). But I have never actually thought of it in such a holostic way. Would definitely use it in the future when I’m designing or fixing a company process :)
> Support brains and developer brains are actually not that different.
Others have already commented on this sentence, but I would like to add that the real problem is context switching. For instance, because I know I take too much time switching contexts on my mind, I always have to plan accordingly, like reducing the number of different tasks everyday, or plan some time between very different tasks..
> 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.
I disagree completely. When I am working on a complex problem (just yesterday I was writing a code for non trivial distributed program involving web sockets and multiple channels of communication between several parties), I really need let's say an hour (but it could be more) to "load" the current work in progress implementation into an in-memory model in my head so I can reason about it and continue development. When I have to break this process and deal with something else it completely wastes my time and I have to start from scratch.
This might not apply if I am currently working on some CRUD or other stuff which doesn't require much mental capacity, during those days I can switch in between different tasks easily. But on those other days when I am doing an actual development work involving algorithms and networking I really don't want to be disturbed because I will lose the plot and waste a lot of time.
> 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.
In most companies there is actually a separation between development and support. I think it's rare (perhaps in startups) to have support people just be able to come and start chatting to developers or engineers. The usual process is you have to go through the development manager and he/she decides how to further delegate the work. Developers are probably in a sprint already working on features and don't have time for some ad hoc unrelated work. For that there would be a separate "on call" team which would rotate couple of developers in for 2-4 week stints or so and these would not work on any new development but would be available for fixing urgent bugs.
> 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.
I agree with this. But I would be careful with too much of rotating as if you just keep moving around engineers from projects they are working on to do different work, projects will get super delayed. Usually if I own a project and work on something, there is only 3-4 people who are familiar enough with the domain to be able to work on this. New developers will need couple of weeks of on boarding time. If you start rotating developers around you will waste huge amount of time as new devs need to be brought up on speed to projects and then they will leave in 2 months so you have to do it again.
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.
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.
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).
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.
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.
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.
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 box yourself into the "But, I'm an engineer" corner and decide it's beneath you to talk to customers, you limit yourself. Don't do that. Become a more well-rounded person. Talk to your users. Understand them. Empathize with them. It will make you a better engineer. And if you're a solo founder or part of a small team, it's even more critical that you do this.
Yeah, I totally agree with this. Too often we forget the wide-eyed innocence with which people approach technology, their half-knowledge which secretly terrifies them. They understand, somehow, the intricate pattern they control, and fear messing it up. (Which is actually a very good place to start learning to be a good sysadmin, but I digress...)
One way to empathize with users is to recognize that, to them, your software is a combination of an IRS form and the game Myst. It's filled with inscrutable, unknowable, questions, each of which, in any combination, produce arbitrary state changes in the rest of your program - and perhaps even the rest of the machine (or the internet). What's incredible to me is that this is not an unreasonable state. Real-world software has been forged in the fire of market forces, and contributed by remarkable individuals. Many of them have known computer science theory, but more than a few did not. Indeed, many computer science PhD has gone to his grave without writing a single useful program for other people to use! This, to me, is quite sad.
Compared to the average adventure game that came before it, Myst was actually fairly straightforward in how all of its pieces interacted. Especially because players had basically no inventory.
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.
I don't personally have a wireless printer (mine is networked though), but I've noticed that all of my non-techie relatives have bought a $50 HP in the last 2 years, and somehow they all have it hooked up to WiFi as the only connection. The printers must also implement AirPrint, because they show up on my Grandma's iPhone when she tells an email to print.
Printing photos directly from an iPhone was solved for everyone else and I barely even noticed it happening because I still print from my laptop.
As a developer, a backend app developer for that matter, I still don't know an easy way to do this. I would either sync it to my Google Drive, or fire up a local FTP server on my phone to do it.
Simple joke, don’t get flame baited. I’m sure there is something similar on Android but on iOS all you have to do is AirDrop to your computer. Takes 2 seconds.
I spent 4 years working customer support, technical support and service desk gigs before I got a chance to enter software development (and now DevOps). As much a slog as these jobs could be at times, the soft skills and years of practice walking anyone from a total novice through a power-user through a problem has been invaluable.
I don’t call people users anymore, every employee at my company that I support is a customer of mine - I’ve learned over the years that the vocabulary change can really affect how you interact with people. My team writes internal LOB applications, we’re a medical billing company and not some hip startup; when you call every employee in the company “user” there’s a certain level of animosity (unconsciously best case) - they USE what you provide, it’s the same reason I’ve grown to hate the term “consumer”. A customer is someone you have a relationship with, respect and trust go both ways - ultimately the goal is to have a mutually beneficial relationship.
Being human even I have moments where my level of empathy drops below acceptable levels, when people keep reanimating dead tickets with unrelated issues I can get a little curt (don’t do that, now I’m going to send this to the service desk since development doesn’t work with the spam filter) - but overall I really enjoy the relationships I’ve built with everyone I support. When I get 20 tickets in the morning because a critical application is down I’m not racing because we’re losing $10,000 a minute or to meet an SLA - it’s there’s over 800 people, many of whom I know individually, who are relying on me to get it working again so they can get back to work (and for a production-focused company we have a shockingly low turnover rate, our employees generally love what they do).
I consider this to be a very valuable advice no matter you work with software engineering or not; it's useful for any slightly complicated business from a costumer POV.
I remember a Myers-Briggs-ish consultant taking 40 devs in a room and putting all the INTP/J types on one side and the 3 or 4 of us in the middle or other side and the hanging jaws when he pointed to us and said "Those people are all your CUSTOMERS!"
I've been doing this for over 15 years with an invoicing app I have and I've got to know a lot users pretty well over that time.
My app is simple and easy to use, and I've made "Training Videos" for just about everything you can do with, and I've had years to work out any bugs that have popped up, so I don't get a lot of calls anymore. But every call is a chance to learn something and improve the app and I pay very close attention to those who call.
My approach is that it's never the user's fault, and I tell them that. I work click by click with them to show them how to do something and I tell them if something doesn't work it's my fault and I will fix it. And I also ask them how they think it should work.
Before I made my first app back in the `90s I read a book Apple put out called something like "Apple Human Interface Guidelines". At first glance I thought it was a waste of money, but since I'd spent it I decided to read it all.
It explained some of the history of the Apple GUI and how and why things were designed the way they were, which was basically on things people were familiar with, like "Radio Buttons" and "Checkboxes", etc.
By the time I was done I realized the genius in the approach. I'm still impressed with it. My goal has been to make web apps that the user doesn't have to learn anything to use. That it all works like they expect it should. After 15+ years I've got pretty close now. I rarely get any calls or emails.
How do you deal with conflicting ideas of how something should work?
I'm sure there are a set of users who wish your app worked in one way, while another set of users feel strongly that it works in an opposing way. How do you reconcile that?
I created a shareware Tetris clone for OS X in the mid 2000s and provided my cell number in the readme. I'd get a trickle of calls from all over the world at all times of day. That's where I learned never to have a serial number generator that included the number 0 since it looks so close to the letter 0.
It was weird to be out and about and suddenly get a tech support call, but people were usually really nice.
It's also worth skipping out the letters S and number 5, the letter G and number 6, and the letter B and number 8. I also omit vowels to avoid accidentally creating words in serial codes.
That's a good start, but if the string is meant to be typed by hand it would be better to be case insensitive. Some kind of base 32 encoding would be appropriate.
I actually thought about adding a similar remark to my programs' READMEs just today, but I don't particularly want my snail-mail address floating around the internet any more than necessary. (Maybe I'll get a postbox, if that's not too expensive.)
You can also use a checksum like in IBAN, I have implemented some auto-detection of mistranscribed input based upon that over here: https://github.com/globalcitizen/php-iban
It is very, very difficult to offer phone support as a solo developer, particularly at low price points (below e.g. $5k per year) and for low tech-literacy customers. You can still do it, if you need someone to talk to, you want to do customer development, or you have a customer who strikes your fancy for non-market reasons, but you probably should not message the expectation that you're available.
I always found that my most needy and difficult customers were disproportionate phone users. They also tended to be the lowest value ones so stopping phone support was an easy decision.
My experience with doing phone support for applications is that it is excellent if well-augmented, and absolute garbage otherwise.
Due to a variety of factors, my previous employer provided about 50-50 phone and email support, often with phone as the first point of contact. That worked because phone calls came in with proper context (essentially providing information about who is calling and information about their account status) and I had tools to guide callers when something wasn't extremely basic: most applications are primarily visually- or textually-rich environments, and verbal descriptions require a high degree shared context on both sides (e.g. you are a competent CCNA contacting Cisco TAC, and both parties share a common verbal language to describe non-verbal tools). Absent that, screen-sharing capability is critical, as otherwise phone support is endless dead air of "I'm looking at things you can't see while you describe things I can't see and have no context for, let's both black box everything and pray for telepathy." My current employer doesn't provide that, so phone support devolves into a push button for customers to say, "this issue is urgent!" while support says "probably, but we can't send you screenshots over the phone, so please go away while we write a response that actually provides useful information--you can remain on the phone if you want, but it's going to just be dead air or us talking you down from panic mode while not actually doing anything to address the problem."
Screensharing is absolutely essential. In these days, it should be table stakes. Much as I sometimes hate it in general, it's a huge point in favor of Skype for Business; being able to step into a screenshare or a whiteboard is invaluable.
I cringe when I have to dial into a regular phone bridge. And as much as possible, I try to keep my landline in non-operable condition, so that support requests come in on a more useful channel.
In the absence of screen sharing, if nothing else will do, you could guide the user through using their operating system's built-in screen reader (designed for blind people), assuming you can hear the sound from their computer or mobile device.
I offer phone, email and skype support (as a solo developer). Ratio of support queries I receive is roughly:
90% email
8% skype
2% phone
On my website's contact page I have a few sentences beside the email address saying that you should give as much information as possible about the problem, and that we reply within 1 business day but normally sooner. I think that implies two things: [1] we do actually reply to emails quickly, and [2] email is preferred for support.
Some people just prefer to talk to a human being, at least the first time they contact you. This is either due to them checking to make sure you are responsive and can be contacted, or they are frightened of technology and need a little hand-holding. If I didn't put my phone number of the website I might lose these customers. It doesn't really take much time to deal with, overall.
The only minor issue is that some people (mostly other developers, usually from India) seem to want submit all support requests via skype, and I have to push back at that because [1] it's intrusive and [2] it means I don't have a record of their previous support queries in my email. Unless it's a quick question, I usually email them back. Of course you have to balance the need to provide the support in the way the customer wants to make them happy vs not letting them suck up too much of your time.
Man, I did a job that was nothing but phone support for 8 months, and while I think it was great training for designing UIs that won't confuse people you'd have to pay me a lot to go back to doing that. Many people are not kind, patient, or understanding, and they assume you're unintelligent and uneducated (or else why would you be answering phones for a living?). The misery of that experience was the spur that made me abandon plans for a career in Japanese translation and learn IT (and eventually programming) in the first place.
Support person (at least for the last few years) here, context switching and the issues it creates is a real thing for other roles - not just developers. Everyone needs headphone DND time, both in and outside for the technology sector - it's called concentration time.
A support agent at most tech companies will have to support multiple products in multiple languages and platforms and be ready to provide a useful response to a customer at any time, these responses could be:
Diagnosing code issues,
Diagnosing product issues (internal or external)
Writing code for the customer,
Developing the customer use case,
Working with Engineering,
Finding some free time to learn new products,
Training new agents
etc etc.
This is no easy task and shifting mindsets is sometimes tough.
I strongly echo the comments that documentation is key, if the product docs are written to be consumed by humans it's very helpful support engineers, we're lucky to have great documentation at the company I work so it makes our life easier.
When I did it your absolute maximum unavailable time between calls was supposed to be 30 seconds and if you actually used that time you'd get scolded (even if your stats otherwise looked great).
I'm also a solo developer, and I take support and sales phone calls for FormAPI [1]. I found a nice number on Twilio: (856) FORM-API
I have a license for on-site deployments, and I think every enterprise inquiry has started with a phone call.
I also send a welcome email to new customers where I say that I'm happy to have a call to talk about their requirements or questions. I also use Drift [2] for live chat, and I've handled a few support cases on there.
My advice: I don't think this is an optional thing. You don't solve the problem by removing the phone number from your site. If you're getting too many calls, you need to improve your self-help support pages, or hire another person to help with the phones.
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.
What a mundane post and simplistic topics. Yet it was outstanding. How come I loved reading it? Nice work Non.
One thing that wasn’t a big point, but I hope most people appreciate: Founders/developers/key employees doing some phone support is not tactical grunt work, it can be a strategic, powerful weapon.
In essence, it’s white glove, world class customer service. That alone is good, but what makes it so powerful is it’s on a very small list of things that AmaFaceGoogSoft and other large companies can almost never match you at. In fact forget beating you, they often do poorly at it. Every know anyone who left angry after dealing with F500 support?
In a past life I’ve used high six figure “enterprise” support agreements, w/VIP status. Yes, way better than the Windows consumer help line, but hard even then to match your service. 1MM/yr enterprise support doesn’t buy a product dev or exec. Ironically, it’s easy to lunch with them, but they’re not handling your daily tickets.
Your sales person (you I guess :-) should use it as a club against big companies and do your best to beat them to death with it.
Other things you touched on can also be strategic. Gaining valuable insights (admittedly not the only channels for this) that optimizes your roadmap, occasionally is the difference between staying afloat and sinking.
Of course the reality check is, how much time can you allocate when not only is development a life blood role, you probably wear other hats as well? I don’t think there’s a stock answer, depends on team/company/stage/everything else in the balance.
Anecdotally, I can say one customer relationship built this way turned out to be the connection that led to the acquisition of my company. However as usual, it was impossible to foresee when the contact request email came in.
I mean it as a compliment that you’re post seems deceptively ordinary (speaking plainly is good), I hope people will mine the true value of it. Thanks for writing it, best of luck to you going forward.
Interestingly enough I've found through my own company that it's not so much whether or not you're solo but rather the price of your software that determines if you can economically offer phone support or not.
The short version, under the $1000 price point it's very hard to economically offer free phone support as part of your product. If you're product is subscription based then the same metric applies using the total lifetime value of your customer. Under that price it's very hard to do, whether your a solo developer or a company without charging for support.
I'm launching an app soon, and was planning on making customer service an available and plentiful commodity, not hiring any employees yet, so therefore I'll be the de facto phone support guy. I hadn't considered the emotional benefit of both urgency from the negative, and encouragement from the positive, I was mostly thinking about hearing first-hand the bugs, use cases, user experiences, etc, and being able to put out any fires asap. Thanks!
This was very well written. Effective communication with people is far more challenging (and rewarding) than the communication with devices that we developers do on a day to day basis. It’s easy to get lost in that cloud, and lose touch with the people we’re building for.
In startups, this aspect can too quickly get shunted off to a QA or CS personnel, and problems get abstracted into incident tickets (that are often ignored in favor of the Next Big Feature). That seems to me to be giving up one of the classic fundamental advantages of a small business: the personal touch.
I absolutely _loved_ doing phone technical support, but I don't do it any more because I can't afford it. I earn far more money as a developer and I can't turn that down. I wish good support was valued more highly , and compensated accordingly so I could afford to keep doing it.
Many people admire Steve Jobs, sometimes to the point of mimicking him by wearing jeans and black turtleneck sweaters.
Steve Jobs would sometimes answer to customer support calls. This was in order to understand the customer, their frustrations, and how to work through them with a better product.
Great article. An effective engineer needs to know how to work with non-engineers. Unless, you're on a team composed of purely engineers and don't need to interact with non-engineers. But even then, it's a good skill to hone for potential career changes in the future.
This reminds me of Word Perfect's unlimited free phone support years ago. Though the call to Orem, UT during business hours was neither free nor inexpensive, the service was excellent and part of the reason Word Perfect was so beloved...reveal codes being another reason.
Thank you very much. I am very glad to see this as #1 here.
There is a typo on Voicepaper's description in iTunes. It reads "Voicepaper is a test to speech voice reader..." instead of "Voicepaper is a text to speech voice reader".
What I'm curious is how he markets his apps and what kind of revenue target he goes for.
I know just posting something on the app store is not the way to go. As an iOS developer I know it's tough to be a solo app store developer successfully.
I'll be interested to read your follow-up post on the differences between offering phone support in Japanese and English. A few of the interactions you described here sounded distinctly Japanese to me.
Could one of the folks down-voting this please explain? Did this come across as sarcastic, or offensive? I'm honestly curious, for example, whether most westerners would be as courteous, or whether the taboo against asking about proficiency would feel the same in both cases.
Interesting. I always thought putting personal phone number in your app is a bad idea, but you raised some good points there. I might consider to do that if I release an app for local market.
The point here is not what the advantage of phone support is but to provide the service personally. You can outsource anything, but if you read the article, the learnings you get from doing it yourself are invaluably useful.
The article says he only offers it in the Japanese version:
"I wrote my phone number in the help section of the Japanese version only, since I live in Japan and it is a JP number. I might try it in English too in the future..."
It used to end with "... and this is what what happened." I would prefer "...and it saved my business" or "...it made me quit." Even removing that clickbaity suffix makes me feel better.
"This is what happened" is just an inefficient use of words, not really harmful. There's not anything meaningful you could append in five words. It didn't save or kill his business, nothing so dramatic.
"You'll never believe what happened" is clickbait. "This is what happened" is about on par with an extraneous comma.
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.