From Laid-Off Network Engineer to Platform Engineer: Patryk's Career Journey
- 13 hours ago
- 8 min read
How Patryk went from stuck in manual network work, getting laid off in New York during Covid, to landing a Cloud Platform Engineer role at a tech company — without applying externally.
Watch Patryk's Complete Journey
See the full timeline, the lessons, and the exact study approach that made it work.
Meet Patryk 👋
Network engineer from Poland. Three jobs across London and New York.
Laid off during Covid. Stuck in a Manhattan apartment for three months with no one around.
A few months in the DevOps Bootcamp — before he even finished it — he landed a Platform Engineer role internally. He works now with Kubernetes, Terraform, and AWS, and has had multiple job offers with companies asking him what salary he wants. Today he runs his own consultancy.
This is Patryk's story.
And if you've ever sat through a 40-page Word document procedure wondering whether this is really what IT is supposed to look like — read this.
The Early Jobs: Six Months Here, One Month There
Patryk's IT career started in London during his master's degree. Trainee network engineer. Supporting Wi-Fi networks for theaters across the city. Voice systems. Servers. Small company, just him and one colleague.
After six months, he left. Not because it was bad — because it stopped growing.
"I felt that I didn't learn much after those six months."
His next move was a service desk engineer role at a large ISP. The recruiter had assured him it would be "very network related." It wasn't.
One month in, he handed in his notice.
The reason?
A ticket that took two days. A manual user-onboarding procedure — 30 to 40 pages of a Word document, step by step.
Every time a new company joined their ISP, someone had to sit down and follow that document from start to finish, adding one user to every database, manually.
"They didn't want to automate it at all. They were just, okay, you can do it for a few days. It's just a matter of doing it."
One month was enough information.
💡 Leave Bad Jobs Fast
This is actually a useful instinct. When a job isn't building your skills, every month you stay is a month you're not growing. Patryk recognized that fast.
Most people talk themselves into staying another six months, another year, waiting for things to improve. He didn't.
New York, Covid, and Being Laid Off
His third role was the most interesting so far — a networking company in London supporting low-latency networks for financial brokers. Finally something challenging.
Then the company sent him to New York to support the US region.
Then Covid hit.
"I spent three months in the apartment in the city of New York without anyone."
First they moved him to a hotel over a possible exposure. Then he couldn't go back to the flat because someone else had moved in. Three months, solo, in a Manhattan apartment.
And when he flew back to the UK, the company let him go — because all the brokers had gone remote and there was nothing left to support on-site.
He found another networking role back in the UK. Startup. Government contracts. Interesting on paper.
But this is where something clicked: the problem wasn't this job. It was the profession.
"Networks are built for like 15 years ahead. So if you are going into network engineering, you won't be an architect — you won't be like senior engineers straight away.
The most obvious, the most easiest task would come to you. So replacing switches. I've never had a job in network engineering where I would say, wow, I'm learning a lot day by day. But the first job in DevOps was like, wow — I can't even handle all of those tools."
That comparison told him everything.
Network engineering had a ceiling baked into its structure. DevOps didn't.
The Year of Scattered Learning
Patryk did what most people do.
He made a list of popular DevOps tools. Worked through them one by one. GitLab. Jenkins. Docker. Python. Udemy courses. YouTube tutorials.
He spent roughly a year on this while holding down full-time work.
At the end of that year, he still couldn't build a complete project.
"I had GitLab — we use it for this. Jenkins is similar but for on-prem. Docker is for image generation. But I haven't actually built anything with them. The whole knowledge comes when you actually combine those tools and build something, and you spend hours troubleshooting the whole scenario."
This is the scattered learning trap.
Each course teaches one tool in isolation.
You finish a Docker course, a Kubernetes course, a Terraform course — and then you try to wire them together into something real and it falls apart. Because no course showed you how they connect.
The Terraform course didn't provision Kubernetes. The CI/CD course didn't use Kubernetes.
Nothing was built end to end.
After a year of this, Patryk decided to try something different.
The Decision: Structured Learning Over Scattered Tutorials
He found the TWN DevOps Bootcamp and recognized immediately what had been missing: one complete system, built end to end, each tool added on top of the last.
He did the math on what another year of going nowhere was worth, and signed up.
How He Actually Studied
20 hours per week total — eight hours each weekend day, one to two hours on weeknights
Weekends for building: hands-on projects, uninterrupted blocks, troubleshooting start to finish
Weeknights for theory: reviewing concepts, watching explanations, lighter cognitive load after work
"I didn't really care how long it would take me. I wanted to have the full project fully working, understand every piece of it. Then I can just apply for the role."
He also repeated modules.
If a concept wasn't sticking, he went back and did it again.
"The concept I was struggling the most with — I would go back and just redo the chapter."
Total time to complete: around eight months. The bootcamp is structured for six. He didn't rush it.
The moment things started clicking? The first CI/CD project — Jenkins deploying all the way to Kubernetes.
"That was the first time when we were actually connecting those tools together."
From that point, each project built on the last. By the end, he had something he could actually explain and build from memory.
The Internal Switch: Applied Before He Even Finished
Here's something most people don't do.
Patryk applied for an internal Platform Engineer role at his company before completing the bootcamp. The Kubernetes module was still in progress.
"I applied internally because they were looking for people in a platform team — AWS-based. And I got this job internally."
Why did it work?
Internal applications are a different game. The company already knows you.
✅ They've seen your work ethic.
✅ They don't need to guess whether you'll show up or communicate well.
✅ The business context you already have — how the company operates, their constraints, their priorities — is genuinely useful, and external hires take weeks just to get up to speed on that.
It's also lower risk for the company. If an internal move doesn't work out, they can move you back.
A bad external hire costs recruiting fees, onboarding time, and months of lost productivity.
Patryk had his networking background, his bootcamp projects, and relationships in the company. That was enough.
Day One on the Platform Team
The new role involved Nginx proxies, CloudFront, ECS — lots of Linux networking under the hood.
His old networking knowledge wasn't wasted. It just wasn't as central as he'd expected.
"The networking background helped me probably 20% in DevOps engineering — which was less than I expected. Software engineering background would have helped way more."
That's actually reassuring for anyone worried about not having the "right" background.
It matters less than the skills you build going forward.
The bootcamp prepared him for the technical work.
When Terragrunt came up — a tool he hadn't learned — he mapped it back to what he already knew.
"Terragrunt is just a wrapper of Terraform. Very similar concepts. It's like one, two days of looking at the commands, what it does. And this mindset — okay, I did a similar thing, I will handle that one — that confidence is very important."
His First Big Win: Automating Certificate Renewals
About six to eight months in, Patryk felt confident enough to start proposing changes.
The team had a manual certificate renewal process. Every 12 to 24 months, a solutions architect from a partner company would send a Slack reminder.
Then someone manually created the CSR, sent it to another team, waited for it to go to the certificate authority, paid for the cert, received it back, and uploaded it.
If any field didn't match, the whole process started over.
Patryk migrated all customers to AWS Certificate Manager (ACM).
The technical work: one to two days. He wrote a Terraform module, tested it, applied it.
The actual implementation: one to two months. Convincing stakeholders. Addressing concerns from people who had done it the old way for years. Getting sign-off from multiple teams. Walking customers through the migration plan.
"In IT, it's all about the procedures and people. Writing the code is the simplest part right now — especially with all those LLMs. It's about the procedures."
The outcome: eliminated the manual renewal process entirely. Every customer saved around $200 per year on certificate renewals.
That's the job.
🔍 Identify the inefficiency.
🔨 Build the automated solution quickly.
👥 Then do the longer work of getting people to actually adopt it.
Patryk's Advice: What He'd Do Differently
At the end of the interview, Patryk reflected on what he'd change if he were starting over in 2015 with his current knowledge.
1. Leave bad jobs fast
"If I'm not learning and money is not very high, there was nothing for me to risk. One month or two is enough. If you have enough courage to apply to another job after a couple of months — the next job was more challenging, I got better salary, I could learn more."
2. Build one complete end-to-end project
"I would join the bootcamp again. Build one big project and try to learn a lot of different stuff to build this all-around skill — to be able to ship something from beginning to end."
3. Think like a problem solver, not a job title
"A lot of companies are not looking for specialized people anymore. They're looking for basically problem solvers. They're not looking for software engineers or DevOps engineers. They want work to be done, and that you have this personality of delivering."
4. Make your learning visible from day one
"I would try to record my journey from day one. If I ship something, document it on GitHub, post it on LinkedIn. It's not about the knowledge anymore. Companies are looking for people worldwide. It's also about the marketing. They need to know what you are able to do."
"There are many smart people that nobody knows about them. And it was difficult for them to change the role, even though they are doing a lot of complicated things at their actual company."
Patryk didn't just say this — he went and did it.
He started his own consultancy onlydevops.pl. He also teaches DevOps at Panda Academy.
At the time of writing, he has over 17,000 followers on LinkedIn.
That's what consistent public learning compounds into over a few years.
Not overnight — but the engineers who start documenting on day one end up with options that the equally-skilled engineers who stayed quiet simply don't have.
What This Proves
Patryk's story isn't a shortcut story. It's not "do this one thing and get hired in 30 days."
It's the opposite: a patient, realistic account of what actually works.
Three jobs that taught him what to avoid.
A year of tutorials that taught him what doesn't connect.
Eight months of structured learning that finally gave him a complete picture.
An internal application before he was "finished."
A first win that took two days technically and two months politically.
The scattered phase is temporary. Once you move to a structured approach — building complete projects, understanding how the pieces connect — the confusion clears up.
Not all at once. But it clears.
And as Patryk put it: the question isn't whether you have the right background.
It's whether you'll build something real and let people know you built it.
Ready to Follow the Same Path?
Learn the same way Patryk did — complete, integrated projects that connect Kubernetes, Terraform, CI/CD, and AWS into systems you can actually explain and build.
We helped 1,000s of engineers from absolutely zero DevOps knowledge to becoming a senior engineer, who is proficient in DevOps within just few months.
