[cyberferret]

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.

[kqr]

> And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'.

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

[blt]

I wrote myself off as "bad at being supportive" for a long time. Eventually I realized that being supportive is a trainable skill just like software development or healthy eating. I am still not great at it, but getting better. I respectfully urge you to examine yourself and try to modify your habits rather than looking for excuses.

[koliber]

Agreed that it is trainable if you are bad at it in general.

I don't think the parent was saying that he is bad at emotional support and being empathetic. He said he is having trouble switching from the developer brain mode into the empathetic human brain mode.

This is something I noticed myself as well, especially when working from home. When I worked in an office, the commute home provided time to decompress and switch off my focused analytical brain. By the time I would get home, I would be in the proper mindset. I guess you could say that there are benefits to a commute after all!

[dkersten]

> I guess you could say that there are benefits to a commute after all!

Absolutely, its forced idle time where your mind can drift. Although, over time, I find myself just getting more and more tired during my commute to the point where anything I do think about is quickly lost now... :/

[jdironman]

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.

[crispyambulance]

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.

[dangerlibrary]

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

[fapjacks]

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.

[scott_karana]

There's a truism about gender: when men complain, it's because they want something solved. When women complain, it's because they want sympathy.

Doesn't mix and match well unless you consciously try to handle it differently.

[cubano]

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

[dhimes]

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.

specifically, #39:

http://showcase.netins.net/web/tash/rules/rules.html

[wickawic]

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:

https://english.emmaclit.com/2017/05/20/you-shouldve-asked/

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.

[crispyambulance]

Definitely not claiming "scientific rigor" nor do I think it would be worth it to even try.

The argument-after-work scenario, however, has been around for a long time and is well known by marriage counselors.

https://hbr.org/2016/04/how-to-not-fight-with-your-spouse-wh...

[dangerlibrary]

FTA:

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

[justinpombrio]

A story from my father:

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.

[wjnc]

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

[hutzlibu]

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

[nicoburns]

I've found a short (20 minute) nap can help a lot with this.

[codingdave]

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.

[shrimp_emoji]

But some people's work continues after the commute. Humanity is untenable; embrace the cold, unempathic autism. It is the only way.

[Cthulhu_]

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.

[sspiff]

I've found that doing anything distracting can help.

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.

[Tistron]

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

[LoSboccacc]

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)

[mk89]

oh, and I thought I was a bad person... interesting that others have the same issue (?)

[friendzis]

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

[laumars]

> And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'.

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

[jrochkind1]

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.

[danso]

> I did it for 10 years, but more recently have moved away from phone support as much as possible (or delegated to others to do).

Somehow you managed to also keep the business going as its sole developer without going insane or bankrupt. If your luck turns bad and you have to find job security at a Big TechCo, at least the prospect of being stuck in an open-office-layout won't scare you :)

[cyberferret]

It would probably freak me out TBH! :) After so long working for myself from home, the prospect of being in a busy office with people milling about and a hundred conversations going on at once will probably reduce me to a quivering wreck under the desk! :P

[reaanb]

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.

[erader]

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.

[cyberferret]

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.

[b3lvedere]

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

[erader]

Totally. It should be in the GTM checklist for every product/feature

[dogles]

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.

[erader]

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.

[kgbdrop1]

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.

In any case, my 2 cents.

[seer]

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

[jventura]

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

[richardknop]

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

[tomcooks]

Great presentation and insights on a profession that is kind of considered less important by a lot of people, thanks

[oblio]

I think the main reason for the hierarchy we have in IT is basically necessity, and I say this as someone who's more into devops & co.

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

[gxs]

Some of the most successful companies in the world, with a reputation for excellent customer service offer single channel support through cases only, because phone support is too inefficient.

Kudos to you for staying afloat for so long the way you did.

[cyberferret]

Thanks. I did try to coerce my customers away from phone support (by reducing my hours that I would respond to calls) and try to get them to use a ticketing system (Zendesk)). That worked to a certain extent, but still didn't fully eliminate those that were already used to phone support.

A ticketing system also helped with another big bugbear of mine - getting back to customers with long support ticket cycles, i.e. where I had to make bug fixes, test and deploy. I was frequently forgetting to get back to them to advise them I had fixed an issue. The ticketing system helped me to keep track of that.

Following up with customers was another mind loop that detracted from the freedom of mind I needed to develop good code.

[friendzis]

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.

[BurningFrog]

The obvious solution is to have phone support days or hours.

If you only accept support calls at certain times, you can plan to do development at other times.

[cyberferret]

When dealing with local clients, that is certainly a possibility (and indeed was the case with me at one stage). But when you have customers all over the world, you have to basically be on call 24hours a day (also the case with me).

[majewsky]

Do you allow clients to shake you out of your sleep?

[ajeet_dhaliwal]

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

[justinmoh]

I agree.

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

Your dedication of doing it for ten years amazed me.

[paulryanrogers]

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.