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 👇

I had a conversation with an engineer last year that I keep coming back to.

He had been at the same company for three years. Smart guy. Technically solid. Never missed a deadline. His code was clean, well tested, well documented. By every technical measure, he was performing well above his mid-level title.

He had applied for a senior promotion twice.

Twice he was passed over.

He came to me frustrated. Almost ready to quit and find a senior title somewhere else — which, honestly, is what a lot of engineers do when they hit this wall.

He asked me:

"Blaise, what am I missing? My code is better than half the seniors on the team. What do they have that I don't?"

I told him the truth.

It was not his code that was holding him back. His code was fine. It was everything that happens around the code — the thinking, the communication, the ownership — that was keeping him at mid-level.

He got the promotion four months later.

Today I want to tell you exactly what changed.

Most engineers believe that getting promoted to senior is about getting better at writing code.

So they study harder. They learn new frameworks. They get another certification. They optimise their pull requests. They work longer hours hoping someone notices.

And they stay stuck.

Because the people who make promotion decisions are not primarily asking "can this person write good code?" They are asking something entirely different:

"Can this person be trusted with more?"

More ambiguity. More responsibility. More impact. More people depending on them.

That is a completely different question. And it requires a completely different answer.

There is a version of mid-level that looks like this:

A ticket comes in. The engineer picks it up. They build what the ticket says. They open a pull request. They move on to the next ticket.

That is not ownership. That is execution.

Ownership looks different.

An engineer with an ownership mindset picks up a ticket and asks: does this actually solve the right problem? They notice that the feature they are building will interact strangely with a system three teams away and they flag it before it becomes an incident. They see that the approach in the ticket will work for 1,000 users but will fall apart at 100,000 and they raise it now — not after the fact.

They do not just close tickets. They think about outcomes.

I have seen this pattern so clearly in production environments. The mid-level engineer deploys the fix and marks the ticket done. The senior engineer deploys the fix, watches the metrics for thirty minutes, writes a note in the incident channel explaining what happened and what was done, and then opens a follow-up ticket to address the root cause so it never happens again.

Same fix. Completely different level of ownership.

What this looks like in practice:

When something breaks on your team — even if it is not your code — ask what you can do to help. Write the post-mortem. Follow up on the action items. Treat the system's health like it is your personal responsibility because at the senior level, it is.

This is the one that surprises engineers the most when I tell them.

Senior engineers are not necessarily better at solving problems. They are better at surfacing them early.

A mid-level engineer hits a blocker on Wednesday. They work around it. They try different approaches. By Friday they are two days behind and they mention it in the standup. Now the manager has to scramble to adjust timelines, reset expectations with stakeholders, and figure out how to recover.

A senior engineer hits the same blocker on Wednesday. By Wednesday afternoon they have already sent a message: "I hit something unexpected with the authentication service integration. It is not blocking me completely but it will add two days to the timeline. I have three possible approaches — here is the tradeoff of each. Which direction do you want me to go?"

The problem is the same. The impact on the team is completely different.

Senior engineers understand that their manager's biggest fear is not problems — it is surprises. A problem with context and options is manageable. A problem discovered at the deadline is a crisis.

What this looks like in practice:

Get comfortable sending the uncomfortable message early. The one that says "this is taking longer than expected." The one that says "I think we are building the wrong thing." The one that says "I see a risk here that nobody is talking about."

That message — sent early, with context and options — is one of the clearest signals of senior-level thinking.

Mid-level engineers think about their service.

Senior engineers think about the ecosystem their service lives in.

This is a genuine shift in how you hold information in your head. It is not just knowing that other services exist. It is actively thinking about how your decisions affect them — and how their behaviour affects you.

In a real production scenario I was involved with, a mid-level engineer made a perfectly reasonable change to an API endpoint. They updated the response format to be cleaner and more consistent. They tested it thoroughly. It worked perfectly in isolation.

What they did not think about was the three other services consuming that endpoint that were parsing the old response format. All three broke in production simultaneously.

A senior engineer would have asked: who else is calling this endpoint? What are they expecting? How do I make this change safely — probably by versioning the API and deprecating the old format gradually rather than changing it in place?

This is systems thinking. It is not about being smarter. It is about training yourself to always ask: what else does this touch?

What this looks like in practice:

Before you make any significant change, ask three questions. Who depends on this? What breaks if I get this wrong? What is the safest path to the outcome I want?

Those three questions will catch 80% of the production incidents that mid-level engineers create — not out of carelessness, but out of limited scope of view.This Week’s Challenge

✅ Identify one person who is two to five years ahead of you on the path you want to walk.

✅ Engage genuinely with something they have shared — a post, an article, a talk.

✅ Send them one specific, respectful question this week.

Not a mentorship request. Just a question.

That is how it starts.

This is the one that is hardest to fake and most visible to the people who make promotion decisions.

Senior engineers raise the floor of the entire team.

They do code reviews that teach — not just reviews that approve or reject. They write documentation that actually helps the next person. They ask the question in the meeting that everyone was thinking but nobody said. They pair with the junior engineer who is stuck instead of waiting for the standup to surface the problem.

They are invested in the team's output, not just their own.

I have watched managers describe senior engineers to me and the word that comes up most consistently is not "brilliant" or "fast" or "technical." It is "reliable." The person you can hand something to and know it will be handled — not just the code part, but all the parts around it.

What this looks like in practice:

Pick one engineer on your team who is more junior than you. Show up for them this week. Review their PR with a comment that teaches something, not just a comment that points out what is wrong. Answer their question in the team channel publicly so everyone benefits. Invite them into a conversation they would not normally be part of.

Do that consistently for three months and watch how the people above you start describing you.

When I worked with him, we did not touch his code at all.

We worked on four things.

He started writing a short note in every PR explaining not just what the change did but why that approach was chosen over the alternatives. Decision context — not just implementation.

He started sending one proactive update per week to his manager. Not a status report. A short message: here is what I am working on, here is a risk I see, here is what I am doing about it.

He started asking "who else does this affect?" before making any change to a shared system.

And he started doing one genuinely useful thing for a junior teammate every week. A review. A pairing session. An honest conversation about their growth.

Four months later he was promoted.

His code did not change. His behaviour around the code changed completely.

✅ Look at the last three pull requests you opened. Did they include context about why you made the decisions you made — or just what you changed? Add that context this week.

✅ Is there something on your current project that is not going as planned? Send a proactive message to your manager today. Not to complain. To surface it early with options.

✅ Before your next significant change, ask: who depends on this? What breaks if I get this wrong? Write the answers down before you start.

✅ Pick one person on your team more junior than you and do one genuinely useful thing for them this week.

The promotion to senior is not a reward for writing better code than everyone else.

It is recognition that you have started thinking differently. That you see more. That you take responsibility for outcomes, not just outputs. That the people around you are better because you are there.

The engineers who get stuck at mid-level are not less talented. They are often more technically gifted than the seniors above them. What they have not yet done is make the shift from "I do my work well" to "I take responsibility for how this all turns out."

That shift — in thinking, in communication, in ownership — is the real promotion criteria. Everything else is just the ticket to get in the room.

Write good code. But think like someone the team cannot afford to lose.

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
📧 [email protected]