Hello 👋

Welcome to another week — and another opportunity to grow into a strong, confident DevOps, Infrastructure, or Platform Engineer.

Today’s issue is brought to you by The Engineering Ladder — where we share practical, career-shaping lessons in DevOps and Software Engineering to help you level up with clarity and direction.

💡 PS: Before we dive into today’s topic, I want to quickly share something important with you…

If you’ve been following The Engineering Ladder, you already know one thing I believe deeply:

👉 Real tech careers are built on evidence, not just interest.

That belief is exactly why we built CloudOps Academy.

CloudOps Academy is a hands-on training program for DevOps Engineers, Infrastructure Engineers, and Platform Engineers who want more than theory.
We focus on helping engineers build real systems, understand how production environments work, and gain the confidence to perform in real roles — not just pass interviews.

At CloudOps Academy, you don’t just “learn tools.”
You learn how to:
✅ Design and operate real cloud infrastructure
✅ Work with Docker, CI/CD, monitoring, and automation the way teams do in production
✅ Think like a reliability-focused engineer, not just a script writer
✅ Build projects you can confidently explain in interviews
✅ Grow from uncertainty to clarity with structured guidance and mentorship

Our goal is simple:
to help you become job-ready, confident, and credible as an engineer.

If you’re serious about building a strong DevOps or Cloud career — and you want guidance from engineers who are actively working in the field — we’d love to talk.

📞 Phone: +237 653 583 000
📧 Email: [email protected]

No pressure.
Just clarity on whether CloudOps Academy is the right next step for you.

Now, let’s get into today’s lesson 👇

In 2023, an engineer I know made a decision that scared him.

He had spent four years building backend services. Python, Django, PostgreSQL, REST APIs. He was good at it. His team valued him. His manager liked him. By every conventional measure, things were going well.

But he was bored.

Not the casual kind of bored that passes after a good sprint. The deep kind. The kind where you wake up on Monday morning and feel nothing about the work waiting for you. The kind that tells you something needs to change.

He had been watching the DevOps and platform engineering space. The work looked interesting to him — infrastructure, automation, deployment pipelines, the systems underneath the systems. He wanted in.

But he had a fear that I hear from almost every engineer who wants to make this kind of move.

He said:

"Blaise, if I pivot now I am basically starting over. Four years of experience — gone. I will be competing with people who have been doing DevOps their whole career. Why would anyone pick me over them?"

I told him he was looking at it completely wrong.

He made the move. Within eighteen months he was a senior DevOps engineer at a company that specifically hired him because of his backend background — because he understood the systems his pipelines were serving in a way that pure infrastructure engineers often do not.

He did not start over. He redirected.

There is a difference. And understanding that difference is everything when it comes to making a pivot within tech work.

Let me address this directly because it is the belief that stops most engineers from making moves they should make.

When you pivot within tech — from backend to DevOps, from software engineering to data engineering, from individual contributor to platform engineering — you do not lose what you built. You carry it with you. And in most cases, what you carry is more valuable in the new direction than you realise.

The engineer who spent four years in backend before moving to DevOps understands how applications are structured, how they fail, what they need from infrastructure, how developers think about their tools. That understanding is not something a pure infrastructure engineer develops easily. It has to be lived.

The backend engineer who moves into data engineering understands data modeling, API design, system reliability. The platform engineer who came from individual contributor work understands developer experience from the inside — what friction actually feels like, what tools actually help, what documentation actually gets read.

Your previous experience is not baggage you are dragging into a new field. It is a lens that lets you see the new field in a way that people who only ever worked in it cannot.

The engineers who make the strongest pivots are not the ones who successfully pretend their old experience did not happen. They are the ones who figure out exactly how it applies — and then make that connection visible to everyone who is evaluating them.

This sounds obvious. Most engineers skip it entirely and go straight to building a list of gaps. That is the wrong order.

Start with a honest inventory of your current skills — not just the technical ones. Think about:

Technical foundations. What languages, tools, and systems do you know well? What problems have you solved? What systems have you built or operated? These do not disappear when you change direction. They become context.

Problem-solving patterns. How do you debug a system you do not understand? How do you approach a problem with no obvious answer? How do you make decisions under pressure with incomplete information? These patterns transfer completely across every technical discipline.

Collaboration and communication. How do you work across teams? How do you explain technical decisions to non-technical stakeholders? How do you write documentation? How do you run a post-mortem? These are not soft skills sitting on the side of your career. They are load-bearing.

Domain knowledge. If you have spent three years building fintech systems, you understand payment flows, reconciliation, regulatory constraints, data integrity requirements. If you pivot to DevOps in a fintech company, that domain knowledge is immediately valuable — you understand what you are building infrastructure for.

Write this inventory down. Be generous with yourself. You are not padding a CV. You are building an accurate picture of what you are actually bringing into the new direction.

Now identify the gaps. But be precise about what a gap actually is.

A gap is not "I have never done DevOps before." That is too broad to be useful.

A real gap sounds like: "I do not have hands-on experience with Kubernetes. I have not configured a CI/CD pipeline from scratch. I have not worked with infrastructure as code tools like Terraform. I have not operated a system at the infrastructure level — I have only consumed the infrastructure."

Specific gaps have specific solutions. Broad gaps just produce anxiety.

For the backend to DevOps pivot, the real technical gaps are usually:

Linux and systems administration depth. Networking fundamentals — DNS, load balancers, firewalls, VPNs. Container orchestration — Docker deeply, Kubernetes at least broadly. Infrastructure as code — Terraform or Pulumi. CI/CD pipeline design and operation. Cloud provider services beyond the basics an application developer would use. Monitoring and observability from the infrastructure side.

That list looks long. But here is the thing — if you have four years of backend experience, you already understand why each of those things matters. You have consumed the output of all of them. You just have not operated them.

That changes the learning curve significantly. You are not learning concepts from scratch. You are filling in operational experience around concepts you already have context for.

This is where most pivot attempts stall.

Engineers identify the gap. They find courses. They watch videos. They read documentation. They feel like they are making progress. Then they apply for jobs and struggle to answer questions about real operational experience — because they have knowledge but not experience.

The bridge between knowledge and experience is building things.

Not tutorials. Not guided labs where every step is spelled out. Real projects where you make real decisions and deal with real consequences.

For the backend to DevOps pivot, this looks like:

Take one of your existing personal or portfolio projects and build a full CI/CD pipeline around it from scratch. Not using a template. From a blank configuration file. Make it build, test, containerise, and deploy automatically on every push.

Provision real cloud infrastructure using Terraform. Not just one server — a proper environment with networking, security groups, a database, a load balancer, and an application running on it. Destroy it. Rebuild it from scratch. Do it until it feels natural.

Set up a Kubernetes cluster — even a small one on a cheap cloud provider or locally with Kind. Deploy your application to it. Configure health checks. Simulate a failure. Watch how Kubernetes responds. Break things on purpose and fix them.

Instrument a running application with Prometheus and Grafana. Set up real alerts. Respond to a real alert. Write a runbook for what you did.

Every one of these projects gives you something that courses cannot: a story. A real thing you built, a decision you made, a problem you hit and solved. That is what experienced interviewers are looking for and what distinguishes engineers who have learned DevOps from engineers who have done it.

This is the part most engineers get wrong when they are trying to communicate the pivot to potential employers or their own leadership team.

They apologise for it.

They frame it as a gap they are trying to close. A risk the hiring manager should be willing to take. Something that needs to be explained away.

That framing guarantees that whoever is evaluating you will see it as a weakness. Because you told them to.

The honest, accurate framing is completely different.

You are not a DevOps engineer with no experience. You are a backend engineer with four years of production systems experience who has spent the last six months building serious infrastructure projects and is now bringing both perspectives to a role that benefits from exactly that combination.

That is not spin. That is accurate.

Think about what a hiring manager for a DevOps role actually needs. They need someone who can build reliable infrastructure. They also need someone who understands the developers who will use that infrastructure — someone who can design pipelines that fit how engineers actually work, write documentation that developers actually read, and have conversations about reliability that connect to what the application team actually cares about.

A pure infrastructure engineer who has never written application code has to develop that understanding over time. You bring it on day one.

That is a genuine advantage. Say it that way.

The fastest pivots I have watched happen did not happen through job boards.

They happened through relationships.

The engineer who already knows someone in the team they want to join. The manager who has seen their work and is willing to take a chance on the pivot because they trust the person. The community where they have been showing up consistently and have built a visible track record of learning and building.

If you are making a pivot, your network is not just useful — it is probably your most reliable path to the first role in the new direction.

This means a few things practically.

Start talking about the pivot publicly before you are ready. Post about what you are building. Write about what you are learning. Share the projects. Ask questions in communities where experienced practitioners hang out. Be visible about the direction you are moving in.

The engineers who get opportunities in new directions are almost always the ones who have been talking about those directions for months before an opportunity appears. Opportunities find people who have made their intentions visible.

It also means having direct conversations with people who are already doing what you want to do. Not asking for a job. Asking how they got there. What they would focus on learning. What they wish they had known. Most people who have made a pivot themselves are genuinely happy to talk about it — because they remember what it felt like to not know which way to go.

Everything above applies — but there is one additional thing worth saying for engineers moving between industries rather than between technical disciplines.

Domain knowledge matters more than most engineers think.

An engineer moving from general software development into healthtech, fintech, logistics, or any other domain-specific industry brings technical skills. But the engineers who move fastest in those industries are the ones who take the domain seriously — who learn the business context, the regulatory environment, the specific problems the industry is trying to solve.

This is not a distraction from technical work. It is what makes technical work valuable in a specific context.

Spend real time understanding the domain you are moving into. Read industry publications. Talk to people who have worked in it for years. Understand what the business actually cares about — not at a surface level, but deeply enough to have a real conversation about it.

That understanding, combined with strong technical skills, is a combination that is rare and genuinely valuable in any industry.

Let me be honest about time because I think most career pivot advice is too optimistic here.

A meaningful pivot within tech — one that gets you into a genuinely senior role in the new direction with real responsibility — typically takes between twelve and twenty-four months of deliberate effort.

Not twelve months of casually watching videos. Twelve months of building real things, showing up in communities, having conversations, applying for roles, getting feedback, adjusting, and building more things.

The engineers I have watched make the cleanest pivots treated it like a second job for a defined period. Not forever. But seriously enough, for long enough, that the bridge they built could actually hold weight.

If you are in a hurry, you will likely underinvest in the building phase and struggle to compete with people who have more direct experience. If you are patient and deliberate, you will reach a point where your combination of old experience and new skills makes you a genuinely unusual and valuable candidate.

That point is worth waiting for.

✅ If you are considering a pivot, write down your current skills inventory today. Be generous. Include everything — technical, domain knowledge, soft skills, problem-solving patterns. All of it.

✅ Identify your three most specific, concrete gaps in the direction you want to move. Not broad categories. Specific skills you do not yet have operational experience with.

✅ Pick one project this week that forces you to use one of those skills on a real problem. Not a tutorial. A real project with real decisions.

✅ Tell someone about the direction you are moving in. A colleague, a community, LinkedIn. Make the intention visible. The accountability and the visibility both help.

The engineer I told you about at the beginning of this article — the one who was scared of starting over — sent me a message recently.

He is now leading the platform engineering function at a Series B startup. They specifically recruited him because his backend background meant he built infrastructure with developer experience in mind in a way that pure infrastructure engineers on the team struggled to do.

He did not start over. He redirected four years of experience toward a new problem and built the specific skills he needed to make that experience land in a new context.

That is what a pivot actually is when it is done well.

Not a reset. Not an admission that the previous years were wasted.

A reorientation — pointing everything you have built in a direction that excites you again.

The skills you have are real. The experience is real. The judgment you have developed is real.

You are not starting from zero. You are starting from somewhere. And somewhere, pointed in the right direction, is a very good place to begin.

You do not need to start over. You need to redirect. There is a difference. And that difference is everything.

PS:
At CloudOps Academy, we help engineers make this exact transition — from uncertainty to clarity — through hands-on training, real systems, and structured mentorship.

If you’re ready to move beyond theory and start building real DevOps skills, reach out:
📞 +237 653 583 000