Introduction

Looking back over my last couple of years as a Senior Platform Engineer at Holland & Barrett, it’s been a real eye-opener for me. Before landing this gig, I spent eight solid years working with Symfony, a PHP framework that I’ve got a lot of love for. I’ve been doing my thing mostly in Scotland, balancing my time between backend stuff and cloud engineering, with a bit more of my heart leaning towards the backend.

Back when I was in my mid-20s, before I even got into platform engineering, I thought I was on top of my game, able to build and manage applications that were pretty robust. But moving from the fast-moving world of startups to the bigger, more structured corporate world was a wake-up call. It was a whole new ball game, with challenges and learning curves way bigger than anything I’d faced before. It really made me rethink what it means to build tech that works on a large scale.

This post is about diving into that shift, talking about what I’ve learned, the challenges I’ve faced, and how it’s all shaped the engineer I am today.

What is Platform Engineering?

In my time wrestling with cloud-native tech, platform engineering has been about making complex systems simpler to handle. Think of it as creating a smoother interface that lets developers focus on building cool stuff without getting tangled up in the technical weeds. It’s about taking the headache out of dealing with infrastructure so that folks can concentrate on what they do best: adding real value to the business.

The big split between DevOps and platform engineering? It’s all about scaling. In the startup world, you can get by with one jack-of-all-trades engineer. But as a company grows and its products start to reach wider, the tech needs get a lot more complicated.

Take the shift from a monolithic to microservices, for example. Moving to a bunch of smaller, interconnected services from one big application can be a nightmare. You’re looking at more moving parts, which means more things that can go wrong. This shift demands a sharper focus on keeping costs in check, ensuring everything’s running smoothly, and keeping the digital doors locked tight against threats.

That’s where the specialist teams come in. PaaS teams are all about giving developers a break from infrastructure headaches, SRE squads make sure everything’s running like a well-oiled machine, and DX teams focus on keeping the developer experience as painless as possible. Together, these teams tackle the growing pains of scaling up, making sure that the tech doesn’t just grow but evolves smartly.

This teamwork is what sets platform engineering apart from DevOps. It’s not just about bridging the gap between making stuff and keeping it running; it’s about building a whole ecosystem that’s easy to use, scalable, and reliable.

But hey, this is just my take. There’s plenty of debate out there about what “DevOps” really means, with no shortage of opinions flying around on Reddit and Twitter. And just for kicks, here’s a story from the trenches: once had a frontend contractor told me DevOps wasn’t a “real job”… then proceeded to ask for help fixing his failing deployment. Go figure.

The Initial Challenges

Diving into platform engineering threw me straight into the deep end, sparking a ton of growth but also lining up a serious set of challenges:

Stepping Out of My Comfort Zone: Jumping into platform engineering meant leaving behind what I knew best. After years of honing my skills with Symfony, suddenly that expertise didn’t cut it anymore. Facing this was a bit of a shock to the system.
Tackling Terraform at Scale: Moving on to managing and developing our own modules for large-scale, multi-environment deployments with Terragrunt was a whole different ball game compared to my previous work, which was more about direct, hardcoded solutions. This shift pushed me to get a grip on infrastructure as code principles, adding a new layer of complexity to my skill set.
Wrestling Kubernetes: Kubernetes was the giant I hadn’t faced yet. My basic understanding, limited to introductory tutorials, was put to the test despite a false sense of confidence from my time using ECS (Elastic Container Service). It was time to horizontally level up my skillz.
Decoding AWS IAM Policies: AWS Identity and Access Management (IAM) policies turned out to be a real puzzle. Previously, I could get away with a surface-level understanding, but now I found myself having to really dig into the nuts and bolts of how IAM policies work. This deep dive was all about grasping the ins and outs of policy evaluation logic and nailing down the best practices to ensure our cloud resources were locked down tight and managed right.
Datadog Complexities: Facing Datadog’s interface, loaded with metrics and logs, was overwhelming. Figuring out what mattered among the sea of data was a slow process, demanding patience and a keen eye to pinpoint what was actually critical for our operations.
Debugging Across the Stack: Debugging took on a new meaning as I navigated through different layers of technologies. This wasn’t just about fixing bugs; it was about understanding the intricate dance between infrastructure, network, applications, and user interfaces.
Learning Active Directory and User Management: Getting to grips with Microsoft Entra ID and managing user aspects in a large organization was far from the straightforward tasks I was used to. This was a new playing field, involving a mix of identity management, permissions, and security which was crucial given the role of SSO and RBAC on a platform.
Supporting Uncharted Territories: One of the toughest parts was being expected to provide support across all these areas where I was still finding my feet. The pressure to guide, troubleshoot, and maintain system reliability while learning on the fly was intense.

Each of these hurdles was a lesson in itself, teaching me not just about the technicalities of platform engineering, but also about resilience, patience, and the continuous journey of learning.

Growth & Self Development

Jumping into my new role threw me a bunch of curveballs that really made me change up how I deal with stuff I don’t know.

Embracing the Discomfort: Ended up way outside my comfort zone more times than I’d like to admit. It was rough and seriously stressful at points. But, getting uncomfortable lit a fire in me to get better.
The Value of Questions: Hello, imposter syndrome. I was always worried I’d bug my teammates with endless “dumb” questions. Looking back, those moments were gold. Every question helped me get a bit smarter, and the patience and wisdom my teammates shared were clutch for my growth.
The Courage to Ask: Kept asking questions, even if I felt like a broken record. Turns out, getting things crystal clear wasn’t a weakness—it was key to really understanding our work and avoiding big mess-ups.
Some Reading Materials: Not exactly a bookworm, but I did dig into a few reads that made a difference. ”System Design Interview” (pdf) gave me a solid base in architecture, and mindfulness books like ”This Is It” & ”The Power of Now” helped me keep my noisy head clear under pressure.
The Power of Sharing: Throwing my ideas out there and breaking down my thought process opened doors for better teamwork and insight. It was all about learning from each other, whether I was on the money or way off base.
A Commitment to Documentation: We all hunkered down on keeping our docs fresh and up-to-date on Confluence, especially since they were front and center for our clients. Getting into the habit of updating our knowledge base meant I got to learn about a ton of new tech along the way.

This whole chapter has been a wild ride of learning and growing fast. It’s shown me how crucial it is to be resilient, to lean on your team, and to tackle challenges head-on with a mix of curiosity and grit. This experience hasn’t just made me a better engineer—it’s made me a better problem-solver across the board.

Overcoming Obstacles

Chopping Down the Big Stuff: First thing that hit me was figuring out how to slice up those complicated tasks into something I could actually tackle. Doing it bit by bit not only made things less scary but also helped me see how everything fits together. Plus, celebrating the small wins along the way really kept me going.
Getting Cool with Feedback: At first, any sort of criticism felt like a punch to the gut. But I got to a point where I could take it without letting it mess with my head. Seeing feedback as something useful, not personal, was a game-changer. It let me take in what others were saying and use it to get better without feeling weighed down.
Learning When to Take a Breather: Probably the least obvious trick I picked up was knowing when to hit pause, especially when I was stuck banging my head against the wall. Sounds weird, but taking a break when things got too much actually helped clear my head. Coming back with a fresh perspective often cracked the problem wide open.

These strategies didn’t just help me get stuff done; they revamped how I tackle challenges and think on my feet. Definitely lessons for the long haul.

Problems I’ve Observed

In my time on the job, I’ve bumped into some real headaches that show just how tricky platform engineering can be. Here’s the lowdown:

This Job’s a Fucking Beast: Straight up, platform engineering’s tough. It’s not just about keeping the lights on; it’s about figuring out how to grow without blowing your budget.
Shortcut Syndrome: The convenience of our platform tools sometimes leads to a reliance on easy solutions, with a few engineers skipping the deeper dive into how things really work. This habit can spell trouble when unexpected issues pop up and not everyone has the know-how to troubleshoot effectively.
Balancing Act: Trying to scale things up but keep costs down is like walking a tightrope. Every choice impacts performance or the budget, and striking the right balance is hard.
Teamwork Hurdles: Mixing different teams shows off the gaps in what we all know. Getting everyone aligned is easier said than done, but it’s crucial for moving forward together.
Monitoring Madness: Just when you think you’ve got it all sorted, something new pops up that needs watching. It’s an endless game, always finding new stuff to keep an eye on.
Update Overload: Keeping track of all the updates and making sure the team does too feels like a full-time gig.
Engaging Engineers: The real challenge lies in getting engineers to prioritize and adapt to platform changes amid their own packed schedules. It requires persistent outreach and reminders to ensure they’re aligned and responsive to these necessary shifts.
Juggling Act with Priorities: It’s a constant balancing act between ongoing maintenance and tackling items on the roadmap. Figuring out what needs immediate attention versus what can wait is like trying to keep too many balls in the air. Every day is about making tough calls on where to focus next.
Managing Dependencies: Handling dependencies on a large scale is complex. It demands that every project is equipped with robust testing pipelines to ensure that any version updates won’t cause major disruptions.
Handling Egos: You will definitely run into folks resistant to change or just plain hard to work with. We’re all trying to reach the same goal, but that doesn’t always mean it’s smooth sailing. Dealing with it involves a lot of talking, understanding, and sometimes just navigating around those big egos to keep everything on track.

Navigating these issues has been part of the gig, offering up as many lessons as challenges.

Advice For newcomers

Ease Into It: Jumping into platform engineering? Don’t try to conquer everything day one. It’s a marathon, not a sprint. Get your bearings, learn the ropes, and pace yourself.
Own Your Mistakes: You’re going to mess up, and that’s okay. What’s important
Prioritize Self-Care: Don’t let the job consume you. Make time for yourself, your hobbies, and your loved ones. Burnout helps no one.
Stay Open to Change: The only constant in platform engineering is change. Whether it’s a new tool, a process overhaul, or adapting to team dynamics, stay flexible and open.
Get Comfortable Being Uncomfortable: You’ll be out of your comfort zone a lot. That’s where the growth happens. When things get tough, remember it’s all adding to your skillset.

Conclusion

My first year diving into platform engineering was nothing short of intense. It stretched me in ways I hadn’t anticipated, pushing me to expand my horizons and deepen my understanding of various programming languages. I’m not claiming to be an expert in all of them, but I’m definitely more familiar than I was before.

This journey has boosted my self-confidence in my abilities. Seeing my own growth and realizing what I’m capable of has been incredibly rewarding. The transition from a PHP/LAMP stack background to cloud engineering has not only significantly increased my market value in terms of salary but also opened up opportunities for remote work—a non-negotiable for me. Had I remained in my PHP comfort zone, finding roles that meet my need for flexibility would have been much tougher, even in today’s remote-friendly work environment.

I’m still on my way to becoming an expert in platform engineering, but the amount I’ve learned so far has been massive. Tackling Kubernetes and managing it at scale was a real eye-opener, proving to me that I can master complex topics. As someone who’s played guitar for a decade without ever diving into music theory, conquering Kubernetes has left me feeling like there’s nothing I can’t learn if I set my mind to it.

All in all, this experience has been a game-changer, showing me the vast potential within myself and the tech world. It’s a journey I’m glad I embarked on, full of challenges, learning, and growth. And if there’s one thing I’ve taken away, it’s that with the right mindset, persistence, and a willingness to push through the tough times, the possibilities are limitless.