Trying to move from technical support to software development is hard. From not knowing where to start to recruiters not realizing your value, it can feel like an uphill battle.
I worked in Salesforce as a triage agent and moved all the way up to Tier 3 support, before moving to software development.
Today, I'm an architect at Salto, helping Zendesk and Salesforce teams use proper software development tools.
In this article, I'll share some lessons and tips on switching your career from tech support to software development.
Why move from tech support to software development
Your reasons for wanting to switch careers are entirely personal. I had a few reasons, and I hope some of them resonate with you:
As mentioned earlier, I went all the way from triage to Tier 3 support. This was a very fulfilling journey, but I didn't want it to end there. I wanted a next step.
I knew support leadership wasn't for me as I wanted to retain my hands-on skills, so Engineering, R&D, or any other version of that, was the logical next step for me.
(Potentially) better pay
I use the word potentially because when I was a Tier 3 Engineer, I knew I made more money than many software developers out there. However, this was definitely not the norm and generally speaking, a career in software development is more lucrative than one in support.
I'd say, though, try not to make this your primary motivation as software development is hard. You need more than a desire for better compensation to do well in this field.
With that out of the way, let's go over some concrete steps you can take to accelerate your journey to software development.
The steps that I will list below all share a common goal: You need to become as technical as possible in your tech support role.
This will make the transition to software development less painful and can really help you close some gaps.
Move to technical support
This guide is for folks who are already in tech support. However, if you are in customer support for a non-software company (i.e a general customer service role), your best bet is to try to move to a technical support role, supporting a SaaS product (Salesforce, Zendesk, Intercom, etc.)
You can still use the techniques described below to make the move to technical support.
Learn the basics web development first
Many people trying to move to software development start their journey by learning a programming language like Python.
While I think this is great, I think it is much better to start with web development. Why?
Web development has the fastest return on investment when it comes to seeing the results of your effort. You can study for a couple of hours, and very quickly, you'll have a basic web page up and running.
Python, on the other hand, runs in a vacuum. You learn about if/else statements, for loops, etc., but it's unclear how this translates to a real-world application.
When I started learning Python early in my tech support career, I was constantly interrupted with questions like:
But where would this code run?
How can I make this code accessible to others?
How much more do I need to learn to be able to create an app? And where would the app live? On my computer? On a hosting provider?
All these questions distracted me, and while I knew all about if/else statements, I had no idea how to use that in the real world. It was a knowledge that had no use for me.
This can also really help you show your skills to others, something I will touch on in a bit.
Here's a good course with all the concepts I think you need to know to get started: The Complete Front-End Web Development Course!
About learning programming
Despite my argument above against starting your journey by learning a general-purpose programming language (as opposed to web development, which is much more specialized), at some point, you'll do well to learn more about the core concepts of programming.
For this, I highly recommend Head First Java
. This is an incredible book. One of the best ones I've ever read.
The authors do an incredible job explaining core programming concepts in an easy-to-understand way. I cannot recommend this highly enough.
The only problem with this book is that, as I explained above, many of the programs you will write will run in a vacuum, and it'll be hard for you to understand how to use that knowledge in the real world.
Understand how the internet works
Along the same lines of web development, it is extremely useful to understand how the internet works at a high level.
You should be able to describe what happens when you enter a URL on your browser and how the information is displayed on the web page.
At a minimum, I highly recommend that you understand:
This is important because, most likely, you are supporting a SaaS product and these products run on the web. Therefore, they are prone to experience performance issues due to network outages, etc.
So it's very, very important that you have the skills to help your customers troubleshoot basic network issues.
This can also help you stand out amongst your colleagues. Many of them won't really understand how the internet works, and if you are the exception, you'll quickly become the go-to person for any network-related questions.
This is great for getting more visibility from your managers and more respect from your Engineering/R&D team.
Create a simple web page to solve a gap in your company
This is crucial. You've gone through a web development course in Udemy or YouTube, but now what? If you don't use those skills, you'll quickly forget them.
The best way to keep those new skills fresh and get experience is to create an app that solves a tiny problem in your support organization.
Let me give you an example:When I was a Tier 3 engineer at Marketo, we wrote very long queries to pull data from our logs. These queries were hard to remember, they had a ton of different parameters, and they were hard to reason about.
After I learned how to create a very basic web page with just HTML and JQuery, I made a simple page that would automatically generate the query for you. All you had to do was put the parameters on the web page, and it would magically generate the entire query for you.
I pitched this to my Tier 3 colleagues, and they loved it. We started using it.
This was also very important because I was able to add this to my resume. And when talking to recruiters, I could tell them about my (basic) experience solving a real-world problem with web development skills.
Learn the basics of databases
Knowing the basics of databases and SQL can go a long way in making you a more technical tech support rep. Why?
Databases are used everywhere. There isn't a single app out there that doesn't use some sort of database. As such, they are prone to experience database performance issues, etc.
Depending on which app you support, this knowledge can help you be more proficient at retrieving customer logs or becoming the go-to person for database-related problems.
Dealing with recruiters
This is probably one of the most frustrating topics on this list.
My experience is that most recruiters, for some reason, don't understand that tech support is a highly technical role. To many of them, tech support is the same as being a call center agent answering billing questions (nothing wrong with that, it's just not what we do).
I had many failed attempts at convincing recruiters that I was a technical person and that I could do software development. It was like having "support" stamped on my forehead, and it would negatively influence any conversation I had.
There's no silver bullet for this issue. I got lucky because my experience was being a tech support rep at Salesforce, and so I was able to land a job in Salesforce software development. It would've been much harder if I had tried to break into a more generalized software development role.
That said, there are some things I think can help:
Make your resume look as technical as possible
I know we are very proud of our customer-facing skills, excellent CSAT scores, and experience managing others (if you are a tech/team lead).
Recruiters don't care about that. Make your resume all about your technical skills. Mention all the technologies you know and how you used different tools to support your customers. Talk about the type of issues you resolved.
This can help you look more like a software developer in their eyes, which can help you at least get an initial call with them.
Create a portfolio of things you've built
Say you did 3 Udemy or Coursera courses on software development. Put them on your LinkedIn under the Featured Content section. Make sure the whole world can see them.
If you've created some basic stuff, put all that in a GitHub repository and add it to your LinkedIn. This allows you to say to a potential recruiter:
"I have very relevant experience in technology, and I've also worked on some open-source projects. Check out my GitHub repo"
This sounds much better than saying:
"I only have tech support experience. I've done a few online courses, though."
You are saying the same thing, but it's all about how you frame it.
Ok, so you've learned web development and the general concepts of programming. You have a couple of sites you can show off to recruiters. Now what?
None of the above will make you land a software development job just like that. Instead, as I said at the beginning of this article, the idea is to become as technical as possible in your tech support role.
Because the more technical you are, the higher the chances for you to get involved in software development stuff, for example:
You may be pulled into more complex escalations
You may be involved in providing more direct product feedback to R&D
You may be able to create an app that solves a problem at your company
All of these things move you closer to the world of software development.
With that, you could apply to very highly complex support roles. For example, many companies have a position between Tier 3 and R&D. This role is usually called Supportability Engineering or Customer-Centric Engineering.
In these roles, you are not writing code but directly troubleshooting the code. For example, you are looking at stack traces and reviewing logs that Tier 3 wouldn't understand.
As I said, this puts you closer to software engineering than a traditional support role. Also, many of these roles will have "Software Engineer" as the title, even if you are not writing code.
And you know who loves those titles? Recruiters ;)
That's all I have for now. If you have any questions, please reach out on LinkedIn
or contact me at the Support Driven