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 want to start with a confession.

For most of my career, the phrase "personal brand" made me uncomfortable. It sounded like something an influencer would say while filming themselves drinking coffee. It felt like the opposite of what good engineering is about — substance over noise, work over performance, results over self-promotion.

So for years I did what most engineers do. I kept my head down, I did the work, and I assumed that was enough.

It was not enough. Not in the way I thought it would be.

I have watched engineers far less talented than people I know personally end up with conference invitations, job offers from companies they did not apply to, freelance work falling into their inbox, and a network of senior engineers who genuinely respected them. Not because they were louder. Because they had been quietly sharing their work for years, while the rest of us were quietly hoping someone would notice.

This newsletter is about the version of personal brand that actually makes sense for engineers. Not the influencer version. The honest one.

Here is the uncomfortable part.

You already have a personal brand. Every engineer does. It is just the collection of things people associate with your name when you are not in the room. Your reputation for shipping. Your reputation for being kind to juniors. Your reputation for over-engineering things. Your reputation for finishing what you start, or not.

You did not choose to have one. You have one anyway.

The only real question is whether the brand you have was built deliberately or by accident. Most engineers leave it to accident — and then wonder why opportunities seem to find other people first.

The engineers who do this well are not performing. They are just being deliberate about something everyone else is leaving to chance.

Most engineers I talk to about this resist it for the same reason. It feels like showing off. It feels like the loud people winning over the people doing the real work.

I had to sit with this for a long time before I understood where it was coming from. Here is what I eventually figured out.

There is a difference between performing and sharing.

Performing is when you write a post that exaggerates what you did so it sounds more impressive than it was. Performing is when you take credit for a team's work and put your face on it. Performing is when you talk about systems you barely touched as if you architected them.

People can smell performing from a long way off. It rarely ages well.

Sharing is different. Sharing is when you write about the bug that took you three days to find and explain how you found it. Sharing is when you publish a short post about a migration you ran, with the honest version including the mistakes. Sharing is when you give a talk about a system you actually built and explain the trade-offs you actually made.

Sharing is just doing the work, and then writing one more paragraph about what you learned. That is it. That is the entire trick.

If you can hold onto that distinction, the discomfort starts to fade. You are not asking people to look at you. You are leaving useful breadcrumbs for the next engineer who runs into the same problem. The fact that your name happens to be attached to those breadcrumbs is a by-product, not the point.

There are roughly four ways engineers build a deliberate body of work over time. You do not need to do all of them. Pick one, do it consistently for a year, and you will be ahead of 95% of engineers in your position.

This is the highest leverage thing on the list. Writing is cheap, asynchronous, and compounds.

Most engineers do not write because they think they need to have something profound to say. They do not. The best engineering writing on the internet is mostly people explaining how they solved a specific problem, what they tried that did not work, and what they would do differently next time.

You debugged a strange MongoDB timeout last week. Write 600 words about it. You figured out how to make GitLab runners stop hanging. Write a post about it. You finally understood how vLLM differs from Ollama for agentic workloads. Write a post.

The trick is to write for the person you were three months ago. That person is real. There are thousands of them on the internet right now searching for exactly the thing you just solved.

You do not need a fancy blog. A simple Hashnode, Medium, or Substack works. Even consistent LinkedIn posts work — though I would push you to own your domain eventually because platforms come and go.

Here is what nobody tells you. The first twenty posts you write will get almost no traffic. You will feel like you are writing into a void. Then somewhere around post number thirty, something shifts. Search engines start picking you up. People share an old post you forgot about. Someone you have never met emails you about something you wrote last year.

That is the compounding effect. It is real, but it is slow. It does not work for the people who write for three months and quit because nobody is reading.

Speaking sounds terrifying until you realise the bar is just sharing what you know with people who do not yet know it.

Start with the smallest room. A lunch and learn at your company. A walkthrough of a system you built for the new engineers. A short talk in your team's weekly meeting about that incident you handled last week.

When you are comfortable there, move up one level. A local meetup. A virtual community. A guest spot on someone's podcast or stream.

The reason this works for your brand is not because conferences will book you immediately. It is because every time you speak, you force yourself to organise your thinking, you become known to a small group of people who did not know you before, and a recording of your talk lives on the internet for anyone who searches your name later.

A short, well-prepared internal talk that gets recorded and shared in the company wiki is worth more than three meetup appearances where you read off slides nobody can see clearly.

Building in public is the most underused tool on this list, especially for backend and platform engineers.

It means showing your work as you go, not just the polished final output. The half-finished diagram. The first version of the design doc with all the unanswered questions. The actual incident timeline with the embarrassing four hours you spent looking in the wrong place.

You can do this inside your company — putting design docs in shared drives instead of personal folders, posting your in-progress thinking in team channels, narrating your work in pull request descriptions instead of just saying "fixed it." This is how senior engineers become known internally without ever appearing to self-promote. The work just shows up where people can see it.

You can also do it externally if you have a side project. A small open source tool. An internal catalog you built that you can describe at a high level without leaking proprietary detail. A weekend experiment.

Building in public is uncomfortable because it removes the safety net of only showing the finished product. But that is exactly why it builds trust. People can see that you actually think the way you say you think.

This is the one that gets ignored most often, and it is probably the one that has built the most quiet careers.

Answer questions on Stack Overflow. Reply thoughtfully to people asking for help on Reddit, Discord, or Slack communities. Review a junior engineer's design document and post your feedback in a public channel where others can learn from it. Send someone a useful link with a real explanation instead of just the URL.

Do this for two years and you will have built a reputation as someone who is generous, knowledgeable, and worth being around. Nothing on a CV will ever do for you what that reputation does.

There is no shortcut here. The engineers whose names you know — the ones with the newsletters, the talks, the open source projects, the offers — were almost all writing or building or speaking to nobody for a long time before anything happened.

I will not tell you it takes six months. It does not. It usually takes years.

But years pass anyway. The question is whether at the end of the next two years you have a body of work that represents how you think and what you have learned, or whether you have a slightly fuller GitHub contribution graph and nothing else to show.

One post a month. One talk a quarter. One real piece of writing per significant project you finish. That is a pace anyone can sustain alongside a demanding job. Do it for two years and look back.

Let me be specific about what I am not saying.

I am not saying you need to be on every platform. You do not. Pick one or two and go deep.

I am not saying you should optimise for engagement metrics. Most viral engineering content is mediocre. The stuff that actually builds careers is the slow, useful, honest writing that does not trend but gets quietly bookmarked by people who matter.

I am not saying you should turn your work into content. The work comes first. The sharing is downstream of the work. If you reverse this — looking for content opportunities instead of solving real problems — people will sense it and your credibility will erode quietly.

And I am definitely not saying you have to enjoy any of this. Many engineers I respect find writing uncomfortable. They do it anyway because they understand it is part of the job at a certain level. You can treat it the same way you treat documentation or code review. A professional habit, not a personality trait.

✅ Write a 500-word post this week about something you solved in the last month. Do not aim for profound. Aim for useful. Post it somewhere — your blog, LinkedIn, your company wiki, anywhere with a URL you can point to later.

✅ Identify one small room you could speak in next quarter. A team meeting, a lunch and learn, an internal demo. Put it on the calendar.

✅ Pick one platform — just one — where you will share your work consistently for the next twelve months. Write down the cadence (weekly, fortnightly, monthly). Then actually keep it.

The engineers who end up with the best opportunities are rarely the loudest. They are the ones who built a quiet, consistent, honest record of their work over years. People can find them. People can read their thinking. People know what they are good at without having to ask.

That is not a personal brand in the influencer sense. That is just being a professional adult who treats their own career as seriously as they treat the systems they build.

You will not feel like you are showing off if the thing you are sharing is true, useful, and grounded in real work. You will just feel like you are doing your job.

Do the work. Share the work. Repeat for long enough that it stops feeling strange.

Invisible work is wasted work. Make yours findable.

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]