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