I Became the Most Wanted Software Support Engineer of My Town
This guide will help you make the list as well.
Join the DZone community and get the full member experience.Join For Free
It’s been more than 20 years since I started my first professional job as a software support engineer. So, back when everyone was still amused by the Lotus 1-2-3 and later the HTML thing, I was about to step into a whole new world of software development industry — the supporting phase.
You may also like: 10 Things Every Programmer and Software Engineer Should Know
It didn’t take me long to realize that there are “things that I don’t like” about this job. So, the younger me soon started to analyze the situation and offer solutions — some being a bit extra idealistic. (Well, it’s called ‘being young’ for a reason, right?).
Excluding the unrealistic sides, the younger me had some acceptable problem-solving skills. It helped me to work my way up from a not-so-welcome software support engineer to the much-loved one.
Who Am I to Give Software Support Advice?
Simply said, I built my career on the basis of being a software support engineer, but that’s just the tip of the iceberg. Throughout my career, I struggled with so many difficulties that thought me priceless lessons. The reason why this article exists is that some of them were so profound that they still come in handy at my 40s — even though I’m currently a DevOps engineer.
Where Did It All Begin?
The whole story began when the company I worked for back in the 90s decided to put me in charge of enterprise software they had just developed.
It was a regular first-day-of-job thing and I was [obviously] a bit nervous. At the same time, I had this excitement-like feeling in my gut. After all, I was going to become the guy who supports the team like a healer video game character. (The Lycan in Dota 2, if you will).
Things didn’t come up as glorious and poetic as I expected. There was no standing ovation, and it was more of the Miss Gulch’s unwelcome arrival at the farm in The Wicked Witch of the West.
You could hear the harmonica being played and sense the tension as ireful-within people were waiting to meet us. So, as you guessed, it was exactly like the entrance scene of Sergio Leone’s masterpiece "Once Upon A Time In The West".
However, I spent the next couple of weeks trying to change the situation for the better. And I actually did manage to successfully build up trust and bond with the employees of the customer company.
So, the following software supporting best practices are based on what I did in real life — and not just a bunch of positive manners written by a Charles Ponzi-like con artist!
1. Don’t Forget That Humans Don’t Speak the Code Language
SaaS support is totally different from supporting a locally-run software. This is where you must engage with human beings and show your social skills as well as code writing.
When I entered the seven-floor building of our customer company, no one was interested in talking about the codes. Instead, they were ready to burst out, complaining about every single aspect of our product.
I didn’t want to become the know-it-all of the room to reject every statement using some technical terms. So, I simply listened to them. This simple act of mine led to a miracle.
The employees of the customer company (aka our real end-users) revealed many issues of our product in no time.
Plus, I also found out that they were frustrated about the lack of two-way communication. They could not share their thoughts with my company because the guy who wrote the software was clearly too ego-boosted to listen.
So, here's the lesson: if you don’t want to fail in your job as a local support engineer, speak the human language. Avoid utilizing the cumbersome terminology of coding and put the end-users at their ease talking to you.
2. Plan for the ''You Are Not Welcome'' Status Quo
As mentioned before, there are moments where you must support software for an unhappy, frustrated, and displeased customer. So, be prepared for some eye-rolls and aggressive speeches all the time.
Let your guard down and be empathetic towards the end-users of your product. It’s not your job to protect the software or the company behind it. Stop engaging in debates over how extraordinary your company is, and, instead, support the end-user — as it’s your real job.
Of course, I’m not saying that you must agree with whatsoever the end-users are suggesting; however, it’s vital to know that defending your company or product blindly will have nothing in return.
In my case, the customer company’s employees had a disappointing experience with the former technician. They were already looking at me as another guy who’s there to tell them that they’re wrong — and the software is heavenly great.
My empathetic attitude helped them get rid of the stereotypes and see me as someone who’s there for them (and not against them).
I accepted the fact that the end-user is not happy with the product. Instead of trying to prove the opposite, I asked them to let me fix things.
3. Bear in Mind That It’s Neither B2B nor B2C — It’s an SSE2SSE Situation
I’m quite sure you’ve never heard of an SSE2SSE situation because I made it up; however, not hearing the term before doesn’t mean not encountering it. Regardless of the word, you’re already familiar with the concept.
Okay, SSE2SSE stands for Software Support Engineer to Suspicious Software End-User. It refers to the fact that the customers of enterprise software are always disbelieving towards your product because they’ve spent a lot to buy it.
They always think as if you were there to fool them and indirectly force them to continue using the product. You should ready yourself for an awkward situation where you’re allegedly the person who’s against the team while your job is to support it.
When my company asked me to support the new software, I had no idea what’s expecting me in the customer company. Soon, I discovered that it’s only “suspicion” which is waiting for me back there.
I decided to back my ideas up with as much document and data as possible. It wasn’t like ‘we must do that — period.’ By contrast, it was like ‘we must do that because…’
This straightforward and open approach made me a valuable part of the team that’s able to fix the issues. If becoming a successful software support engineer is your goal, prepare yourself to utilize some Gödel's proof techniques!
Don’t avoid explanations and let the users know why, how, or for what reason you’re taking an action. (They have every right to understand what’s happening to their enterprise software which cost them thousands of dollars).
4. Never Become a Yes-Man but Avoid the Opposite as Well!
So far it was all about the end-user (aka your customer). I can see those Braveheart Mel Gibsons in the crowd ready to sacrifice whatever they have for the customers. But please, don’t!
Being a professional supporter is not all about giving. By contrast, a real-deal software support engineer knows how and when to utilize the power of “no.”
I’ll pass the mic to Steve Jobs to clarify the idea. He used to ask former Apple head of design Jony Ives “how many times did you say no today?” That’s because Jobs believed the art of saying no keeps you focused and brings success in time.
However, it’s more of a CEO act to say no and reject things all day long. You better avoid such an attitude as a support engineer.
Balancing the yeses and noes is actually the key to success in this job. Neither the full Steve Jobs approach nor the Jim Carrey manner in the Yes Man will come in handy in software supporting processes.
5. Act Like a Spy, Think Like a Double Agent
Okay, let’s face the music; working with two companies comes with some data transmission. No matter how minding-only-your-own-business you are, there are some situations where you must transfer information to make communication possible.
Anywise, it’s not the fact that you may look like a spy that should worry you. Actually, it’s not being able to employ this opportunity for better performance that must unease you.
You have the chance to become the communication bridge between your company and the customer company. Why not use it as a tool to make the whole process a win-win game for everyone?
You’re not going to need to reveal the mystery of the Vatican Secret Archives. Don’t think of it as a risky and disloyal act.
What you have to do, however, is build up trust utilizing some secrete-looking information. The client needs to feel like you’re on their side to put in honestly. Giving them such info makes them have faith in you to start the collaboration.
I used to attend all the meetings between my company and the client company simply because both sides trusted me. I could be the link and keep both sides of the business in touch without having them directly touching each other.
The Best Way to Become a Complete Software Developer
Opinions expressed by DZone contributors are their own.
Front-End: Cache Strategies You Should Know
10 Traits That Separate the Best Devs From the Crowd
Manifold vs. Lombok: Enhancing Java With Property Support
How To Use Pandas and Matplotlib To Perform EDA In Python