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.
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 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!
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... :/
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.
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.
Doesn't mix and match well unless you consciously try to handle it differently.
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.
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.
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.
The argument-after-work scenario, however, has been around for a long time and is well known by marriage counselors.
> 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.
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'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.
Commuting, listening to a podcast or audio book, playing a video game for 15-20 minutes, ...
Whatever takes your mind away from matters at work.
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  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.
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.
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.
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 :)
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.
> 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.
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.
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.
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.
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)
- 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.
In any case, my 2 cents.
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..
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.
You can't have a product without developers. You can have a product without QA, support, Ops, etc.
Managers are another story cause there we get into more social aspects...
Kudos to you for staying afloat for so long the way you did.
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.
If you only accept support calls at certain times, you can plan to do development at other times.
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.
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.
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.
But I digress.
King's Quest seems a more fair comparison IMO.
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.
I see you’re an Android user!
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 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).
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.
Kind of feel like the "Maytag Man" now.
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?
It was weird to be out and about and suddenly get a tech support call, but people were usually really nice.
Just throwing this out there in case the problem comes up again: https://en.wikipedia.org/wiki/Base58
If I ever develop something really small and useful one day I’d love to get post cards from around the world!
Did you ever hear from TTC?
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."
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.
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:  we do actually reply to emails quickly, and  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  it's intrusive and  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.
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
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.
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  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.
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.
I wrote about it here: http://www.followsteph.com/2006/10/10/is-technical-phone-sup...
I then followed it up with an article discussing whether or not companies should charge for support based on my findings in the previous article: http://www.followsteph.com/2010/10/19/should-software-compan...
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.
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.
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.
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".
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.
Has anyone been able to monetize phone support as an upsell?
"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..."
"You'll never believe what happened" is clickbait. "This is what happened" is about on par with an extraneous comma.