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 👇

A while back I was on a call with an engineer who had just been promoted to a senior software engineer role.

New title. Significant pay increase. A seat at the table in architecture decisions that affected the entire engineering organisation.

By every external measure, she had arrived.

Three weeks into the new role she sent me a message.

"Blaise, I feel like a fraud. Everyone in these meetings seems so certain. They throw around ideas with such confidence. And I am sitting there second-guessing every thought before I say it out loud. I keep waiting for someone to figure out that I do not actually belong in this room."

I read that message and felt something close to recognition.

Not because I had heard it before — though I had, many times.

But because I had felt exactly that feeling myself. In rooms I had worked hard to get into. At moments that should have felt like proof that I belonged.

Imposter syndrome does not care how good you are. It does not care how long you have been doing this or what your title says or how many problems you have solved. It shows up anyway. And the cruel irony — the thing that nobody warns you about — is that it tends to get worse the more senior you become.

Today I want to talk about that honestly. Not with platitudes. Not with a list of affirmations. With the real conversation that I think more engineers need to have.

Imposter syndrome is the persistent internal experience of believing that you are not as competent as others perceive you to be. That your success is the result of luck, timing, or other people's mistakes rather than your own ability. And that at some point, someone is going to figure this out and the whole thing will unravel.

It was first identified in 1978 by psychologists Pauline Clance and Suzanne Imes, who noticed it particularly in high-achieving women. Since then, research has found it across genders, industries, and seniority levels — and in tech specifically, it is extraordinarily common.

One study found that around 70% of people experience imposter syndrome at some point in their careers.

Seventy percent.

Which means the person in the meeting who looks the most confident — the one throwing ideas around without hesitation, the one you are comparing yourself to — there is a reasonable chance they go home some nights wondering if they actually know what they are doing.

You are not alone in this feeling. You are in the majority.

You would expect that with more experience, more success, more evidence of competence, the feeling would fade. It often does not. For many engineers it intensifies.

Here is why.

When you are junior, the gap between what you know and what you are expected to know is obvious and accepted. Nobody expects a junior engineer to have all the answers. You are allowed to not know things. The bar is calibrated to your level.

As you move up, the expectations change — but something else changes too. The problems get harder. The ambiguity increases. You are making decisions with less certainty and more consequence. And crucially, you are now in rooms with people who are genuinely excellent — which makes your own gaps feel more visible even as they are actually getting smaller.

There is also a comparison problem that seniority makes worse. When you are junior, you compare yourself to people slightly ahead of you. When you are senior, you compare yourself to the best people in the industry — because now you are reading their blog posts, watching their conference talks, sitting in their architecture reviews. You are measuring yourself against a highlight reel of the most visible, most articulate, most confident-seeming people in your field.

And nobody's highlight reel includes the moments of doubt.

Imposter syndrome is not one feeling. It is a collection of thought patterns that feed each other. Understanding them specifically is the first step to interrupting them.

When something goes well, imposter syndrome tells you it was luck. The timing was right. The team was strong. You happened to be in the right place.

When something goes wrong, imposter syndrome tells you it was you. Your fault. Your limitation. Proof of what you secretly feared.

This asymmetry is not rational but it is extremely common. And it means that success never fully updates your belief about your own competence while failure confirms every doubt you already had.

The corrective is simple but requires practice: apply the same standard to both. If you are willing to attribute failure to your own limitations, you have to be equally willing to attribute success to your own capability. Not all of it. But some of it. Probably more than you instinctively give yourself.

Nobody compares themselves to one person.

In your head, you are measuring yourself against a composite — a person with the communication skills of engineer A, the system design depth of engineer B, the calm under pressure of engineer C, the breadth of knowledge of engineer D.

That composite person does not exist. You are comparing your complete, unfiltered self — including your gaps, your doubts, your bad days — to an imaginary ideal assembled from the best qualities of everyone around you.

Of course you feel inadequate. You have constructed a standard that nobody actually meets.

The more you learn about a topic, the more aware you become of everything you do not know.

A junior engineer often feels confident because they do not yet know how much there is to know. A senior engineer who has been working seriously in distributed systems for eight years has a detailed, visceral understanding of how complex the field is — and how much still lies beyond their direct experience.

This can feel like a sign that you are not expert enough. It is actually a sign that you are expert enough to understand the real shape of the problem.

The people who know the least about a topic are often the most confident about it. This is well documented — it is sometimes called the Dunning-Kruger effect. The discomfort you feel about the limits of your knowledge is a feature of genuine expertise, not a sign of its absence.

Imposter syndrome creates a specific kind of performance anxiety that feeds itself.

You are in a meeting. You have a thought. Before you say it, you run it through a filter: is this smart enough? Is this obvious to everyone? Will saying this reveal that I do not really understand?

The filter takes long enough that the moment passes. Someone else says something similar. People respond well to it.

Now you feel worse. You had the thought and did not say it. That engineer said it and got credit for it. Your internal narrative: they are smarter, more confident, more deserving of being in this room.

But the reality is simpler. They just said the thing. You filtered it out.

The loop continues.

Here is the part I want to spend the most time on, because the advice that usually gets given — "just believe in yourself" — is not useful. It is the answer to a different question.

The engineers I know who manage imposter syndrome well are not the ones who eliminated the feeling. Most of them have not. They are the ones who developed a relationship with the feeling that stops it from running the show.

Imposter syndrome is a feeling. It presents itself as a fact — "I do not belong here" — but it is not one.

The practical discipline is learning to treat it as a signal to investigate rather than a conclusion to accept.

When the feeling shows up, ask: what is the actual evidence on both sides?

Evidence that you do not belong: I did not know the answer to that question in the meeting today.

Evidence that you do: I have solved twelve problems harder than this one in the past year. I was specifically asked to be in this room. The last three projects I led shipped successfully. The engineer who asked that question has been working in this specific area for three years longer than I have.

The feeling says you do not belong. The evidence says something more complicated and more generous.

Get in the habit of asking for the evidence. Not to dismiss the feeling — but to put it in accurate proportion.

This is one of the most practical things I have seen work consistently.

Keep a document — private, just for you — where you record things you have done that were genuinely hard. Problems you solved. Incidents you handled. Decisions you made that turned out well. Feedback you received that was specific and positive.

Not to show anyone. Not as a brag document. As an evidence base that you can return to when the feeling is loudest.

Imposter syndrome has terrible memory. It forgets your wins and remembers your doubts. Your job is to give it a more accurate record.

The performance anxiety loop I described earlier has one exit: saying the thing anyway.

Not waiting until you are certain it is brilliant. Not filtering until only the perfect thought survives. Just saying the thing, with appropriate humility, and seeing what happens.

Most of the time what happens is: the thought was useful, the room engages with it, and nothing catastrophic occurs.

The engineers I know who have worked through imposter syndrome most effectively made a specific decision at some point to stop letting the filter have the final word. They still feel the hesitation. They say the thing anyway. And every time they do, the filter loses a little power.

The reason imposter syndrome feels so isolating is that nobody talks about it.

Everyone around you looks confident. You assume that confidence is real and that your doubt is a personal failing. The gap between what you feel and what you imagine others feel seems like evidence that something is wrong with you specifically.

When engineers start talking about this honestly — and I have been in rooms where this happened, and it is a remarkable thing to watch — the relief is almost physical. Person after person saying some version of "I thought it was just me."

It is never just you.

Find the people you trust — a mentor, a peer group, a community — and have the honest conversation. Not to wallow in it. To put it in accurate proportion by seeing that the people you admire most are navigating the same thing.

The comparison to a composite is a losing game. Nobody wins it.

The reframe that works is moving from "am I as good as the people in this room" to "what can I contribute to what this room is trying to accomplish."

Those are different questions. The first puts you in competition with an imaginary standard. The second puts you in service of a real goal.

And when you focus on contribution — on what you can add, what problem you can help solve, what perspective you have that might be useful — you almost always find something genuine. Because you would not be in the room if you had nothing to offer.

This is perhaps the most important mindset shift I have seen in engineers who handle this well.

The feeling of not being certain — of not knowing for sure what the right answer is, of making a call with incomplete information — that feeling never goes away in a senior technical role. The problems at that level are genuinely hard. There often is no certain answer.

The engineers who are most effective at senior levels are not the ones who feel certain. They are the ones who have made peace with uncertainty. Who can say "I am not sure, but here is my best thinking and here is how we can validate it" without that uncertainty feeling like a confession of inadequacy.

Uncertainty is not a sign that you are not good enough for the role. It is a sign that the role is hard enough to be worth doing.

I told her the truth.

The feeling she was describing was not a sign that she did not belong. It was a sign that she was paying attention. That she was taking the responsibility seriously. That she cared about getting it right.

The people who never feel that way in senior roles are not the most competent ones. They are often the ones who are not aware enough of what they do not know.

I told her to say the next thing that came to her in a meeting before the filter could catch it.

She did.

It was a good point. People engaged with it. The conversation moved forward.

She sent me a message that evening.

"I said the thing. Nobody threw me out of the room."

That is usually how it goes.

✅ Start the evidence document. Right now, before you close this. Write down five things you have done in the past year that were genuinely hard. Problems you solved. Situations you handled. Things that required real skill and judgment. Keep adding to it.

✅ Think about the last thought you filtered out in a meeting. This week, say the next one before the filter catches it. Just say it. See what happens.

✅ Find one person you trust and have the honest conversation. Tell them you sometimes feel like you do not belong. Watch what they say back.

✅ The next time the feeling shows up, ask for the evidence. What does the feeling say? What does the actual record say? Put them side by side and be honest about which one is more accurate.

Imposter syndrome is not a sign that you are a fraud.

It is a sign that you are self-aware enough to know that you do not know everything. That you care enough about the work to worry about whether you are doing it well. That you are in a role with real stakes and you understand what those stakes mean.

Those are not the qualities of someone who does not belong.

Those are the qualities of someone who takes their craft seriously.

The engineers who never doubt themselves are not the ones doing the most important work. The ones doing the most important work carry the weight of that responsibility — and sometimes that weight feels like doubt.

You are allowed to feel uncertain and still be excellent.

You are allowed to not have all the answers and still deserve your seat at the table.

You earned the room. Now stay in it.

The feeling is not the truth. The work is. And the work says you belong.

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]