The title came about 18 months after the work did. By the time anyone at the top US-based company I work with called me an Automation Engineer, I had already rebuilt three of the most repetitive workflows in the department, cut a roughly six-hour onboarding process down to under an hour, and automated a weekly report that used to eat my Friday afternoons. Nobody assigned me those projects. Nobody told me automation was now part of my role. I just kept solving problems that were clearly solvable, and eventually the title caught up.
If you are in IT support right now, wondering whether a path to a larger technical role exists without going back to school or waiting for someone to hand you a promotion, this is the honest version of how that transition works.
The Support Desk Is the Best Vantage Point You Will Ever Have
Most people who build automation for a living figure out what to build by talking to product managers, business analysts, or department heads. Support people know what to build because they live it. Every ticket that comes in three times a week is a workflow begging to be automated. Every process someone explains verbally because "it is not written down" is documentation that does not exist yet. Every manual step that takes a human 20 minutes, but that a rule could handle in 2 seconds, is a clear improvement waiting to happen.
When I was at a large international NGO in an ICT support role, I had access to years of ticket history. I did not need anyone to tell me what the high-volume, low-complexity problems were. They were right there in the queue, week after week. Password resets. New-hire account setups. Printer drivers on specific builds. Access provisioning done by hand because nobody had built a standard process yet.
If I could see the pattern, I could often build the fix.
That visibility is an asset most people in support do not realize they have. You know which processes are fragile. You know which onboarding steps get skipped under pressure. You know exactly how long it takes a human to do something a script could handle in seconds. That knowledge is not nothing. It is the foundation of every good automation brief.
The First Automation That Changed My Trajectory
At the NGO, I built a provisioning checklist driven by a shared form. New-hire requests came in, the form captured the key fields (name, department, start date, manager), and that data drove a standardized setup sequence: create the Active Directory account, assign the right group memberships, set up the email alias, provision the VPN profile. Still partially manual, but the checklist meant no steps were skipped and nothing had to live in someone's head.
Later, at the top US-based company, I took that concept further. New-hire requests fed into an automated workflow that handled the first several steps without a human touching anything. The original onboarding process took roughly half a day end to end. After the automation, that same sequence ran in under an hour, with better consistency than when people did it by hand.
I did not need a new title to build either of those things. I needed the access rights I already had, the pattern knowledge I had built from months of tickets, and a willingness to spend a few evenings actually learning the tooling.
Building in Plain Sight
One thing I got wrong early: I tried to build quietly and only show the result once it was perfect. That instinct is understandable. It is also wrong.
The better move is to share what you are working on before it is done. Not as a formal pitch. Just an update in a 1:1 or a Slack message: "I noticed we process new-hire accounts manually every time. I am building something to handle the first few steps automatically. Should have a draft ready to test by Friday."
Two things happen when you do this. First, your manager or colleagues often add context you did not have, which saves you from building the wrong thing. Second, and more importantly, you become associated with the category of "person who improves things" rather than just "person who handles tickets."
At the NGO, my ICT Officer knew I was building tools on the side because I told him. When a bigger automation project came up, he asked me to lead it. That was not luck.
The Compounding Effect
Once you ship one visible automation, something shifts. The expectations placed on you go up, but so does the trust budget people extend to you. Colleagues start coming to you with "is there a way to automate this?" questions. Your manager starts thinking of you for projects that involve systems and workflows, not just tickets.
By the time I transitioned into a role that had Automation Engineer in the title, I had already been doing the work for over a year. The transition was not a leap. It was a paperwork formality.
The career shift is not about convincing anyone you can do the work. It is about having already done the work, in plain sight, until the evidence makes the case for you.
The Concrete Path If You Are at the Beginning
If you are in IT support right now and want to make this shift, here is the sequence I would actually follow:
Start with the ticket queue, not with a tool. Look at the last three months of tickets. Find the top five problems by volume that are also low-complexity. One of those is your first automation project. You already know what it is. You probably already resent doing it by hand.
Learn one tool and go deep. Pick one automation platform your org already licenses or one that is cheap to run. Power Automate if you are in a Microsoft 365 environment. Zapier if it is already in the budget. n8n if you want something more flexible and are comfortable with a bit more setup. Learn it well enough to build a real workflow in it, not just watch tutorials. The specific tool matters less than the depth of your understanding of it.
Build something real, not a demo. A working automation that saves 30 minutes per week is worth more for your career than five impressive demos that never ran in production. Preferably, build it for a problem your team actually has, not a hypothetical one.
Document what you built and what it changed. One paragraph. The problem, the approach, the result. Even if the result is "saves roughly an hour each week," write it down. This is the kind of evidence that makes performance conversations and promotion cases much easier to have.
Tell people what you are doing. Not as a brag, as a professional update. Share the outcome in your next 1:1. Add it to any self-evaluation you fill out. Put it in your working log. The work does not count if no one knows it happened.
A Note for the Person Reading This in Nairobi
The career path I am describing does not require a visa, a move to a tech hub, or a computer science degree. It requires a ticket queue you can analyze, a tool you can learn for free or very cheaply, and a problem worth solving.
I started at Tier 1 support. I built things I was not asked to build. I told people I was building them. I shipped things that worked. That sequence repeated, and the title eventually caught up.
The automation career is not a destination you apply for. It is a reputation you build, one visible workflow at a time.
If you are doing IT support right now and the path to something bigger feels unclear, start with the thing that is wasting your Friday afternoons. Automate it. Do it where your manager can see the result. Then do it again.
The title will follow the work. It always does.
If any of this maps to where you are right now and you want to talk through the first move, reach out.
Comments