Back to Home to display all posts.
Showing posts with label Agile. Show all posts

12/12/2023

Become a DevOps Engineer with the Dynamic DevOps Roadmap - Career

Dynamic DevOps Roadmap

A couple of months ago, I discussed why all linear DevOps learning roadmaps are broken by default (like roadmap.sh/devops)! In that post, I've discussed the issue, where it comes from, and the solution I tried for over 5 years!

The solution is simply switching to an MVP-style learning roadmap where you learn in iterations and touch multiple parts simultaneously (not necessarily equally). Each iteration should focus on a primary topic while exploring related side topics. So after a month, you already know about each topic in the roadmap, and after the 2nd month, you have the basics, and after the 3rd month, you have a good base, and so on.

Based on my mentorship experience in the last 5 years, I've concluded that any "tool-based" approach to deal with DevOps will fail miserably. The Cloud-Native landscape is getting bigger and bigger every day, and there is no way to deal with it that way.

For that reason, I've reviewed all docs from the previous mentorship docs I held in the past (I worked with people starting their first job, career shift, or moving to another work style or company) and built the ultimate missing solution!

⭐ Check out the Dynamic Roadmap content ⭐

This roadmap is polymorphic, which means it's designed to work in different modes. It depends on how fast you want to go.

  1. Self-Learning Course: In this mode, you are not expected to have DevOps experience, and you want to go from zero to hero, transforming your knowledge to land your first job as a DevOps Engineer.
  2. Hands-on Project: In this mode, you have some experience with DevOps (usually between 1-2 years of work experience), but you want to step up your skills with real hands-on industry-grad projects to learn DevOps in a pragmatic manner.
  3. Mentorship Program: In this mode, the previous two modes are covered (that means it could be only for the project or the whole roadmap) but with support from a mentor! The project will provide you with a DevOps expert who will guide you in following up on your progress and personalizing your learning plan.

The whole idea is about the Learning by Doing method (aka Problem-based Learning), which is done in iterative phases where you learn as you go and cover the whole DevOps cycle like Code, Containers, Testing, Continuous Integration, Continuous Delivery, Observability, and Infrastructure.

The project is a work in progress; more details are in the status section.

I hope that the project helps more people start their DevOps engineering careers! The market is thirsty for it already!

⭐ Check out the Dynamic Roadmap content ⭐

Happy DevOps-ing :-)

Continue Reading »

12/11/2023

DevOps is not only a culture - Discussion Panel

Today is my second session JobStack 2023 after my previous one yesterday titled "Platform Engineering: Manage your infrastructure using Kubernetes and Crossplane", but this time it was a discussion panel with Ahmad Aabed (CTO of Zyda).

For a long time, DevOps methodologies have been the driving force behind innovation and efficiency in modern software development. You've likely encountered the popular jargon: "DevOps is not a role; it is a culture"! However, the truth is that DevOps has much more!

This session dives deep into the pillars world of DevOps, going beyond the cultural aspect to explore practices, technology stacks, mindset, and more. This is an open discussion where we will share (and encourage you to do so) the experiences of implementing DevOps. In other words, what practical steps have you taken to embrace the power of DevOps in your organization?

A shot from the recoding

At the end, I'd like to share a couple of posts I wrote before in that regard (DevOps methodologies in action):

Enjoy :-)

Continue Reading »

06/06/2023

Your DevOps learning roadmap is broken! - Career

...
⚠️ Update ⚠️
If you are looking for the solution for this dilemma, then check this out: How to become a DevOps Engineer in 2024 with the Dynamic DevOps Roadmap.
...

Can you read it? Probably not, it's already broken!

As of 2023, the DevOps Engineer role remains one of the top 10 most in-demand jobs across all industries (not just the tech field!) And that was the case for the last 5 years at least and is expected to continue for the foreseeable future.

While DevOps is a hot topic all the time, it's in particular hard to start DevOps engineer as your first job. Many engineers believe that it's not possible at all to begin as a DevOps professional without first working as a developer or in operations (I totally disagree with that!).

Almost every day, I see people struggling on their way to start as fresh/junior DevOps engineers. They usually follow some roadmap (typically roadmap.sh/devops). But still, they cannot land their first job, and sadly, many of them eventually give up!

This blog post explains why most of roadmaps don't work for DevOps roles and won't help you start your first job as a DevOps engineer. Also, the post discusses the best way to start in a DevOps role without prior work experience. While it might not work for everyone, I can say that it has been successful with all the people I have mentored in the last couple of years.


ToC

TL;DR

In 2023 starting a DevOps engineer role is challenging because the DevOps model has various implementations and patterns. It's even more complicated (but still possible) if that's your first job without previous software industry experience. Yet, many learning roadmaps like roadmap.sh/devops still follow a linear path (i.e., learn some topic to the end, then move to another, and so on) which doesn't work well with the DevOps role because a skilled DevOps engineer is a T-Shaped skilled. Adopting a dynamic MVP learning roadmap increases your chances of entering the market and starting your first job as a DevOps engineer without previous software hands-on experience.


DevOps Topologies

First, let's start with the DevOps model itself. Being a high-level methodology that can be implemented in various ways makes it super challenging. Hence, the DevOps engineer role has no unified definition or standard requirements.

I will not delve into the cliché DevOps is not a role, it is a culture (because in reality, it doesn't work like that! DevOps is not just a culture, and it is also a role), but here I want to emphasize that not all DevOps engineers are the same!

Here I want to mention "DevOps Topologies" which covers different team structures that implement DevOps. It shows many bad and good DevOps patterns.

Given that no one-size-fits-all team topology works for every organization, it's wrong to say it's not possible to start your career as a DevOps engineer. But there are situations where it's extremely challenging to do so, such as being the sole DevOps engineer in a team or even in a company.

So, what can you do to increase your chances of landing your first job as a DevOps engineer? You should have T-shaped skills and leave no stone unturned in your learning journey!

T-Shaped Skills

The "T-Shaped skills" helps DevOps engineers to efficivtly handle various challanges.

The T-shaped skills refer to combining broad and deep skills in a specific field. The horizontal bar of the "T" represents a broad range of general knowledge and skills across different disciplines or areas, and the vertical stem of the "T" represents deep expertise in a specific area. It's simply a mix between being a specialist and generalist at the same time!

The T-shaped skills will help you to work in companies with different DevOps patterns. You can easily transition between different areas in the DevOps spectrum. Not only that but also it will help you to handle new challenges effectively. In fact, the best DevOps engineers I have come across possessed T-shaped skills.

Does it mean there's no I-shaped DevOps engineer who specializes in certain areas and no little knowledge in other areas? I would say it's possible, but it may limit the available opportunities and companies you can work with.

Actually, as you progress in your career, it's better to develop more specialization (i.e., more vertical stems), and after a couple of years in the industry, your next step should be Pi-Shaped skills (search also for M-Shaped and Comb-Shaped skills, but it's a topic for another post).

To summarize this section, you should aim to gain exposure to various areas of DevOps practices and technologies without delving too deep into each one, yet, you need to dive in-depth into some of them (according to the market or organizations your target). And due to that, your roadmap shouldn't be linear but follow the MVP-style approach!

MVP Learning Roadmap

You probably heard before about the "Minimum Viable Product" or MVP, a basic version of a product with enough features to satisfy early users and gather feedback for further development, which's commonly associated with Agile methodologies. Interestingly, this approach can also be applied to learning roadmaps too!

Over the years, I saw people want to start their career as DevOps but completely lost! That's probably because they try to progress in a linear fashion. Typically they will follow some roadmap like roadmap.sh/devops and start learning the topics one by one top down. I.e., they spend a couple of weeks with Linux, then a month learning programming language, then some time with the containers, and more time with Kubernetes. And several months passed, and they found themselves stuck in the middle of the roadmap but still unable to get any job because many topics were untouched!

The truth is that the linear vertical learning path DOES NOT WORK in the DevOps field! You need to follow an MVP-style learning roadmap where you learn in iterations and touch multiple parts at the same time (not necessarily equally). Each iteration should focus on a primary topic while exploring related side topics. So after a month, you already know about each topic in the roadmap, and after the 2nd month, you have the basics, and after the 3rd month, you have a good base, and so on.

By adopting an MVP-style learning roadmap, you can ensure that you cover various aspects of DevOps while continuously building upon your knowledge. This approach allows for a more well-rounded understanding and a better chance of landing your first job as a DevOps engineer.

3 different high-level roadmaps models with different approaches to learning, the first two from the left follow the MVP-style, and the last one is linear.

  • The model on the left iterates horizontally in equal chunks over each area (good). It's simple and straightforward, each area (e.g., OS and code, containers and cloud, etc) has a fixed weight based on importance in the daily work. You don't need to think a lot about the next step, from the left to the right, you learn about each area and reach basic knowledge in all of them.

  • The model in the center iterates horizontally in dynamic chunks over each area (better). It's the same as the previous one but a bit more advanced, where it needs hands-on knowledge to decide the right weight for each area (based on many factors like targeted market or learner skills or background). This approach is more efficient; however, it requires guidance from an experienced DevOps engineer (e.g., a mentor or career coach) to define the weights correctly. It's even more critical when you have some sort of constraints like time or so (they are usually there in career shifts).

  • The model on the right iterates vertically over each area (bad). Don't do that! It has several drawbacks. For example, it delays your market fit, where in most cases, you cannot work as a DevOps engineer until you have completed all areas. Additionally, there is no space to review your learning approaches or holistic feedback in general. Finally, it's missing the connection between different areas, at the end of the day at work, you don't use a single skill at a time. I actually saw many disappointed people in the middle of the roadmap because they still didn't get the full picture.

So to ensure a more effective learning journey, it's recommended to adopt an MVP-style learning roadmap that allows for iterative learning across multiple areas while also considering the relevance and importance of each area in real-world DevOps work.

The Solution!

⭐ Check out the Dynamic Roadmap content ⭐

A dynamic MVP-style learning roadmap is one of the best ways to start as a DevOps engineer.

Let's put everything together. The Based on my experience mentoring people in different stages (starting their first job, career shift, moving to another work style or company), I have found that the approach of using a dynamic MVP-style roadmap with hands-on projects designed by an experienced DevOps engineer has been highly successful. That means each project will cover all DevOps areas used in the job. It's also essential to understand the targeted market and organizations because, with different DevOps topologies, the DevOps engineer role requirements vary.

In conclusion, to start working DevOps engineer, you don't need to know "everything" about the software development life cycle (SDLC), nor start as Dev or Ops and then switch to DevOps. In many DevOps topologies, you can secure your first job as a DevOps engineer if you invest enough time in learning (not only the technical aspects) and follow an MVP-style roadmap. Also, undoubtedly having a senior DevOps on both ends (during the learning and in the company where you apply) will make your start much easier.

Continue Reading »

11/01/2020

08/08/2019

Your company doesn't need a hero but a team! - Work culture

What I like about working in startups and small-mid companies is that they’re flexible and you can have a visible change and a direct impact. Ironically that's the same reason why heroes and heroism find their way in that ecosystem.

If you have been working in the IT industry for some time and especially in startups, mostly you would have met that kind of people at work ... heroes!

Who are "heroes"?

So who exactly is a "hero"? (sometimes also called "Ninja")

Heroes are some people at work who can do crazy stuff. They are doing everything needed to get things done. They have all kinds of access and privileges. They know all the info that cannot be found anywhere. They are doing the hard tasks that only they can do and solve problems that no one else can solve. However, all of that’s mostly done with no clear mid- and long-term planning, undocumented, and on an ad-hoc style! (so being a hero is not about performance but work practices!)

Managers mostly like them because they, the heroes, get lots of things done quickly for the company. In fact, heroes are not necessarily bad people, assholes, or jerks. Sometimes they are also good and nice but their way of work is just harmful!

How harmful could it be?

Wait a minute! Doesn't that sound good? Many things are getting done fast and on time! Isn't it better if we have more of those heroes?

NO! Unfortunately not! All of that comes at a cost!

Toxic culture

First of all, heroes are heroes because the rest are "normal". Those heroes simply limit the other people in the team and keep them from growing, and the only way to pair with heroes is to be another hero, just like them. But in the end, a company is like a film, there is no film full of stars!

Not only that but also wrong expectations raised against other team members when they don’t do the hero-way! Why aren’t they the next hero?

Technical debt

What heroes are actually doing is like getting a loan, you have a lot of money to spend now, but you drown in debt later ... the technical debt. Maybe everything works "just fine" for now, but later, many things will not.

Teams (and maybe the whole company) will end with fire fighting and an ad-hoc work style. And then when you realize what was wrong, the cost of re-engineering the mess, and fix it, is usually horrible.

Limited growth

When heroes are off or on a vacation, other people tend to be afraid of making changes, because it's not clear how things are working. Furthermore, when heroes are not there, many incidents happen because most of the time they keep things “just work”.

Also if the heroes are not communicating their work (through documentation, short presentations, awareness sessions, etc), then their absence due to any reason (death, accident, etc) means that their team and maybe the whole company are paralyzed.

After all, those heroes are humans and have their limits, hence companies cannot depend on people "individually" but as a "team".

What are heroism signs?

It's not so hard to find traces of hero practices … you just need a closer look, especially on the team level.

  • Do all team members have a common understanding of what they do?
  • Do the team members say "no" from time to time or is it always "yes"?
  • Does the team work extra hours or until late?
  • Does the team have a clear mid-term plan? (between 6 to 12 months)
  • Does the team have a proper onboarding plan for a new member?
  • Is the team in a "freeze mode" when a member is off or on a vacation?
  • How much does planning take place before the actual implementation?
  • How many returned incidents does the team have and on which interval?
  • How many parts of work are undocumented or have no clear way to do them?
Those are the most common signs. The more you have, the bigger the problem.

Reduce heroism and build sustainable solutions!

At the end of the day, when you realize how heroism is harmful to the company, it's probably too late. Mostly you will be on the horns of a dilemma!

If you keep heroes and their way of work, the longer they stay the harder to change. And if you tried to get rid of those practices quickly, you put yourself and the company in an ultimate risk!

It's also worth mentioning, and believe it or not, having heroes as a part of a company is not really a problem per se! In the early stages of the company life, they could help the company growth a lot. The actual problem is when the "hero-way" becomes the default way to work with no proper plan to move towards sustainability.

Unfortunately, there is no silver bullet to fix this. But here are some takeaways you could think about:

  • Plan, plan, plan. It's the way to a smooth transformation and mitigate the hero effect.
  • Build a work culture and practices. Something like Agile and DevOps that encourage teamwork instead of solo work.
  • Sooner rather than later. But if something will not be done now, there should be a reference and plan for it.
  • Get rid of silos. Silos are the best place to grow heroes.
  • Be prepared. Mostly, heroes will leave once there are a process and a proper workflow.
  • People are different. Having a process doesn't mean you ignore individual differences.
  • Change is a risk. Most of the time it needs to be done slowly, but also firmly.
  • Finally, don’t go so far! Having sustainable processes is pretty important, but too much of “process” also hurts! Find the sweet spot of balance, otherwise you will lose “agility”.

That's all! And I hope you have more sustainability and less heroism :-)

Continue Reading »

21/05/2019

Powered by Blogger.

Hello, my name is Ahmed AbouZaid, I'm a passionate Tech Lead DevOps Engineer. 👋

I specialize in Cloud-Native and Kubernetes. I'm also a Free/Open source geek and book author. My favorite topics are DevOps transformation, DevSecOps, automation, data, and metrics.

More about me ➡️

Contact Me

Name

Email *

Message *

Start Your DevOps Engineer Journey!

Start Your DevOps Engineer Journey!
Start your DevOps career for free the Agile way with the Dynamic DevOps Roadmap ⭐

My Latest Peer-reviewed Research Paper

My Latest Peer-reviewed Research Paper
Building a Modern Data Platform Based on the Data Lakehouse Architecture and Cloud-Native Ecosystem

Latest Post

10 Helm Chart Development Best Practices - Kubernetes

About 10 years ago, I used SaltStack extensively and wrote my top 10 best practices for SaltStack formulas . Today, I do the ...

Popular Posts

Blog Archive