Blaise Acha —DevOps & career mentoring

Blaise Acha —DevOps & career mentoring Senior DevOps Engineer at Gozem. Clarity calls, career roadmaps, technical presence reviews, and mentorship — book at consult.akumblaiseacha.com

One conversation changed the way I think about mentorship.Early in my career, I believed mentorship was about giving peo...
25/07/2026

One conversation changed the way I think about mentorship.

Early in my career, I believed mentorship was about giving people answers.

Recommend the right course.
Suggest the right certification.
Point them toward the right technology.

Over time, I realized something.

The best mentors don't create followers.

They create independent thinkers.

A mentor's job isn't to have all the answers.

It's to help someone ask better questions.
To challenge assumptions.
To share lessons learned from experience.

And sometimes, to simply give someone the confidence to keep going when progress feels slow.

That's how I approach every mentoring conversation today.

I don't want someone to leave with a checklist they can complete in a week.

I want them to leave with a way of thinking that will serve them for years.

Because technology will change.
Frameworks will come and go.

But curiosity, discipline, and sound engineering judgment have a much longer shelf life.

I've also learned that mentorship isn't limited to formal sessions.

Sometimes it's a code review.
A thoughtful LinkedIn post.
A conversation after a conference talk.
Or a message from someone asking for career advice.

Every interaction is an opportunity to help someone move forward.

And if you've been in this industry for a few years, chances are you already know something that could save someone else months of frustration.

Don't underestimate the impact of sharing what you've learned.
Knowledge grows when it's passed on.

That's one of the reasons I enjoy writing and mentoring.

If something I've learned through experience can help another engineer avoid a mistake or build confidence in their journey, then it's worth sharing.

Who's one person that had a meaningful impact on your career, and what lesson did they leave with you?

The engineers people trust aren't the ones who never make mistakes, they're the ones who take ownership.Every engineer w...
19/07/2026

The engineers people trust aren't the ones who never make mistakes, they're the ones who take ownership.

Every engineer will eventually make a mistake.

A deployment will fail.
A configuration will be wrong.
An assumption won't hold in production.
That's part of building software.

What separates exceptional engineers isn't perfection.

It's ownership.

Ownership means resisting the urge to point fingers when something goes wrong.

Instead, you focus on understanding the issue, communicating clearly, and helping the team recover.

I've always admired engineers who say:

"Here's what happened."
"Here's what I learned."
"Here's how we'll prevent it next time."

Those conversations build trust.
Blame rarely improves a system.
Learning does.

Ownership also means thinking beyond your assigned tasks.
If you notice a fragile process, improve it.
If documentation is missing, write it.
If repetitive work can be automated, automate it.

Don't wait for someone to ask.

That's how engineers become leaders, long before they're given a leadership title.

The people who make the greatest impact aren't always those with the deepest technical expertise.

They're the ones their teammates can depend on.

Reliability isn't just a quality we build into systems.
It's a quality we build into ourselves.

And over time, people remember reliable engineers.
Not because they were perfect.

But because they consistently showed up, accepted responsibility, and made the entire team stronger.
Titles come and go.
Trust is earned one decision at a time.

In your opinion, what's the clearest sign that an engineer has developed true ownership?

The biggest misconception about becoming a Senior Engineer is that it's all about technical knowledge.When many engineer...
14/07/2026

The biggest misconception about becoming a Senior Engineer is that it's all about technical knowledge.

When many engineers think about becoming "senior," they immediately think about learning more technologies.

Another cloud certification.
Another programming language.
Another Kubernetes course.

Those things are valuable.

But they're rarely what earns you the trust that comes with seniority.

The biggest difference I've observed between junior and senior engineers isn't the number of tools they know.

It's how they think.

Senior engineers don't just solve problems.

They identify the right problems to solve.
They don't optimize systems in isolation.

They understand the impact of every technical decision on customers, teammates, and the business.

When an incident happens, they don't panic.

They gather facts.
They communicate clearly.

They make informed decisions under pressure.
They also understand that engineering is a team sport.

Being technically brilliant means very little if you can't explain your ideas, mentor others, or collaborate across teams.

Some of the most respected engineers I've worked with weren't necessarily the ones who wrote the most code.

They were the people others trusted.
The ones who simplified complexity.
The ones who helped teammates grow.

The ones who left systems—and people—better than they found them.
If your goal is to become a senior engineer, don't focus only on expanding your technical toolkit.

Develop your judgment.
Strengthen your communication.
Learn to make trade-offs.

Understand the business behind the technology.
And never stop being curious.

Technical skills might help you get promoted.

But trust, leadership, and sound decision-making are what make people see you as a senior engineer long before your job title changes.

In the end, seniority isn't something you declare.

It's something your team begins to recognize.

What's one quality you believe every Senior Engineer should have, regardless of their technology stack? I'd love to hear your thoughts.

I've learned more from the days things didn't go as planned than from the days everything worked perfectly.As engineers,...
14/07/2026

I've learned more from the days things didn't go as planned than from the days everything worked perfectly.

As engineers, we celebrate successful deployments, stable systems, and completed projects.

But if I'm honest, the biggest lessons in my career didn't come from success.
They came from failure.

From deployments that didn't go as expected.
From assumptions that turned out to be wrong.

From systems that behaved differently in production than they did in testing.
From decisions I would make differently today.

Every one of those moments taught me something valuable.
Failure taught me to investigate before making assumptions.

It taught me to document what I learned so the same mistake wouldn't happen twice.

It taught me that preparation is far more valuable than panic.

Most importantly, it taught me that engineering isn't about avoiding mistakes altogether.

It's about building systems—and habits—that allow you to recover quickly, learn continuously, and improve over time.

One mindset has stayed with me throughout my career:

Every incident is tuition.

You can either pay the price and learn the lesson, or pay the price and repeat it.
The choice is yours.

That's why I encourage young engineers not to fear mistakes.
Fear making the same mistake because you refused to reflect on it.

The best engineering teams I've worked with don't ask:

"Who caused the problem?"

They ask:

"What can we improve so this doesn't happen again?"

That shift from blame to learning creates stronger systems and stronger engineers.

Whether you're just starting your career or leading engineering teams, remember this:

Success builds confidence.

Failure, when approached with humility, builds wisdom.
And in engineering, wisdom is often what makes the difference when the pressure is highest.

What's one failure that ultimately made you a better engineer or professional? I'd love to hear what it taught you.

The best backend developers I know don't just write code, they understand where that code runs.I've worked with brillian...
11/07/2026

The best backend developers I know don't just write code, they understand where that code runs.

I've worked with brilliant backend engineers who could build elegant APIs, optimize database queries, and design clean software architectures.

But many of them had little understanding of the infrastructure powering their applications.

That knowledge gap becomes expensive as systems grow.

When you understand the cloud, you start making different engineering decisions.

You think about latency before users complain.

You design APIs with scalability in mind.

You understand why applications fail under load.

You appreciate the importance of monitoring, backups, security, and disaster recovery.

Most importantly, you begin to see software as more than just code.

You see it as a complete system.

This doesn't mean every backend developer needs to become a DevOps engineer.

It means every backend developer should understand the fundamentals of the environment their applications depend on.

Questions like:

• Where does my application run?
• How is it deployed?
• What happens if the server crashes?
• How is traffic distributed?
• How are secrets managed?
• How do we know when something is broken?

These aren't just DevOps questions.

They're engineering questions.

The best engineering teams I've worked with didn't operate in silos.

Developers understood infrastructure.

Platform engineers understood application requirements.

Everyone shared responsibility for building reliable systems.

That collaboration led to faster deployments, fewer production issues, and better products for users.

If you're a backend developer looking to grow into a senior role, don't stop at writing great code.

Learn the fundamentals of cloud infrastructure.

Understand deployment pipelines.

Explore observability.

Get comfortable reading logs, metrics, and dashboards.

Because the more you understand the entire system, the more valuable you become, not just as a developer, but as an engineer.

Technology keeps evolving.

Systems thinking never goes out of style.

If you're a backend developer, what's one cloud concept you wish you'd learned earlier in your career?

There's a huge difference between learning DevOps and actually doing DevOps.You can spend months watching tutorials, ear...
09/07/2026

There's a huge difference between learning DevOps and actually doing DevOps.

You can spend months watching tutorials, earning certifications, and building personal projects.
And you should.

That's how every engineer starts.
But eventually, you have to leave the safety of the lab.

Because production teaches lessons that no course ever can.
In a course, deployments usually work.

In production, deployments sometimes fail five minutes before your biggest customer logs in.

In a course, monitoring is just another chapter.

In production, it's often the only thing helping you understand why users are complaining.

In a course, cloud costs are rarely discussed.

In production, every architectural decision has a financial impact.

And when you're responsible for systems that thousands or even millions of people depend on, you begin to see DevOps differently.

You stop asking:

"Which tool should I learn next?"

And start asking:

"How can I build systems that are reliable, secure, scalable, and easy for my team to operate?"

That's the mindset shift that transforms an engineer.

The best DevOps engineers aren't the ones who memorize the most commands.

They're the ones who think in systems.
They understand trade-offs.
They communicate clearly during incidents.

They automate repetitive work.

And they never stop improving the platform for everyone around them.
If you're early in your career, keep learning the tools.

But don't let your journey stop there.

Build projects.

Break things.

Fix them.

Read postmortems.

Understand why systems fail.

Learn how businesses use technology—not just how technology works.
Because companies don't hire DevOps engineers to manage servers.

They hire them to help teams deliver software faster, more reliably, and with greater confidence.

That's the difference between learning DevOps and doing DevOps.

If that's the kind of engineer you're striving to become, you're already asking the right questions.

What's one lesson you've learned from building or operating real systems that no certification ever taught you?

hashtag hashtag hashtag hashtag hashtag

The first thing I look for when mentoring a junior engineer isn't technical skill.It's curiosity.Over the years, I've re...
08/07/2026

The first thing I look for when mentoring a junior engineer isn't technical skill.
It's curiosity.

Over the years, I've realized something interesting.

The engineers who grow the fastest aren't always the smartest in the room.
They're the ones who ask better questions.

When I mentor someone, I'm not looking for a walking encyclopedia of AWS services or Kubernetes commands.

I'm looking for someone who's genuinely curious about how things work.

Someone who asks:

"Why did we choose this architecture?"
"What problem is this tool solving?"
"What happens if this service fails?"

"How would this scale if we had ten times the traffic?"

Those questions tell me far more than someone who can recite a list of commands from memory.

The second thing I look for is ownership.

When something breaks, do you immediately blame the code, the infrastructure, or someone else?

Or do you take responsibility for understanding the problem?
Great engineers don't rush to conclusions.

They investigate.
They test assumptions.
They learn from every incident.

Finally, I look for humility.

Technology changes too quickly for anyone to know everything.

The engineers who continue to grow are those who are comfortable saying:

"I don't know yet, but I'm willing to figure it out."

That's not weakness.
That's professionalism.
Every engineer starts somewhere.

What matters isn't where you begin.

It's whether you're willing to keep learning long after the tutorials end.

When I mentor engineers, my goal isn't simply to help them get a job.

It's to help them develop the mindset that allows them to thrive throughout their careers.

Because tools will change.
Industries will evolve.

But curiosity, ownership, humility, and sound engineering judgment will always be valuable.

If you could strengthen just one skill this year, would it be your technical ability or your way of thinking? I'd love to hear your answer.

If you're looking for practical mentorship built around real production experience, you can learn more at consult.akumblaiseacha.com.

Learning Docker won't get you hired. Learning how to solve problems will.Every week, I receive messages from aspiring De...
06/07/2026

Learning Docker won't get you hired. Learning how to solve problems will.

Every week, I receive messages from aspiring DevOps engineers asking the same question:

"I've finished a Docker course. What should I learn next?"

My answer usually surprises them.

I tell them to stop thinking in terms of "what tool should I learn next?" and start asking "what problem does this tool solve?"

Docker is an incredible technology.

It solved one of software engineering's biggest challenges: consistency. Instead of hearing, "It works on my machine," developers can package applications so they behave the same across different environments.

But here's the truth.

No company hires someone simply because they know Docker.

They hire engineers who understand why containers exist, when to use them, and how they fit into a larger platform.

Can you troubleshoot why a container keeps restarting?

Do you understand networking between containers?
Can you investigate high memory usage?

Do you know when a virtual machine might be a better choice than a container?
Can you explain the trade-offs?

That's what separates someone who has completed a course from someone who's ready for production.

The same principle applies to Kubernetes, Terraform, AWS, and every other tool in our industry.

Tools are temporary.
Fundamentals are permanent.

If you're building your DevOps roadmap, spend as much time learning Linux, networking, operating systems, scripting, and troubleshooting as you do learning new technologies.

Because in production, nobody asks,
"Who here has a Docker certificate?"

They ask,
"Who understands what's happening and can fix it?"

Build that engineer.

The opportunities will follow.

If you're looking for a practical roadmap that goes beyond tutorials and focuses on real production thinking, I'd be happy to help through my mentorship and consulting work.

consult.akumblaiseacha.com

The day I stopped trying to be the smartest engineer in the room was the day I started becoming a better one.Early in my...
06/07/2026

The day I stopped trying to be the smartest engineer in the room was the day I started becoming a better one.
Early in my career, I thought being a great engineer meant having all the answers.

Then I started working with production systems.
Production has a way of humbling you.

It doesn't care how many AWS certifications you have, how many Kubernetes clusters you've deployed, or how many technologies you can list on your CV.

When something breaks in production, only one question matters:

How quickly can you understand the problem and restore service?
That realization changed how I approached engineering.

I stopped chasing every new tool and started investing more time in fundamentals—Linux, networking, observability, system design, and understanding how distributed systems behave under pressure.

I also learned something equally important.
During incidents, the engineer who remains calm often contributes more than the engineer who reacts the fastest.

Panic leads to assumptions.
Assumptions lead to mistakes.
Good engineers troubleshoot.
Great engineers investigate.

Over the years, I've come to appreciate that DevOps isn't about showing how much you know.

It's about reducing uncertainty.
It's about helping teams deploy confidently.

It's about building systems that are resilient, observable, and easy to recover when things inevitably go wrong.
Because they will.

No production environment is perfect.
The goal isn't perfection.
The goal is preparedness.

That's one of the biggest lessons I try to pass on to every engineer I mentor.
Learn the tools, yes.

But invest even more in learning how to think.
Technology will continue to evolve.
Sound engineering judgment will always be valuable.

What's one lesson production has taught you that no course ever could?
I'd genuinely love to hear your experience.

If you're looking for practical guidance built on real production experience, not just theory, you can learn more about my consulting and mentorship services at consult.akumblaiseacha.com.

The biggest mistakes junior DevOps engineers make aren't technical. They're mental.I've mentored engineers who knew Dock...
05/07/2026

The biggest mistakes junior DevOps engineers make aren't technical. They're mental.

I've mentored engineers who knew Docker, Kubernetes, Terraform, and AWS, yet still struggled to make an impact in their first DevOps role.
It wasn't because they lacked skills.

It was because they approached the job the wrong way.
Here are five mistakes I see repeatedly.

1. Chasing every new tool.

The DevOps ecosystem changes constantly. If you're always learning the newest tool without understanding the problem it solves, you'll always feel behind. Master the fundamentals, Linux, networking, Git, scripting, and cloud concepts. Tools come and go; principles endure.

2. Optimizing before understanding.

Don't rush to redesign a deployment pipeline or rewrite infrastructure. Spend time learning why things were built that way. Context is one of the most valuable assets you'll have as an engineer.

3. Ignoring the business.

Your job isn't to maintain Kubernetes clusters. Your job is to help the business deliver software reliably, securely, and efficiently. Every technical decision should support a business outcome.

4. Being afraid to ask questions.

The best engineers I know ask thoughtful questions. Curiosity isn't a weakness it's how you avoid expensive mistakes and grow faster.

5. Thinking DevOps is only about automation.

Automation is important, but DevOps is ultimately about collaboration, reliability, and creating systems that help teams move faster with confidence.

One lesson production has taught me is this:

Companies don't remember the engineer who knew the most tools.

They remember the engineer who stayed calm during an incident, solved the right problem, and earned the trust of the team.
Build that engineer.
The tools will follow.

If you're navigating your DevOps journey and want practical guidance rooted in real production experience, not just theory I'd be glad to help. You can learn more about my mentorship and consulting work at
consult.akumblaiseacha.com.

Adresse

Molyko
Buea
00237

Site Web

Notifications

Soyez le premier à savoir et laissez-nous vous envoyer un courriel lorsque Blaise Acha —DevOps & career mentoring publie des nouvelles et des promotions. Votre adresse e-mail ne sera pas utilisée à d'autres fins, et vous pouvez vous désabonner à tout moment.

Raccourcis

Partager

Type