Software engineers hate doing technical support, and they can’t talk to clients. These are often considered to be basic truths of the software industry, but are these real limitations? (Spoiler alert: I think no).
At Blueshift, we recently restructured and merged our development and support teams. We now have a single team of software engineers that both develop and support our application, working directly with clients. They work closely with a small team of functional consultants who are business/domain experts, but the responsibility for all technical support sits with the engineers, including first-line phone and email support. This has been an overwhelmingly positive change for us and our clients, but not without some friction!
In this article, I’ll outline the key principles that have worked for me, and that I believe can help any software engineer excel and thrive in technical support. We generally enjoy the things we excel at, so I believe success is a major step towards enjoyment in this area. Studies have shown that positive thinking has a significant impact on how we feel, so our expectations will also have a significant impact on our satisfaction.
Acceptance
The sooner you accept technical support as a core part of your job as a software engineer, the happier you will be doing it. If possible, skip the first four stages of grief, and jump straight to acceptance. If not, try to at least accelerate the process. I find a good tub of ice-cream can help a lot.
It helps to remember why it’s better for you to do this than to outsource to a separate support team:
Going directly to the software engineer gives the best support outcomes for clients.
Having a direct feed of client questions and bugs gives the tightest possible feedback to allow you to improve your software.
Working directly with clients will offer more opportunities for you to incidentally learn more about the business domain, which will make it easier to understand and develop features.
Belief
Closely related to acceptance is the belief that you are capable of handling the quirks and challenges that come with technical support and client communication. Don’t box yourself in with a fixed mindset that says all you can do is write code, but instead, adopt a growth mindset. As a software engineer your job is to solve hard problems, and these are just different but equally solvable problems.
And remember if some challenges seem insurmountable, you don’t have to solve every problem yourself, you have a team of other software engineers and functional/business consultants to assist you.
Ownership
Ownership in a support context has two parts:
The first step of triage after a call or email should be to determine the right person to own the issue and respond. That may be yourself, or it may be a functional consultant or another engineer with more experience in the problem area. Take the time first to understand the problem and assign it to the right person. If it’s a technical issue, don’t pass it over the fence to a non-technical consultant, but equally, if it’s a question about available functionality or best practice, pass it on to someone who can follow up appropriately.
Once the appropriate person is identified, that person should take ownership of the situation from end to end. This means following through to a complete solution, until the client says the issue is resolved. Resist the urge to throw the issue over the fence if small points arise that are outside your usual scope of practice, but instead, follow up others to get the assistance you need while keeping ownership and responsibility for the issue. And if you hit a wall and feel like you want to give up, ask for help.
Focus
Don’t try to do development and support at the same time. This is a recipe for frustration and inefficiency. Support is by nature full of interruptions, which kill the deep thinking and focus required to do development.
As a team, set aside at least one person each day who will purely focus on support, and not attempt any development. Even if by some miracle the support backlog gets to zero, that person should not start any deep thinking tasks as they still need to be ready to pick up any new support calls or emails. And again, acceptance is a big help to minimizing interruption frustration.
Translation
You may find that some clients communicate in language so foreign, you wonder if they are still speaking English. This often occurs when you and the client have different mental models for understanding the business domain, and when different clients use different language for the same concepts, which again may differ from your internal language. It may also happen when you have an incomplete understanding of some area of your software. Remember the client is trying their best and may also find it challenging to communicate with you as a technical person!
When this occurs:
Don’t stress. This is normal.
If on a phone call, be willing to just say you don’t understand. Ask them to send an email explaining their issue and say you will follow them up or call them back.
Ask a functional/business consultant to translate or fill in gaps in domain knowledge.
Ask other software engineers to fill in gaps in system knowledge.
Imperfection
A big cause of fear and stress in support is the social and time pressure you feel (from various sources) to provide a solution in a short time period. Remember, even the worst problem is probably not a life and death situation, so keep consequences in context and apply the appropriate level of stress and pressure to yourself. Although the client may apply pressure, a polite, professional response will smooth over most situations and buy you the time you need to resolve the problem.
Accept that you are not perfect, sometimes you (like all of us) will make mistakes, and that is fine. Having said that, take steps to mitigate the frequency and impact of mistakes. If you are unsure, get someone to review your investigations before responding to the client, and be willing to ask for help, especially on sensitive issues or tight timeframes.
Resolution
Embrace the satisfaction and primal joy that comes from knocking cases off the support backlog. If you can resolve a few small cases, the sense of achievement you get can give you the motivation you need to smash out a more complex, longer case.
Where possible, resolve support issues promptly by adapting them to create work items in a normal development process. For example, if a client raises a bug, rather than fixing the bug as part of the support case, communicate with the client to establish the priority and a required time frame for the fix then spec out the problem, solution and deadline and create a work item to be picked up by a developer. This work item can be resolved by a developer in an interruption-free workflow and give you more interruptible capacity for other issues.
—
So next time you are assigned to technical support, keep these principles in mind. Accept that this is part of your job, and it’s going to give the best result for the business and your clients. Believe that you are capable of succeeding and growing in this area. Triage cases to the right people and take end to end ownership of cases that you pick up. Accept that interruptions are a part of support, and don’t try to mix focused and interrupted work. Understand the differences in language between yourself and the client, and get help to translate when necessary. Be willing to make mistakes, but take steps to mitigate them. And embrace and channel the satisfaction that comes with bringing cases to resolution.
