The message comes more regularly now than it used to. A junior support agent, a year or two into the role, reaching out to ask whether the move into automation or engineering is actually possible. Often they have already been reading posts about my own path. They want to know if it is real, or just a nice story someone tells to make the field sound more interesting than it is.
I always reply. Not because I have a formula, but because I remember being exactly that person and not knowing who to ask.
Over time, though, I have noticed I am watching for specific things in the people who reach out. Not credentials. Not portfolio links. Something earlier and harder to fake than either of those. This is what I actually look for.
The first question I ask
Before I say anything useful, I ask them to be specific about what they want. Not "I want to do automation" or "I want to get into engineering." Those are directions, not destinations. I want to know: what problem do you actually want to own?
The answer tells me a lot. Someone who says "I want to stop manually copying data between systems every week" is describing a real pain they feel, a problem they have already started thinking about solving. Someone who says "I want to learn Python and get a different title" is describing an outcome they have seen others have. Both are valid starting points, but only one of them has the internal engine that makes the path sustainable.
The people who make it through the transition are almost always the ones who started with a specific frustration, not a general ambition. Frustration is fuel. General ambition tends to run out at the first long plateau.
The quality that predicts everything else
I am not looking at certifications yet. I am not asking about side projects or GitHub profiles. I am watching for one thing: does this person notice problems before they are assigned them?
The support agent who comes to me and says "I keep fixing this same issue manually every week, I looked at it and I think we could automate the lookup step" has already crossed the most important threshold. They saw something. They thought about it. They formed a view. Nobody asked them to.
That quality, proactive noticing, is the single strongest predictor I have found of who will successfully make the transition into a more technical role. More than IQ, more than formal training, more than natural aptitude for tools. You can teach someone how to use Zapier in a day. You cannot easily teach them to habitually see what is broken and wonder why it has to stay that way.
If someone has been doing support for two years and has never independently flagged a process problem to their manager, that is worth naming honestly. Not as a disqualifier, but as work to do before the technical work.
The task I give before any career advice
If I think someone is serious, I give them an assignment before we go any further. Not a course to take or a tool to learn. I ask them to document one thing the team genuinely needs that nobody has written down yet.
It can be small. A runbook for the most common ticket type. A step-by-step for a process they do from memory. A plain-English explanation of something a new hire would have to figure out on their own. The subject almost does not matter. What matters is how they do it.
Do they ask the right questions to understand what the reader actually needs? Do they share it with someone on the team to check whether it is actually useful, or do they just hand it back to me? Do they update it when they notice a gap, or do they consider it done once it is written?
This one task tells me more than a technical assessment. Documentation is unglamorous. It requires you to think from someone else's perspective. It requires patience with ambiguity. And it produces something real that the team can actually use. Those are exactly the qualities that matter in the kind of engineering work I do, building automations and systems that other people depend on.
A lot of people skip this step mentally. They want to talk about the interesting parts. The ones who engage with it seriously, and especially the ones who come back and say "I wrote it and realised I didn't actually understand step three as well as I thought" are almost always the ones who later ship something worth shipping.
What actually separates the ones who make it
I used to think it was technical aptitude. Having spent years now watching people at various stages of this transition, I no longer believe that is the primary variable.
The people who make it have a specific tolerance for the boring parts. Building automations, real ones that production systems depend on, involves a lot of tedious work. Reading API documentation. Tracing why a webhook fires twice under one condition and not at all under another. Writing error handling for edge cases that only appear months after launch. Keeping runbooks updated when nobody is asking you to.
There is a gap between "I want to build automations" and "I am going to spend several months doing unsexy prep work and shipping imperfect early versions." Most people who tell me they want to make the transition are picturing the former. The ones who make it are the ones who can honestly commit to the latter.
That is not a judgment. It is just a description of the work. And being honest about it early saves everyone time.
The timeline conversation
The last thing I always make sure to cover is timeline. Not to discourage anyone, but because I made the mistake early on of thinking this was a shorter path than it is, and I want to spare people that particular frustration.
My own move through different roles and responsibilities took years, not months. My first real automation work happened at a large international NGO while I was still primarily in an ICT support role. The "automation engineer" part of my title came later, after I had already been building things for a long time. The title caught up to the work, not the other way around.
I have seen people become genuinely capable automation builders in twelve to eighteen months of deliberate effort alongside their day job. I have also seen people spend three years taking courses and never ship anything they are proud of. The difference is not how long it took. The difference is whether they were building real things for real problems along the way.
A three-month bootcamp outcome this is not. But a real transition, over real time, producing real work? That is absolutely available to someone in a support role who is willing to put in the kind of effort I have described. I know because I watched it happen for myself and because I have seen it happen for others since.
The actual point
I am not a cheerleader for everyone who tells me they want to make this move. Some people who reach out are genuinely ready to start. Some are still a year away from being ready to start, and that is fine too. What I am trying to give them is an honest read on where they actually are, not a motivational speech.
If you are reading this and you are the person who keeps noticing the broken things nobody asked you to fix, who has already started documenting things that were not documented, who finishes a frustrating manual task and immediately starts thinking about why it has to be manual: you are probably already on this path. You may just not have named it yet.
That is a good place to be. Sharpen the noticing. Ship something small. Find someone who has made the move and ask them the specific question you actually have, not the general one about whether it is possible.
If that person is me, get in touch. I read every message.
Comments