To successfully transition into cloud computing, aspiring tech professionals must prioritize early, hands-on practice and community mentorship over raw certifications. That is the advice of Shuufaay Kibeey US, who recently spoke with news-lens in an exclusive interview. Acknowledging that breaking into IT from a non-technical background in political science and oil & gas was a steep mountain to climb, Shuufaay Kibeey US said finding a supportive network through WirfonCloud changed everything. Ultimately, he notes, while certifications establish a baseline, it is the actual building and experimenting in sandboxes that transforms a career pivot into a reality. Read the excerpt:
Excerpt:
Every major career pivot begins with a single spark. How did you first cross paths with WirfonCloud, and looking back, in what specific ways did that initial encounter completely alter the trajectory of your professional and personal life?
My spark came out of a hard moment. I was working in Oil and Gas when COVID hit, and like a lot of people in that industry, I watched the work dry up week by week until I was eventually laid off. I wasn’t just looking for a job — I wanted something that would challenge me, pay the bills, and actually have room to grow.
That’s when Fai Kitav, a close friend, mentioned WirfonCloud. He didn’t just drop the name and move on — he invited me to sit in on one of their Zoom calls so I could see it for myself instead of taking his word for it. That single call was the spark. What stood out on that call was the experience and calmness of the instructor; Mr. Banjika Ngo, the way they explained complex concepts, highlighting the numerous opportunities that Cloud Computing provides as well as the excitement of other students. Looking back, that one conversation changed the trajectory of my career in a special way.
Considering your background in Political Science and the Oil & Gas industry, what pivotal moment or insight motivated your successful transition into Cloud Engineering, and how did you overcome the initial learning curve?
My path here wasn’t a straight line. Political Science gave me a foundation in analysis and understanding complex systems, and Oil & Gas gave me years of practical, high-stakes industry experience. But the pivotal moment came when COVID hit the energy sector hard. Watching layoffs ripple through a company and an industry I’d built a career in made one thing clear: this wasn’t a temporary dip, it was a structural shift. At the same time, I couldn’t ignore what was happening in tech; cloud computing was accelerating, demand for skilled engineers was climbing, and companies were investing in it even as other industries pulled back. That contrast was the insight: one path was shrinking, the other was clearly growing. The decision to pivot into Cloud Engineering came from that side-by-side reality, not just hope that something else might work out.
The learning curve, honestly, hit me on every front at once. I was learning technical concepts; networking, systems, cloud architecture: completely from scratch, with no prior tech background to lean on. That came with real imposter syndrome; it’s humbling to go from being competent and experienced in one field to being a total beginner in another. On top of that, I had to balance studying with the practical pressure of bills, family support and a job search, and even once concepts started clicking, there was a real gap between understanding theory and actually being able to do the work hands-on.
What got me through was a combination of things, not any single fix. WirfonCloud gave me structure and mentorship so I wasn’t trying to figure out the right path alone. I built a disciplined daily study routine, because consistency mattered more than intensity. Hands-on labs and projects closed the gap between “I understand this” and “I can do this,” which is where real confidence came from. And I leaned on support from people like Fai Kitav, Thecla Mbunwe, Yvonne Meilam, and others around me, who kept me grounded when the imposter syndrome got loud.
Looking back, the hardest part wasn’t any one obstacle; it was holding discipline, support, and practice together at the same time until they reinforced each other.
Given your diverse learning journey, encompassing mentoring, bootcamps, and self-study, how do you strategically approach learning new cloud technologies or solving complex technical problems you haven’t encountered before?
My approach comes directly from how I learned in the first place; through a mix of mentoring, structured bootcamp training, and self-study. So I don’t rely on just one method when I hit something new. I treat each new problem the same way: break it down, draw on the right resource for that specific piece, then make sure it doesn’t disappear once I’ve solved it.
The first thing I do with any unfamiliar technology or problem is break it into smaller, manageable pieces. Cloud systems can look overwhelming as a whole, but almost every complex issue is really a handful of smaller, more approachable ones stacked together. Isolating those pieces tells me exactly where my gap in understanding actually is, instead of feeling stuck in a vague, general way.
From there, I lean on a mix of resources depending on what the problem calls for. If it’s something foundational, I’ll go to official documentation. If it’s something gnarly or non-obvious, I’ll bring it to mentors or experienced colleagues, or pull from the bootcamp and WirfonCloud community and that network has stayed valuable well past the training itself, because there’s almost always someone who’s already run into the same wall.
Once I’ve actually solved it, I take time to document the process and reflect on what made it difficult in the first place. Writing it down, whether that’s a quick note, a runbook, or just a clear explanation to myself turns a one-off fix into something I can reuse. And reflecting on why it was hard helps me catch patterns, so I’m not just collecting solved problems; I’m actually getting faster and sharper at the next unfamiliar one.
That combination of breaking things down, pulling from the right mix of people and resources, then documenting and reflecting is what lets me approach something I’ve never seen before with confidence instead of dread.
With your current role involving migration from AWS to Azure, what were the most significant technical and operational challenges you faced in adapting your AWS expertise to the Azure ecosystem, and how did you address them?
Moving from AWS to Azure tested whether I actually understood cloud concepts or had just memorized AWS’s specific implementation of them and it turned out to be a mix of both. The technical challenges showed up on several fronts at once. Mapping AWS services to their Azure equivalents wasn’t always one-to-one — IAM doesn’t translate cleanly to Azure AD, and S3 doesn’t behave identically to Blob Storage, even when they solve similar problems. The networking model was its own adjustment, since VNets and NSGs follow different logic than VPCs and security groups, even though they’re solving the same underlying problem. On top of that, Azure’s terminology and console navigation slowed me down at first simply because muscle memory from AWS didn’t transfer, and cost management and governance worked differently enough that I had to relearn how to think about resource organization, not just where to click.
Operationally, the challenges were just as real. Coordinating cutover timing to minimize downtime meant planning around dependencies I couldn’t always see until I was deep into the migration. Getting stakeholders and teams aligned on the plan took as much communication as it did technical work. Documentation and knowledge transfer mattered enormously, since the team needed to operate confidently in Azure after I was done, not just trust that the migration worked. And managing rollback risk meant building in safety nets for the moments when something didn’t go as planned mid-migration.
I addressed all of this with the same multi-pronged approach I use for any unfamiliar problem. Microsoft Learn and Azure certifications gave me the structured foundation. Hands-on labs and sandbox testing let me validate my understanding before touching anything in production, which mattered enormously given the stakes of a live migration. I leaned on mentors and teammates with deeper Azure experience whenever I hit something genuinely unfamiliar rather than burning time guessing. And I built comparison references mapping AWS concepts directly to their Azure counterparts, which let me translate my existing expertise instead of starting from zero.
The biggest lesson from the whole migration was that cloud expertise isn’t really about knowing one platform’s commands; it is about understanding the underlying concepts well enough to re-map them when the platform changes underneath you.
Reflecting on your journey from a non-IT background to a Senior Cloud Computing Engineer, what is your vision for the future of cloud technology, and using Wirfon Cloud as reference, what single piece of advice would you offer to individuals aspiring to make a similar career transition?
Looking at where cloud technology is headed, I think the biggest shift is the convergence of AI, Machine Learning and cloud infrastructure. Automation and AI-driven operations are becoming embedded in how cloud systems are built and managed, not just a layer added on top. At the same time, multi-cloud and hybrid environments are becoming the norm rather than the exception, which I’ve experienced firsthand managing an AWS-to-Azure migration. Companies aren’t betting on a single platform anymore; they’re building for flexibility across ecosystems. My vision is a future where the most valuable cloud engineers aren’t the ones who know one platform deeply, but the ones who understand the underlying concepts well enough to move fluidly between platforms and increasingly AI-augmented systems as the landscape keeps shifting.
If I had to give one piece of advice to someone considering a similar transition, drawing on what actually got me here through WirfonCloud, it would be this: don’t try to do it alone, and don’t wait until you feel “ready” to start getting your hands dirty. I came from Political Science and Oil & Gas; about as far from a traditional IT background as you can get and what made the difference wasn’t waiting until I felt qualified. It was finding a community and mentors through WirfonCloud who could guide me, combined with getting into hands-on labs and real practice early, instead of trying to learn everything in theory first. The certifications and concepts matter, but they only became real once I was actually building and breaking things in a sandbox. Community plus hands-on practice, started early rather than “eventually,” is what turns a career pivot from a hopeful idea into an actual outcome.
Your journey with WirfonCloud has been a significant chapter in your professional evolution. Looking back at your time there, what specific projects or cultural elements within the organization most accelerated your growth, and how did that environment help solidify your transition from a non-IT background into a senior-level engineer?
The single biggest accelerator was what I term the “capstone project”, which pulled together cloud migration, building out networking, server, and security infrastructure, and DevOps practices, all tied directly into the certification track. It wasn’t a series of disconnected exercises; rather, it was structured the way real engineering work actually is; where migration decisions affect infrastructure design, infrastructure design affects security posture, and DevOps practices tie all of it together into something that actually runs. That integration mattered, because it mirrored real workplace problems rather than isolated textbook scenarios, and it forced me to make decisions under genuine ambiguity, the same way I would on the job, instead of following a predefined answer key. By the time I finished it, I had something concrete to point to in interviews and in my portfolio, but more importantly, it was the project where I stopped feeling like a student working through assignments and started feeling like an engineer solving real problems.
That capstone landed as hard as it did because of the culture around it. The mentorship gave me access to experienced engineers who’d actually lived through the kinds of problems I was hitting for the first time, so I wasn’t guessing in the dark. The peer community mattered just as much as learning alongside others making the same leap from non-IT backgrounds meant I never felt isolated in the struggle, and seeing peers work through the same uncertainty normalized it instead of making it feel like a personal failing. And the structure and accountability, deadlines, milestones, regular check-ins; kept momentum going during a period where, frankly, it would have been easy to lose discipline given everything else going on in my life at the time.
Looking back, that combination is what solidified the transition for me. The capstone gave me the technical proof that I could actually do the work at a senior level, and the mentorship, community, and structure around it gave me the support system to get there without losing confidence along the way. WirfonCloud didn’t just teach me cloud engineering; it built the environment that made the transition stick.
With the upcoming launch of WirfonCloud Academy with Foundation First as first step, based on your own experience, how will this foundational focus protect newcomers from hitting a wall when they encounter complex, real-world cloud architectures?
WirfonCloud’s Foundation First addresses exactly the gap I felt most acutely in my own transition. Coming from Political Science and Oil & Gas, I didn’t have a technical baseline to fall back on and every new cloud concept had to be built from nothing, often at the same time I was trying to understand the cloud-specific tooling sitting on top of it. That’s a hard way to learn, because you’re solving two problems at once: the fundamental concept and its cloud implementation.
What Foundation First does differently is separate those two problems. By starting with Linux and Networking fundamentals, things like the OSI model, DNS, subnetting, and firewalls before ever touching AWS-specific services, newcomers build the underlying mental models first. Then, when they get to AWS Cloud Practitioner, Solutions Architect, and Terraform, they’re not learning two things simultaneously. They’re applying a foundation they already trust to a new, specific context. That’s the difference between memorizing steps and actually understanding why those steps work, which is exactly what falls apart the moment a real-world architecture doesn’t behave like the tutorial did.
In my own experience, the moments I hit a wall were almost always foundational, not cloud-specific, a networking concept I didn’t fully grasp, a Linux command I was using without understanding what it actually did under the hood. Those gaps don’t show up in a simple lab exercise, but they show up fast in a live, real-world architecture with multiple interacting pieces. A program that closes those gaps before introducing complexity means newcomers hit that complexity with something solid underneath them, instead of discovering the gap at the worst possible moment; mid-project, under pressure, with something live depending on it.
That’s the real protection Foundation First offers: it doesn’t make the complexity of real-world cloud architecture disappear, but it makes sure newcomers are standing on solid ground when they finally meet it.
Interviewed by Etienne Mainimo Mengnjo
