From Telecom to DevOps Cloud Engineer: How She Switched to the DevOps Team in 13 Months

After more than ten years in telecom, Alba broke into DevOps as a Cloud Engineer — before she'd even finished the bootcamp. If you come from a non-software background and wonder whether the jump is even possible, this is the story to read. TechWorld with Nana DevOps Bootcamp review.

Watch Alba's Complete Journey

See the full story — from radio networks in Venezuela and France to deploying cloud infrastructure in the US — and the exact study routine that made it work.

[NOTE BY EDITOR: YT VIDEO RELEASED SOON ON TWN CHANNEL!]

Meet Alba 👋

Hi, I'm Alba, a DevOps Cloud Engineer based in Chicago, USA 🇺🇸.

I'm originally from Caracas, Venezuela, and I spent more than ten years in the telecom industry before moving into DevOps.

Today my work is on the cloud side of mobile networks. I deploy cloud-native services into customer environments for Tier-1 mobile operators across the US and Canada, working a lot with Kubernetes, Helm charts, Terraform, Ansible, and CI/CD pipelines.

Every customer environment is different, so I'm constantly exposed to new tools, different cloud providers, and different setups.

What I like about my position is the perspective it gives me — I understand both the telecom side and the cloud infrastructure behind modern mobile networks. And honestly, most days it doesn't feel like work 🙂

"I'm constantly learning all the time. I love it. When I start working, sometimes I don't even feel it's work."

From Optimizing Radio Networks… to Building the Cloud Behind Them

Alba currently works as a DevOps Cloud Engineer at Forsk, a software company in the telecom industry, after spending four years there as a radio frequency (RF) engineer.

Alba's story is a clean example of a career switch that a lot of people assume isn't realistic: moving from a specialized, non-software engineering field into DevOps — with no Linux, no Git, and no cloud experience to start with.

She studied telecommunications engineering in Venezuela, worked for Huawei on a major operator's network, then moved to France for a master's in mobile communications and years of RF optimization work. In 2021 she relocated to Chicago and joined Forsk as an RF engineer.

Then she did something most people only talk about. While working full-time, she taught herself the fundamentals, worked through the IT Fundamentals course and the DevOps Bootcamp at 5 a.m. before her workday, and — before she'd even finished the bootcamp — walked into her manager's office to pitch a role that didn't officially exist yet.

She had only the advanced modules left to go. About a month later, she was on the DevOps team — same company, no gap, no new job search.

Here's Alba's journey in her own words 👇

Let's start from your career beginning. What did you do before DevOps?

I studied telecommunications engineering and started working right away for Huawei Technologies on Telefónica's network, which is a big operator in Venezuela.

After about a year, I decided to move to France to do my master's degree in mobile communications.

After my master's, I worked as an RF optimization engineer in Europe. Then in 2021 I moved to the United States, and joined Forsk, a software company focused on the telecommunications industry.

I spent four years there as an RF optimization and design engineer.

For most of that time, my work had nothing to do with Linux, cloud, or infrastructure. I worked with radio network design tools.

You had a stable telecom career. Why walk away from it?

I was completely sure I wanted to change. It had been a long time that I wanted to make it happen, but I didn't know how.

"I was really bored and tired how slow the RF world is moving, and how we heavily rely on the telcos and vendors."

The RF industry is small and depends heavily on mobile operators and vendors. And the market itself was shifting — machine learning, more automation, a lot of the work moving to the cloud.

A lot of RF work was already being automated. I didn't want to wait around for that to catch up with me.

"I need to do a big jump now before later, like in ten years. I don't see myself doing that jump way later."

Editor's Note: Notice what drove the decision — not panic about being replaced, but boredom and a desire to grow. Alba moved toward something she found exciting rather than away from something she feared. That motivation is one of the strongest predictors of who actually finishes a career switch and who stalls halfway.

Why DevOps specifically — not cloud engineering or pure software development?

DevOps sat right where I wanted to be. I was interested in the whole application lifecycle and in operations, but I didn't want to write code from scratch all day.

DevOps was the middle ground.

"DevOps was working with the cloud industry. It was also operations and dev — it puts both together. I was not willing to start coding from scratch all the time, so to me it was the middle ground between dev and operations."

Coming from telecommunications, I also knew I'd have far more room to grow in IT than in the radio world, where you depend heavily on a handful of telcos and vendors.

You already had AWS certifications. Why weren't they enough?

I started the way a lot of people do: a couple of crash courses, a bit of Python, a bit of Linux.

Then I got my AWS Cloud Practitioner, then the AWS Solutions Architect Associate. I knew the services and the infrastructure — but I'd done everything through the console, and I knew real projects don't work like that.

I was missing a piece, and I didn't even know what it was yet.

So I went and read actual job descriptions to see where my skills fit. That's when it hit me.

"AWS was just a little part of the puzzle. And when I start reading all the qualifications, I was like, wow, I have to see CI/CD pipelines. What is this? Kubernetes, Docker, Infrastructure, Terraform. Ansible — I was completely lost. And then it's when I really realized the huge gap that I had."

That was the turning point. I realized I couldn't just keep collecting certifications, because at that point I wasn't actually building anything. I needed to close the gap for real.

Editor's Note: This is one of the most useful moves in Alba's whole story, and it costs nothing: she reverse-engineered her learning plan from real job descriptions. Instead of guessing what to study, she let the market tell her — and immediately saw that the certifications alone left a hands-on gap.

You found TWN through YouTube. Why pay for a bootcamp instead of just learning free?

I started watching YouTube videos, and that's when I found your channel. I loved the way you explained difficult topics in an easy way. But I needed structure.

I tried to self-study from videos for a while, and it didn't work for me.

"I was jumping from this video to this video, and there were many repeated information. I really feel that I need a structured path."

I spent about two months that way and felt I was wasting time. When I looked at the bootcamp syllabus, the path was clear — start with the foundations and build up tool by tool, with hands-on projects that mirror real production work.

Coming from telecom, that structure mattered. I wasn't comfortable with Linux before, and I had no idea about Git at the start — what's a rebase, what's a merge, how do you handle all these files.

Building up from the basics before the advanced tools is exactly what made everything click.

"Imagine if I could have started with Kubernetes, with a YouTube channel, and then I don't know Linux, I don't know Git — it was completely a waste of time. For DevOps you need quite a structure, because it's not an easy field. You can get overwhelmed and you can throw in the towel pretty easy."

Why start with the IT Fundamentals course instead of going straight into the bootcamp?

I wanted the full picture of how software actually gets built before I went deeper — that was the part I didn't have.

I was working at a software company, so the course also helped me make sense of what the people around me did every day.

"It was interesting to me, understanding the software development lifecycle and the position of my colleagues — I saw the tester, the developer, I saw my manager in the agile, how they were working with all the concepts. It was going to give me the big picture of software development, and then I could move to the bootcamp so I will have stronger foundations to build on top."

That foundation made stepping into the bootcamp much smoother. Looking back, it was the right call.

You did all of this with a full-time job. What did your schedule actually look like?

Before I enrolled, I told myself: I need to organize myself. I have my nine-to-five, and after work I'm tired, exhausted, stressed — I don't want to do anything.

So I decided to give myself the first energy of the day, before anyone else got it.

"I woke up very early in the morning, at five a.m. every day, working on my bootcamp."

On weekends is where I work the most, because I had more time — at least three, four hours, Saturdays and Sundays.

I had to sacrifice a lot of my time off. The first energy was to myself, not to my job, not to anything else — to myself, to be able to move forward into my goals.

It took about eight months in total, with breaks in between — I had a planned eye surgery that took me out for a while, and some vacation.

The hardest part was getting back into the routine after a long break. But what carried me wasn't motivation, it was consistency.

"Commitment, consistency is key. You need to work at least one percent daily, doesn't matter. It builds on top every single day."

At the beginning you have the motivation of the first few months, but what keeps you on the road is consistency. Motivation disappears fast.

And the hands-on projects were what made it genuinely enjoyable.

"When we start putting together all the hands-on projects, it was like magic. It was like, wow, this is how your real production environment is working. Connecting all the technologies, connecting all the tools — it was amazing to me."

Here's the bold part: you didn't apply for a DevOps job. You created one. How?

There was no open position. But I knew the company needed it — we had a small US team, and the one person doing all the DevOps work was overwhelmed.

I wasn't even finished with the bootcamp yet. I'd completed the core modules — pipelines, Kubernetes, the AWS infrastructure — and only had the observability part left.

But I decided to talk to my manager anyway, because there was nothing to lose.

"To me it was like a win-win situation."

I went in and showed him exactly what I'd been doing.

This is what I have done the last year. I have obtained my AWS certifications. I'm enrolled in this bootcamp. This is my syllabus.

"I showed him the syllabus and he was pretty impressed — not only for all the hard work I had done, but for the initiative that I took to move forward just by myself."

He said he'd talk to headquarters in France. I waited about a month, and then I got the approval to switch into the DevOps team.

There was a real advantage to doing it inside my own company:

"I already know the team, I already know the company, they know me, they trust me, and they know my hard work. So it was like a layer of friction that they removed."

But it's not automatically easy, either:

"You need to change the perception of the people that work with you. They know you as RF, not as DevOps. That takes time — to build confidence, to build trust, to build ownership."

Editor's Note: This is the part we want everyone to take away. If you already work somewhere — even in a completely non-IT role — and you see your company hiring or struggling for DevOps help, you have an advantage an outside candidate doesn't: they already trust you. Alba turned "there's no open role" into a role by showing initiative and a track record. That's a move you can copy.

Weren't you afraid you'd get the role and then fail at it?

No, because for me there was no going back to RF.

If I fail, I will need to push and prove myself again — but I will do it, and I will move forward.

Everyone at some point, we were all beginners, we were juniors.

You learn from your struggles. If everything is too easy, you don't learn from it."

Once you switched, did the bootcamp actually map to the real work?

Yes — almost immediately. When I started looking at what the team was doing, I kept recognizing it.

"I saw this, I learned this in the bootcamp. It's exactly the same — maybe different tools, but how you work with Docker, Kubernetes, it's exactly the same.

When I was looking at this, I was like, wow, I understand this. It felt so good, to be honest."

The tools weren't always identical. We used Terraform and Ansible like in the bootcamp, but our CI/CD was on Azure, not Jenkins. That didn't matter.

"It's not like Jenkins, but you can translate it — it's the same. In the end, the concepts are the same."

Certifications vs. hands-on projects — how do they compare?

They complement each other.

You need the certification foundations to really know the services, but you need the bootcamp and the hands-on projects to apply them in real environments.

Certifications matter more in some situations than others:

"When you're coming from a non-IT career, it's way more difficult to prove your knowledge. So the certificates help to prove that you have the knowledge, and that you're still building on top."

What's next for you?

Right now I'm going deeper into Kubernetes, because I use it every single day.

"I just passed the CKAD certification. Now I'm going to start preparing for the CKA — it's valuable for my work, because I work a lot with Kubernetes."

After that, I want to move toward AI infrastructure.

I would really like to translate my DevOps knowledge, maybe moving towards AI infrastructure. We also have very exciting projects coming with AI at my current company.

You switched careers from a non-IT field, full-time, in your thirties. What would you tell someone who feels it's too late or too risky?

First, be honest with yourself about whether you actually want it — not because it's trending or because you saw it on LinkedIn.

That honesty is what keeps you consistent.

Then, stop waiting.

"At any age, it doesn't matter. As long as you're learning and you're motivated, you can do it. You need to have the mindset. There is nothing you can lose — if you don't like the switch, you can always go back to your previous career, because you already have that experience. So what can you lose?"

Don't wait until everything is perfect, because you will never know all the technologies, you'll never be an expert on all the tools and be ready. If you wait for the perfect moment, you won't do it.

On AI — use AI in your favor, don't fear it:

"You cannot be afraid all the time of doing the first step, because otherwise you get paralyzed."

Alba's Key Takeaways for Career Switchers

✅ Switch toward excitement, not away from fear

Alba moved because she was bored and wanted to grow — not because she was scared. That motivation is what gets you to the finish line.

✅ Build the foundation before the flashy tools

Linux and Git first, then Docker, then Kubernetes. She took IT Fundamentals before the bootcamp on purpose, and it's why the advanced topics clicked.

✅ Let job descriptions write your study plan

Reading real qualifications showed her the exact gap her AWS certs left behind — and what to learn next.

✅ Protect a daily window; consistency beats motivation

5 a.m. every day, three to four hours each weekend day. One percent daily, compounding.

✅ Look at the company you're already in

If your employer needs DevOps help, you have trust an outsider doesn't. Pitch the move with a track record

✅ Prioritize the first role over the first raise

The first DevOps job is the hardest to land. The experience is worth more than an immediate salary bump.

✅ Build your projects as a portfolio, not for a certificate

Do the work for a reason you'll actually use later. The quality follows.

---

Ready to make your own switch into DevOps?

Alba's story is proof that a non-software background isn't a dead end — it's a starting point.

She went from a decade in radio networks to a DevOps Cloud Engineer role inside her own company — approved for the role before she'd even finished the program — with no gap in employment, while working full-time and learning at 5 a.m.

The turning point wasn't talent or luck. It was structured learning plus the mindset to act on it.

Whether you're coming from a completely different field or you already work in tech and want to go deeper, the IT Fundamentals Course and the DevOps Bootcamp are built to take you there — concepts first, then the hands-on projects that map directly to real production work.

You can download the full syllabus to see exactly how the program is structured before you start.

If Alba could break into DevOps from radio networks, there's a path here for you too 😊