From Laid-Off Network Engineer to Platform Engineer: Patrick's DevOps Journey

[00:02] city of New York without anyone. I was even surprised that in IT people still even surprised that in IT people still do this word document 20, 30, 40 pages and you had to go step by step. They didn't want to automate it at all. And

[00:17] after 1 year I was like I'm not able to to actually build anything. I've never had a job in in network engineering when I would say, "Wow, I'm learning a lot day by day." But this first job in Devils was like, "Wow, I can't even

[00:31] handle all of those tools." 6 months at one company, 1 month at the next, 9 months at the third company, manual procedures with 40-page Word

[00:44] documents, no automation, no learning, just repetition. Then COVID hit. He was laid off, stuck in New York apartment for 3 months with no one.

[00:56] Most people would have given up on IT completely at this point. But Patrick didn't. And within 2 years of making one critical decision, he's now a platform

[01:08] engineer working with Kubernetes, Terraform, building infrastructure that companies actually need. He has multiple job offers, companies asking what salary he wants to stop interviewing elsewhere. So, what changed between feeling stuck

[01:23] in manual work and now confidently building production systems. So, Patrick tried learning DevOps for over a year first. Udemy courses, YouTube tutorials,

[01:35] random projects. He had set up infrastructure in AWS. Come back 2 weeks later and everything would be broken. Nothing was connected anymore. The pieces just didn't fit together. In this video, you will see what finally made it

[01:50] work for him. Not just what he learned, but how the structured learning differs from scattered tutorials And why quitting bad jobs quickly is better than staying for years hoping that your current job will improve. And

[02:07] the exact study approach he used that turned his confusion into confidence. If you have tried learning DevOps and felt overwhelmed, or if you are stuck doing repetitive work wondering how others break out, or if you're collecting

[02:21] courses but cannot build complete projects, then this is going to be a proven path that somebody else took that you can literally just repeat. So, let's start with how Patrick even got into IT in the first place.

[02:41] Before you even knew what DevOps engineering was, maybe it was not even a concept back then when you started. So, you have a network engineering background, right? Where you were working in. So, tell me about your

[02:54] journey into IT, into network engineering. What were you doing in this role? You know, how many years of experience you had? I got my first job into IT when I was on my master's degree. At that time, I was working in

[03:08] London as a trainee network engineer. I was supporting all of maybe not all of, but a lot of theaters in London, their Wi-Fi a lot of theaters in London, their Wi-Fi networks, the CUCM stuff related to

[03:22] voice, some servers as well. And it was fun. I spent there only 6 months because it was very small company. I was only network engineer there, to be honest. No, sorry. There were two, myself and my colleague and the CEO of

[03:38] the company. And I just felt that I didn't learn much after those 6 months. So, I applied to other big company called Cancom, which is like big ISP.

[03:50] And I applied for the service desk engineer role. For the first time when I spoken with the recruiter, he told me that okay, this is called service desk engineer, but it will be like very network related. I was like, okay, I

[04:04] don't care about the title. I just want to learn. If it's called service desk engineer, I don't care. I started there and to be honest, I gave a notice after 1 month. Yeah, it's very fast. After 1 month, basically I haven't learned

[04:20] anything. I mean, maybe I did, but it was very company specific. That's the first point. And the second point, nothing was automated. The network was about purely like supporting network, but don't really do anything in those

[04:34] networks. It was only like adding firewalls and everything was documented. I remember one ticket that took me like 2 days. It was very long one and very manual one. I was even surprised that in IT people still do those things and have

[04:49] those manual procedures for like 20 I I I I I I think I recall it correctly. It was around I don't know, 30, 40 A4 pages and it was about every time when somebody joins the the company this ISP was

[05:04] supporting, you had to add one user to all of the databases and everything was manual. And you had the this this word document 20, 30, 40 pages and you had to go step by step and it

[05:18] wasn't challenging. It wasn't interesting. They didn't want to automate it at all. They were just, okay, you can do it for 3 days. Just a matter of of doing it. You can spend on it those 3 days. And I was like, okay,

[05:33] it's not what I was looking for. So, yeah, I gave a notice. A 40-page manual procedure taking 2 days. And when Patrick suggested automating it, they said, "Just spend 3 days doing it manually." And this is actually a career

[05:48] trap that keeps engineers stuck in their current jobs for years. And this is why it's so dangerous. Every month you spend doing manual work and not learning important technical skills is a month that you are not building

[06:04] is a month that you are not building valuable marketable skills and keeping your skills up to date. Generally just making your own work way more boring and anything exciting or new. You're just

[06:18] doing tedious repetitive work manually. And your resume may say IT professional 2 years experience, but what did you actually learn in those 2 years? If the answer is how to follow company specific manual procedures, that knowledge does

[06:34] not transfer. It's not valuable enough for a more common job market. And no other company needs someone who knows custom 40-page user edition processes, right? So Patrick actually recognized this 1 month into his job and he quit.

[06:50] Most people stay 1, 2, even 3 years doing this type of work because they're afraid of how job hopping looks or they're afraid of losing a stable income or getting a challenge in the new job. But here's the thing, 1 month learning

[07:06] nothing and looking for a job is way better than spending 1 whole year learning nothing and not improving anything in your technical skill set. The sooner you recognize a job is not growing your skills or it's not helping

[07:20] you grow as a professional, the sooner you can find the job that actually gives you that growth potential. And this pattern, recognizing bad situations fast and moving on, this is what eventually led Patrick to DevOps specifically. But

[07:37] first, let's see what happened with his third job attempt and the COVID situation that almost ended his IT career entirely.

[07:50] >> Fortunately, I found another role and it was network engineering role at this time finally and it was for the company also based in London and they were supporting low latency networks mostly for brokers.

[08:06] So that was fine. That was challenging. I learned a lot of there and that was the first experience with this networking I had the imagination of. So basically I spent there like 9 months because I was laid off. And this is the

[08:21] funny story because I joined this company after I think that I will go to company after I think that I will go to New York to support the US region and I during the COVID. And it was funny because so I flew to New York. Company

[08:35] had a lot of flats in New York for all of the employees. I got the keys to one in this flat because it was like three bedroom flat. But after a week people from HR or some other department contacted me. There is a possibility I

[08:52] have a COVID and I should move to the hotel. They moved me for one week to the hotel. Then I went back. They said that I can't go back because another person came. I spent three months in the apartment in the city of New York

[09:06] without anyone. That's the whole story. And after I I came back, they basically fired me because obviously we were supporting those offices of brokers and all of the brokers started working remotely. So there was nothing actually

[09:21] >> Let me kind of key into some of the points. So first of all, you you did generally like in technical stuff. So you kind of knew okay, this is a kind of thing for me. Two things that are interesting actually for a lot of people

[09:36] interesting actually for a lot of people is that you started studying this thing there's no demand for that. So, let me actually look around and be flexible can get a job. So, it was pragmatic decision and you tried it and you liked

[09:51] it and you you could then, you know, get a second job and the third job and that could choose between the you're not desperate to stick to one company and I'm not growing. I'm not challenged enough. So, I'm going to actually move

[10:06] to another place. If you find another company and if you like it beneficial, I think on every aspect because you can learn a lot. Also, normally you don't apply for for less money. You at least will get the same amount of money. Yeah,

[10:22] so I think if you are not learning and you are switching jobs, if you have enough courage to to apply to another job or change the job after a couple of months. I didn't care if it's like even like one one for two. If I'm not

[10:35] learning and you know, if money is not like very high, the there was nothing for me to risk to be honest. That's why I made this decision so quickly and for I made this decision so quickly and for me it was beneficial because next job

[10:49] was more challenging. I got better salary. I could learn more. So, for me that was the way. But obviously it it could have been worse. It's always possible, right? That you you you gave a notice. You can went to the company that

[11:03] is even worse. You can always change, right? Because obviously there was enough job openings so that you could switch from one place to another when happens after you get laid off? What what is your thought process? Are you

[11:16] trying to look for another job? Basically that was during the holiday. So, I was like, okay, maybe I will just spend some time in home city. I will go for holidays. I just relax a bit. So, I think I had like a break of 1

[11:32] month or 2. And to be honest, I was silly because it was still COVID, right? So, in the UK, based in Australia, right? Austria. Neighbor of Poland, actually. So, in the

[11:45] UK, basically when you were laid off during the COVID, you were getting like 80% of your salary. So, most people if they were laid off, they didn't care about looking for another job because 80% is still a

[12:00] lot, right? I was silly at that time because I applied to the new role and I didn't benefit from those 80%. I would say it was a startup. They had nice projects for the UK government, networking projects. Here comes the

[12:15] truth in the networks. Networks, I mean, for my previous job as well. Networks for my previous job as well. Networks are built for like 15 years ahead. So, if you are going into network engineering, you won't be an architect.

[12:27] You won't be like senior engineers. By the way, the most obvious, the most easiest task would come to you. So, replacing switches, I don't know if

[12:39] there is any layer two or layer two problem, they would come to you. You need to talk to the tech support on site. Those are low-level issues and you learn something, obviously, but it's not very very challenging.

[12:53] Network engineering right now because it's been in IT for years. One of the first thing in IT is networks, right? So, that's why the bar to get job with prospects is very high because I've never had a job in network engineering

[13:08] when I would say, "Wow, I'm learning a lot day by day." But the first job in DevOps was wow, I I can't even handle all of those tools, all of those repos, and everything. It was like another world of

[13:22] learning. Patrick just revealed why so many network engineers are looking to transition to DevOps or platform engineering. So, let me explain the structural problem here. Networks are built to last 15 years, right? 20 years.

[13:36] And that's great for network stability, but terrible for your career growth because once the network is designed and deployed, your job becomes maintenance. Replace switches, troubleshoot layer two issues, support tickets. The challenging

[13:51] architectural work that was done years ago by senior engineers, so you never get to touch that. Now, compare that to DevOps or cloud engineering. You have the complete opposite situation. New tools every year or every month

[14:05] constantly evolving. You have Kubernetes, Terraform, GitHubs, all concepts. And companies are still figuring out the best practices. That

[14:17] means even junior DevOps engineers get to build things, make decisions, and learn cutting-edge tools weekly or daily sometimes. And Patrick said this perfectly. He said, "I never had a network job where I was learning a lot

[14:32] day by day. But first DevOps job was like, wow, I can't even handle all these tools." But that's not just chaos and just random collection of things. That is really valuable growth opportunity for you as an engineer. And this

[14:48] realization that network engineering had a ceiling pushed him to look at DevOps. a ceiling pushed him to look at DevOps. However, knowing that you need to switch and actually learning DevOps and making the switch are two very different

[15:00] challenges. Did you think, I want to learn something which is related to network engineering, but a little bit more interesting, or did you think, I'm just going to learn whatever, even if it's completely unrelated to networking

[15:12] because I want to do something which is interesting or exciting? Yeah, good question to be honest because I was thinking for about it for for a while. And first of all, I was considering maybe some some programming like like

[15:25] pure Python. The market for Python engineers, especially right now, I mean, in the past, I could get a job as a Python engineer. DevOps is still like related to networking, so I have some kind of background. DevOps is new, so my

[15:39] background is relevant because there is not much people already in DevOps who has like networking DevOps related knowledge. So, that was still enough in terms of networking. The other tools I just learned on the fly, and obviously

[15:54] joining your boot camp was also beneficial because I was able to to actually build something with the theory knowledge I had so from from the networking, from some other like YouTube tutorials or whatever things I was

[16:10] learning. So, what was the reasoning like? Did you compare, for example, salaries between DevOps engineers? Maybe because you could have chosen to become a cloud network or you could have, you know, decided to become like a full

[16:25] stack software engineer. So, did you compare salaries? Did you compare like a number of jobs versus, you know, how many engineers actually knew or could fulfill that role? What was your market research like, so to say, the the entire

[16:37] process? I was reading online about how to switch the roles from network engineering to DevOps or for some cloud roles, and I researched that it's very maybe not easy, but it's easier to switch within the the big company, and I

[16:52] was already working at big company. I had already this business knowledge. big company to have this business knowledge because without it, it's harder. So, I applied for the cloud engineer role internally after

[17:08] Actually, I haven't even completed because I think only Kubernetes module left. Yeah, and I got this job internally.

[17:21] >> [music] >> So, before you found our videos or or bootcamp, what was your learning journey like? Because a lot of people start DevOps is all about. Like, what do you need to learn? And then you see all

[17:33] these tools that they're part of DevOps and you start learning, okay, let me let little bit of Kubernetes. And then they get confused because, you know, how do I tie all these? Did you do the same thing? Like, watch a few videos and

[17:46] tutorials or read blog articles? Yeah, exactly. I did the same thing. So, basically, I was like, okay, let me write down the list of the of the DevOps tools that are mostly used in the big companies. So, I learned from Udemy. I

[18:00] basically or YouTube, I would go, okay, let's go to the GitLab. I was learning GitLab. Then I switched to have a look at Jenkins, then a little bit about, I don't know, Python, Docker, and the rest of the tools. But I haven't built

[18:14] anything because all of those tools weren't all of those tutorials and courses on Udemy, I actually haven't built anything with them. I learned that, okay, GitLab we use for this, Jenkins is similar, but it can also work

[18:28] for for on-prem. It's old, but many companies use it. Docker is for image generation. So, it was like, no, it's very difficult to explain this, but it's like learning bits and pieces to be prepared to to build something. So, it

[18:43] prepared me somehow for the bootcamp to build something or finally, but it would help me during the interview. Because during the interview, they they actually didn't ask me, okay, what is the Terraform, what is GitLab, what can

[18:58] you do in GitLab? But they asked me specifically, what can you build? We have this this pipeline. How would you correlate Terraform with Terragrunt, with GitLab, with AWS? It's good to know, it's good to go through the

[19:12] tutorials only for GitLab, but the whole knowledge comes when you actually combine those tools and build something and you spend hours on troubleshooting the whole scenario of producing something. Why did you just decide to

[19:26] something. Why did you just decide to join DevOps Bootcamp? How long after you have been doing all these Udemy courses and YouTube videos and trying to learn like bits and pieces from everywhere? So, I think it was around maybe 1 year.

[19:40] I was trying to do it myself while managing full-time job. So, obviously it was harder. And after 1 year, I was like, "Okay, I don't have this structure learning. Everything is breaking. I'm not able to to actually build anything

[19:55] because out of hours, let's say I I set up some some infrastructure in AWS. I come back to it in a in a 2 weeks because I don't know, one weekend I had to go to visit my friends or go to visit my family. And once I'm back after 2

[20:10] weeks, something has changed, something stopped working. And I was getting annoyed by it and I was like, "Okay, I need to find some actually structured learning that would help me to go step-by-step." When I saw your boot

[20:22] camp, then I was like, "Okay, structured learning, this is for me." I mean, it was expensive for me at that at that time, obviously, but I was like, "Okay, if it's structured learning, this is what I'm looking for." And

[20:34] actually people nowadays, I think they are looking for if they want to join a boot camp, they want structured learning from somebody who has done it before, spent hours building this, figuring out, but now it's working for you, so you can

[20:49] learn it faster than him or herself, right? 1 year. Patrick spent 1 year trying to learn DevOps through Udemy courses, YouTube tutorials, random demos here and there. And at the end of that year, he couldn't build a complete

[21:04] working project. And he felt that because he didn't have the confidence, everything kept breaking and he just was not able to put the pieces together. And this is a real common trap thousands or tens of thousands of engineers are stuck

[21:20] in right now. Let me show you exactly why this approach fails. Let's analyze this. When you take separate courses, each one teaches you one tool in isolation. So, you have Terraform course that teaches you how to provision

[21:34] infrastructure. Then you have Kubernetes course that teaches you how to deploy containers on Kubernetes clusters. Then you have Docker course where you learn how to build images, push the images to

[21:46] repository. CI/CD course completely separated that is supposed to teach you how to build pipeline. So, you finish all four of these courses, you have certifications from all of them, you feel like you learned something. And you

[22:00] did, you learned those tools, right? But then you try to build a real project tools together to build an end-to-end DevOps process. You say, "I'll use Terraform to create a Kubernetes cluster, then I'm going to deploy my

[22:13] Docker images with a CI/CD pipeline to the Kubernetes cluster. And nothing works or you're literally just stuck because you don't know how to implement that. Why? Because the Terraform course did not show you how to

[22:27] provision Kubernetes cluster on an AWS environment, for example. The Kubernetes course assumed you already had a cluster. The Docker course did not connect to the CI/CD pipeline. And the CI/CD course did not use Docker,

[22:40] Kubernetes, and Terraform. It used maybe completely different tools than what you learned before. Plus, this was Patrick's experience himself. He said, "I set up infrastructure in AWS. I came back two weeks later, something broke and

[22:54] everything stopped working." So, when you're learning scattered with bits and pieces here and there, you're constantly losing context. You set something up, then life happens, something comes in between, you come back, you've forgotten

[23:09] where you were, you don't have the structured guide anymore, the infrastructure has changed or timed out, some copy-pasted code or configuration that you don't know how you put that together anymore from what sources, so

[23:23] you can't properly troubleshoot or debug, and you spend more time figuring debug, and you spend more time figuring out what you did before than actually learning forward. And in many cases, you spend more time trying to understand

[23:35] spend more time trying to understand which resources to put together to learn than actually learning as well. And this is why structured learning works much more effectively because you build one complete system end to end. You start at

[23:49] step one, and then you go all the way to step 10, 20, and so on, adding one additional tool at a time. Like Terraform provisions infrastructure, configures it with maybe Ansible, then deploys Kubernetes clusters, sets up

[24:03] CI/CD pipeline, adds monitoring, then you have this Everything is you're building this one coherent project, and you see how the pieces

[24:15] integrate and connect, which is probably the most important part in DevOps. But here's probably the most important thing. Even with structured learning, thing. Even with structured learning, Patrick struggled, actually.

[24:33] had a full-time job, so you had to kind of find time somehow to carve out time because, especially later in the boot camp, the projects become a little bit more intensive, so you have to have the full context, so to say, to start

[24:49] building the project and then kind of build step by step on top of it. So, did you go from beginning to the end? Did you pick specific modules? This time I learned from my mistakes and I just started from from chapter zero and I was

[25:03] going just step by step. If I if I didn't get anything at at the first time, I would just spend more hours on it to to understand the topic and then I would move on. So, I didn't really care how long it will take me. I wanted to

[25:17] have this full project fully working, understand every piece of it, then I can just apply for the role to to to be job ready. How many hours did you invest in learning or studying during the week? Around 20 hours a week. Normally, that

[25:31] was like 8 hours per day during the weekends if I had the time during the weekend, so that would be like a whole whole normal day and then 1 hour 2 hours >> Because I've heard from some students that did the entire boot camp and

[25:44] sometimes they would come back either do the second round or do the module and then go back and do the second round, so to say, to kind of make sure that they really grasp concepts. Did you do the same thing or kind of zoom in into some

[25:57] of the projects? Yeah, I did the similar thing. So, once I was fully done with the project, I was trying to separate everything in my mind and the concept I was struggling the most with, I would go back to them and just redo the chapter.

[26:12] And how long did it take in total to complete the boot camp? I think more than than 6 months. I think it it's supposed to be completed in 6 months, but for me it took like 8. >> I mean, comparing to 1 year of studying

[26:25] like bits and pieces, it's still like 6 to 8 months is it sounds a lot, but if the line, especially without having any missing gaps, then it's like university, but condensed, so to say. Because at the

[26:38] beginning of the that was boot camp, the modules are much simpler. Did you think know, be patient, I'm going to do those projects because I know that I'm going to need that knowledge, they will all come together, so to say, later in the

[26:50] boot camp? Yeah, I wouldn't say I was patient, but I was trying to be, yeah. So, when in the bootcamp was the first time where you felt like, "Okay, now I feel like all those pieces that I've been learning for the year before, but

[27:04] bootcamp are coming together and I'm actually building something that feels thing." Like, do you remember what project it was in the bootcamp? When in that was? Yeah, I think that this was the first

[27:19] the first CICD project when we were actually connecting all those tools together. There was the Jenkins deployment, right? All the way to interesting because that's like halfway through the bootcamp and then starting

[27:33] from that point, the projects are getting incrementally more and more difficult and advanced. So, you basically had a really good combination of your networking background and, you know, layered on top of that, the DevOps

[27:47] DevOps module in the DevOps bootcamp, we also have a complete module on Linux. Did you need any parts of that module? Like, did you still do it and see if you had any missing gaps that you could fulfill or did you not need it basically

[28:03] because of your experience? Yeah, I I needed it. I mean, I had obviously some basics knowledge even from the university. My course was mostly like university. My course was mostly like 80% into into Cisco. Obviously, it's

[28:18] still like based on the Linux and if you if you if you copy any image, you still use Linux command or something. I needed this module and it gave me also the the good background for for for this role. And now I use this knowledge almost

[28:33] almost every day because in AWS, Linux is everywhere. So, it's more beneficial than Cisco because I don't use Cisco at all, to be honest, right now. Yeah, shows that even though you were impatient, you were still patient, so

[28:48] you didn't actually skip stuff like some people do because they want to the paradox is that people who try to skip and take a shortcut, they actually take longer because they have to come back at some point. So, they have they actually

[29:00] stretch the the process much longer. 20 hours per week. 8 hours each weekend hours per week. 8 hours each weekend day, 1 to 2 hours on weeknights. This is obviously not random. This is a very strategic time management for proper

[29:15] deep learning. And here's why this approach works way better than trying to study every single day just a little bit like 10 minutes and 20 minutes. Because eight uninterrupted hours, this is when you build complete projects without

[29:32] losing context. So, you set up infrastructure, deploy applications, debug and troubleshoot when things break, which is where you learn probably the most. And you need this sustained focus to actually complete something

[29:45] end-to-end, something more complex than like a 20-minute tutorial. You can't build a complete CI/CD pipeline that deploys to Kubernetes with production-grade configurations in 30-minute chunks. So, for that type of

[30:00] learning, you actually need some deep work sessions, multiple uninterrupted hours in one go. But then you have these weeknight hours or shallow work sessions, and you can use them for watching theory videos or reading

[30:15] documentation, reviewing concepts. So, lighter cognitive load after a full work Where you understand the concept, understand the logic behind it before you do the hands-on demos, for example. And what I've seen is that most people

[30:30] And what I've seen is that most people study every day for 30 minutes to an hour. And that sounds disciplined, but it doesn't work for deep, complex, DevOps processes because you're

[30:44] constantly reloading context. You're asking, "What was I building? Why did I make this choice? Why did I make these configuration changes?" So, you spend the first 20 minutes of that session just remembering where you were, what

[30:56] stopped in the middle of troubleshooting. So, Patrick's approach was he would block full days for building, weeknights for reviewing and more lightweight work. And this would separate deep work from shallow work.

[31:12] separate deep work from shallow work. But, here is a very important part that consider. And this was Patrick's perspective where he said, "I did not care how long it would take me." He wasn't racing to finish, to get to the

[31:26] deadline, and just have the lectures completed and watched. He was focusing on understanding properly without rushing the learning process because you know when you understand something completely and confidently and when you

[31:39] can move on to the next topic. And this patience is actually very rare. Most people rush through the modules, they check the completion boxes, wonder why concepts do not stick because they are so in rush to just complete something,

[31:55] get the certification, but they don't focus as much on actual learning and understanding. And he would repeat it until it clicked, and it did click finally through hands-on projects that he was doing and building. Now, you may

[32:09] be thinking, "But, I need to finish fast to get the job, right?" And Patrick was thinking that as well until he realized something important. Let's see what happened when he actually applied for DevOps roles.

[32:27] >> Okay, so what happened after completing the DevOps bootcamp? Did you apply for a job internally in the company or did you try to to DevOps engineer job? >> I applied internally because actually that they were looking for for people in

[32:41] the AWS like a platform platform team. So I applied there. Was it platform engineer or junior DevOps engineer? Like what role did you did they give you? Yeah, it was like platform engineer, but this team were supporting the deployment

[32:56] to the ECS. So still a lot of networking was involved because yeah, all of those was involved because yeah, all of those engine X proxies, the cloud fronts, uh also ECS. So there was maybe maybe that's why I got this role because a lot

[33:11] of networking was involved. If it wasn't like obviously Cisco or Juniper networking, but it was Linux networking. The basics are still the same. >> When you joined the team and you it was kind of first time for you to actually

[33:24] like at work. So how much did you feel like the boot camp actually prepared you for the real world so to say so that you could actually take on the task and you didn't have to ask your team comrades or colleagues all the time how you could do

[33:37] it, but kind of felt like okay, I'm actually confident that I can manage this myself or at least some of the tasks. Did it match the reality or the actual in practice for that specific project that you joined? At least for me

[33:49] this is the most important thing. If you've done something similar in the past or if you know the tool already, you are more calm when you get the new task, but if you get the task with the technology you haven't

[34:02] worked before, you haven't heard of it before, it can be really scary, I would know how long it will take you. You don't know where where to to open the documentation, how it works, what it is. For example, from the from the boot camp

[34:18] because we were managing our tools using the Terraform. My approach was very like okay, I've done it multiple past during the boot camp Terraform, I know it. And when we introduce Terragrunt, I was scared, but

[34:33] I did some learning. Okay, Terraform is just a wrapper of the Terraform. It's similar, very similar concepts. It's like, let's say, 1 2 days of looking at the commands, what it does, etc. Just give me a better confidence of myself

[34:48] and this mindset. Okay, I did similar thing, I will handle that one. And I applied internally. He hadn't even finished the boot camp. Kubernetes module was still in progress and he got the role. This actually shows you

[35:02] something important about internal transitions that a lot of people do not take advantage of. Now, think about this. The internal switches are easier. Why? Because, first of all, you are a known person, known quantity, right?

[35:16] External candidates are unknowns. They need to go through the interviews from, you know, character traits to technical expertise. Can they show up? Can they work with teams? Can they communicate? But, you've already proven all of these

[35:29] soft skills. You're part of the company already, right? The company knows that you can deliver. So, it's easier entry. The second reason is the business context that you already have. And Patrick mentioned this. You understand

[35:42] how the company operates, their systems, their constraints, their priorities. A DevOps engineer who knows the business can contribute immediately, whereas external hires need a few weeks or months to even understand the context

[35:56] and what the company is doing. Another reason is that it's a lower risk for the company because if you have a bad external hire, they wasted months recruiting, onboarding, training. Maybe they even paid a huge amount for the

[36:09] agency who found them the engineer. But, if they have a bad internal transfer, let's say, a software developer who moves to a DevOps department or DevOps engineer who moves to the platform team, they can just move them back to their

[36:22] previous role. It's a much more lower risk scenario. And finally, you can apply before you are ready. With external applications, you're competing with hundreds of candidates. You need to be fully prepared at very specific time

[36:37] when the interviews are open, right? But with internal applications, you have relationships. People know your work ethic, and they're willing to bet on your potential. And in many cases, it shows positively when you're motivated

[36:51] to switch roles to a more valuable position inside the company because it also shows you want to grow your career. So, Patrick applied with incomplete DevOps experience and knowledge. And some external roles may have rejected

[37:07] him, but internally, they saw his background, his networking knowledge, the boot camp process, the DevOps project that he had built, and they took the bet. Now, here's the critical question. Was he actually ready for the

[37:20] work? Because the boot camp projects and real production work are different, right? So, let's see what happened on day one on his new role.

[37:37] at the beginning? Long before you felt really confident in your role, like I stuff like every single day or or at least have that fear of, "Okay, there's I've never heard." >> I think like 6 to to 8 months, I was

[37:52] feeling confident that I can support the network. And this is actually the moment when I started my on-call rota to to support actually the platform. Do you remember if you had any examples where you were you knew the concepts from the

[38:07] boot camp that you could actually teach your team or explain to them or kind of introduce, maybe suggest them new tools or new ways of doing stuff because you kind of learned that as a best practice. Like did you have any such examples? I

[38:20] have one. Technologically, it was a small change, no not much, but when it comes to the benefit was huge. And that was basically a certificates in the cloud. So, when I joined the team, we had the procedure renew the certificates

[38:36] like every 12 or 24 months. And the procedure was very long and it involved a lot of people because basically some solutions architect from another company

[38:50] to remind us on Slack that there is a certificate that is due to expire. Then we had to manually create the CSR to be signed. Then the CSR had to be sent to

[39:02] the solutions engineer from another team. Then they had to send it to the certificate authority to be signed. Then they had to paid for the cert. They need to send it back to us. Then we had to upload it. Sometimes they were sending

[39:16] upload it. Sometimes they were sending us wrong CSR signs. So, maybe they were renewing a lot of them. I didn't have like a straightforward procedure to do it. There were a lot of issues along the way with those certs. Sometimes some

[39:28] fields didn't match. Some fields has changed and they didn't let us know. I decided to migrate all of the the customers to to the ACM in AWS and the benefit was first of all that we won't need to deal with those renewals

[39:44] anymore. And the second thing is every customer would save, I don't know how it customer would save, I don't know how it was around 200 uh dollars per per year for the certificate renewal. It took me a lot of time to do it even though the

[39:58] the change in the Terraform code took to write a module and apply it to took me maybe a day or two. But to speak with all of the stakeholders, to speak with all of the customers, I think it was like 1 month or even two because people

[40:12] were scared that well, we've been doing this for years, renewing those certs. Are you sure it won't break anything? They would bring, you know, head people to the conversations. They wanted to clear plan

[40:28] what what I'm going to do if it was tested. They wanted also the names of the teams for this stuff was already deployed. So, it was Yeah, it's like in people, but now, especially in coding, right? The

[40:45] the writing code is the is the simplest part right now because we have all of procedures. This story reveals the hidden reality of DevOps work that no boot camp can fully prepare you for. And this is an honest reality. Technical

[41:01] solution, 2 days. He wrote Terraform module, migrated to AWS platform, tested, done. The political implementation wanted 2 months. Convinced stakeholders, addressed concerns, documented migration plan, got

[41:17] buy-in from teams, coordinated deployment. So, the boot camp prepared Patrick for the 2-day part. He knew Terraform well enough to write the module quickly. He knew AWS from different projects. He understood how to

[41:31] test infrastructure changes safely. So, that's the technical foundation. But convincing people, dealing with we've been doing this in this way for years situation, managing fears about breaking production, that's learned on the job.

[41:47] That's the practical work experience that comes on top of the technical skill set. And that is often very company specific. And it's perfectly fine. This is how it usually works. And the boot camp gives you technical competence, but

[42:01] the job gives you organizational experience. Without the technical foundation, Patrick could not even have proposed the solution. He would have just followed the manual certificate renewal process forever like everyone

[42:14] before him. But because he had the technical skills, he had the confidence technical skills, he had the confidence to recognize the inefficiency, know a better solution existed, build it quickly, demonstrate that it actually

[42:28] worked, and then do the political work of getting it adopted, and getting the develops engineers actually do. You're not just maintaining systems or building architecture of things. You're identifying problems, building automated

[42:42] solutions, and convincing your team members, managers, a lot of people in the organization to actually adopt them. And notice the impact. Saved every And notice the impact. Saved every customer $200 a year. Eliminated manual

[42:56] renewal process involving multiple teams. Automated away an entire class of problems. That's the kind of contribution that will get you promoted, that will get you noticed, that proves that you are valuable for the team, for

[43:10] the entire company. Now, let's talk about what Patrick learned looking back on his entire journey. Because his advice for future engineers is extremely advice for future engineers is extremely practical.

[43:28] ago was that? >> I think I started in 2015. Okay. So, >> I think I started in 2015. Okay. So, let's say we go back to 2015, and you're you have. So, you have all the experience, you have all the knowledge,

[43:43] are starting from zero. So, you don't have any skills, but you know kind of what works and what doesn't. So, with that knowledge, how would you change that knowledge, how would you change your journey or your path to learning,

[43:58] you know, getting your jobs, getting into a work workplace to kind of get to your goals faster? First of all, a lot of companies are not looking for specialized people right now. I mean the big companies small still look for

[44:10] specialized people, but the big companies look for people all around there that would take any task that they have some python knowledge, they have some AWS knowledge, maybe some azure. They are looking for basically problem

[44:23] solvers. They are not looking for software engineers or devops engineers anymore. The work to be done and that you are have this personality of of delivering the work they need. If I was starting I out, I would

[44:37] probably join your boot camp again, build one one big project, and try to learn a lot of different stuff to be this all around there is to to have to to be able to ship something from the beginning to an end. Okay, so you would

[44:53] start by building something like end-to-end thing, and then you would know, I'm going to become this role or that role or this profession, you would kind of map that to what is it that companies are looking for in terms of

[45:06] like a problem problem solver, and then map my project building skills to that advice actually. I love that. That was it actually from my side. This was super interesting. I'm a representative of our community whenever I'm doing those

[45:21] interviews because I'm also always thinking what what will be interesting, beneficial, valuable for those people because I know a little bit of what concerns and doubts and hesitations they have, especially this is obviously going

[45:33] to be way more interesting for network engineers because they can identify relate to your story. We're going to share it with them for sure. One thing I forgot I would do for sure. I would just try to record my journey from from day

[45:47] one. Just, you know, if I ship something, do it the proper way, document it on GitHub, post it on LinkedIn, I don't know, on any social media. Try to maybe join some local communities,

[46:00] meet some people. It's not about the knowledge anymore because yeah, companies are are looking for people worldwide, so it's also about the the the marketing. You need to They need to know what you are able to do. So,

[46:14] basically, in not just learn in quiet in your cave, but also show people that you're learning and that you know this stuff. So, kind of self-marketing, right? Yeah, because there are many smart people that nobody knows about

[46:27] them and it's just difficult for them to to change their role even though they are doing a lot of complicated things at their actual company. >> That's a really good advice because, let's say, you could be an average

[46:40] engineer with like average skills. If you market yourself better, you're going to have much more opportunities, much higher chances of getting your dream job than someone who is a exceptional engineer, but they're not exposing

[46:55] themselves and they're kind of stuck in their region or company or in their good point. And because a lot of engineers I know they're kind of against any type of sales or marketing stuff, but essentially, when you're going on a

[47:09] job interview, you are selling yourself. So, here you're just starting before the So, here you're just starting before the interview by selling yourself to to get multiple options and opportunities. And that helps also after you are actual

[47:22] DevOps engineer because if you want to to implement to the team signing new tool, you need to sell it, right? To the rest of the of the engineers and and those skills helps. To wrap this up, let me give you Patrick's complete timeline

[47:35] so you can see the real roadmap that you can literally just follow and repeat yourself. So, you have phase one, which is the job hopping phase. First job, 6 months, left because he was not learning enough. Second job, just 1 month, left

[47:51] because manual work, no automation, no career growth, no skill set growth. Third job was in 9 month, he was laid off because of COVID. So, total was about 16 month across three network engineering roles. Phase two was the

[48:05] COVID breaking point. Was stuck in New York apartment for 3 month during lockdown. Returned to UK, took another networking role, realized network engineering had a growth ceiling in general, so it was the profession issue

[48:18] and not the job issue. So, he realized he wanted to switch to a profession that satisfied his need of growing professionally and also future proving his engineering career. So, DevOps came into the picture. And with that, phase

[48:34] three, which was the scattered learning of DevOps. So, over 1 year trying Udemy courses, YouTube tutorials, building infrastructure on AWS, learning different tools, but not able to connect the pieces together because everything

[48:47] the pieces together because everything felt so scattered. Phase four, decided to follow a structured DevOps learning with the DevOps Bootcamp. But, more importantly, he study, he dedicated a lot of time to this. He studied 20 hours

[49:00] per week consistently. 8 hours each weekend day, 1 to 2 hours on weeknights. weekend day, 1 to 2 hours on weeknights. Later, saw that 80% of those projects actually overlapped with real work that he was doing as a DevOps engineer. And

[49:14] then came phase five, even before finishing the Bootcamp, which was the internal switch to DevOps engineering role. So, he applied for cloud platform engineering role internally before even finishing the Bootcamp. He leveraged the

[49:28] business knowledge and existing relationships in the company, got hired based on the demonstrated learning and potential. And with phase six, he had his first win. Certificate automation project, 2 days of technical work, a

[49:42] little bit longer for stakeholder management. He showed actual value by saving customers $200 per year, eliminated manual renewal process. So, he proved value through automation and problem-solving, which is a very typical

[49:57] DevOps engineering skill set. So, his total timeline from network engineering to platform engineer was approximately 2 to 3 years with the boot camp phase being the turning point that made

[50:10] everything faster and more efficient. So, what made it work eventually? There highlight. The first one was willingness to quit bad jobs fast. Three jobs in 16

[50:22] probably call these job hopping, but Patrick calls it searching for growth. He didn't waste years in environments that didn't teach him anything and didn't help him grow professionally. The second element was the structured

[50:36] learning decision. After 1 year of scattered tutorials and failing to learn or see progress after 1 year, he recognized he needed complete projects showing how to integrate tools. Not Terraform alone, not Kubernetes alone,

[50:52] not Docker in a separate course or tutorial, everything working together in tutorial, everything working together in one complex production-grade project. Another element, which is very rare in people, is the patient repetition. He

[51:06] didn't care how long it took. If Kubernetes needed three repetitions of the entire module, he did three iterations. So, he was focusing on understanding, not rushing the completion and checking off the lectures

[51:20] Another one, which was very smart, was the internal leverage. He applied where he already had relationships and business knowledge even before he was fully done with that structured learning of the DevOps boot camp. It was lower

[51:35] risk for the company and easier path for him. And finally, the self-marketing awareness. Looking back, he wishes he had documented his journey publicly from day one. The GitHub projects, LinkedIn posts, making his learning visible

[51:48] because knowledge alone is great, but you can massively boost it by making it visible publicly. People need to know what you can do, what you can build as an engineer especially. And here is his insight about his engineering

[52:03] background. He said that network engineering helped him probably 20% in DevOps engineering, which was less than he expected. He said software engineering background would have helped him way more because it has more

[52:16] overlaps with the DevOps engineering profession. So, if you are worried about not having the right background, it matters less than you think. What matters is if you have a proper learning roadmap and you have patience to build

[52:31] complete projects and just stick to it, you can compensate for the lack of prerequisite knowledge and still become a professional DevOps platform engineer regardless of what engineering background you have. So, if you're stuck

[52:45] in repetitive work right now, or if you've tried scattered tutorials and whether this transition is even possible, Patrick's path actually proves that it is. But not overnight, not without effort, not with a few simple

[53:02] demos and hands-on projects, but it's absolutely achievable with the right approach and enough effort invested in it. The scattered phase is temporary because when you move from scattered learning to a proper structured

[53:17] learning, the results are going to be real. And you're going to see that you can transition from any engineering background within just one to two years to DevOps or platform engineering profession. From manual, boring, maybe

[53:31] unexcited work to automation and more exciting DevOps architect role. From processes and solutions. So, the question is not whether it's possible

[53:43] because Patrick already proved that. Question is whether you will take the same structured approach and you will invest enough time to actually make it work. I think this type of stories actually prove and demonstrate a real

[53:57] path that a lot of people get inspired by. So, I hope it did this for you as well and I hope this was valuable and motivational. If it was, please let me know exactly what resonated with you. And with that, thanks for watching and

[54:12] And with that, thanks for watching and I'll see you in the next video.