Building the secure foundation Ericsson's engineers build on

From intern to building the systems engineers depend on

I did not start out planning a career in DevSecOps. 

Like most engineers, I began with curiosity, an interest in security and blockchain that followed me from my college days all the way into my first role at Ericsson, where I joined as an intern. That curiosity has since evolved into something I could not have fully imagined then: building the platforms and systems that Ericsson engineers across the world rely on every single day to build and deliver the products that keep people connected. 

Today, I work as a Software Developer in the DevSecOps space. My focus spans automation, infrastructure, and security and increasingly, how AI is transforming all three. 

Making complexity easier to manage 

Here is the best way I can describe what I do: I help engineers spend less time setting things up and more time building things that matter. 

Instead of every team spending time setting up and maintaining its own scripts and processes, we try to provide a more plug-and-play experience. 

The idea is simple: teams should be able to enable what they need with minimal effort, while we take care of the underlying automation and maintenance.

A day in the life of DevSecOps Engineer

On a typical day, my work is a mix of improving systems, fixing issues, and collaborating with teams across geographies, colleagues in India, Sweden, Brazil and beyond. 

That collaboration is not just logistical. We follow an inner-source model, which means engineers from different teams actively contribute to shared tools and platforms. A big part of my day involves reviewing those contributions, merging good ideas, and helping build something together that is stronger than what any single team could create alone. 

Behind the scenes, we work with tools like Docker, Kubernetes, Jenkins, GitLab, and Maven — with Jira and Confluence for tracking, and automation tools like Renovate to keep our dependencies healthy and current. 

Technology is just one part of the story what I genuinely appreciate about this culture is the openness. People across different parts of the organisation jump in, propose improvements, and help us build better tools. That collaborative spirit is something I experience every day. 

Team collaboration during a meeting.

The project closest to my heart 

One project I am particularly proud of is the Cloud Software Development Platform; a single, common platform we built for several product teams. 

Before it existed, each team had its own pipelines, scripts, and setups. They were often solving the same or similar problems, just in different ways. That meant duplicated cost, more maintenance effort, and harder transitions for engineers moving between teams, because the tools and standards kept changing. 

Our answer was to build one well-designed platform with central automation and clear structure. Teams now onboard to this platform instead of building their own from scratch. They get a consistent, well-maintained setup and we take care of keeping it up to date and working efficiently for everyone. 

What makes this project special for me is how quietly impactful it is. We listened to many different teams, found the common ground, and then kept improving step by step. Watching more and more teams move onto it, knowing that engineers can trust it and focus on what they actually came to Ericsson to build gives me a real sense of pride. 

What AI means for what I build 

For me, AI is like a digital buddy I can turn to at any hour for a quick answer, a second opinion, or a faster way through a problem. 

But beyond how I personally use it, AI is now a core part of how we build and scale the systems our engineers rely on. My team is working on AI-driven capabilities like MCP servers and agent skills or tools that automate repetitive tasks and make systems more intelligent and context-aware. 

The results have been real and measurable. Teams that have adopted these tools have seen their setup and maintenance effort drop by close to 80 percent. Adoption across the unit has reached around 90 percent which tells me we built something people actually want to use, not just something that looks impressive on paper. 

As a single point of contact for our inner-source MCP servers, I review solutions, ensure good practices are followed, and help manage and maintain these systems. It is a technical role, but it also carries a dimension of leadership influencing how we use emerging technology at scale. 

What excites me most is the direction we are headed: not adding AI on top of existing systems but rethinking how systems should be designed when intelligence is built in from the start. 

Every technology needs a human call 

Automation is excellent at running checks, flagging anomalies, and collecting data. AI can suggest what to do next. But when something behaves unexpectedly or when a decision might affect dozens of teams we still need someone to ask: "What is actually happening here?" That kind of understanding does not come from a script. 

The same is true when choosing a path forward. In my role as a Security Master, and when reviewing our AI servers, I often balance speed, safety, and effort. Sometimes the fastest fix is not the safest one. Sometimes the strictest rule would slow everyone down. Drawing that line is something a person has to do. 

And then there is responsibility. When we design platforms, pipelines, or AI tools, we are deciding how they behave and where they need to stop. Automation and AI can help us do more but they do not carry responsibility for those decisions. People do. For me, that is what human thinking is really about: understanding the context, making the call, and being ready to stand behind it. 

Advice for anyone considering a similar path 

The one piece of advice I would offer anyone thinking about a DevSecOps or platform engineering role is this: work smart, not hard but in DevOps, work smart so others do not have to work hard. 

 A few things I have learned along the way: 

• Reliability comes first: Nobody cares how clever your solution is if it breaks at 2 AM. The best pipeline is the one nobody thinks about because it just works. 
• Learn the "why" before the "how": Do not just copy configuration from the internet. Understand why a container needs those resources, why one stage depends on another. When things break and they will that understanding is what separates you from everyone else staring at an error message. 
• Know what your code costs: Every pipeline, every container, every test suite runs on real infrastructure. Asking yourself whether you are using shared resources responsibly makes you a better engineer, not just a better coder. 
• Automate yourself out of repetitive work: Every time I caught myself doing the same thing twice, I turned it into a script, a pipeline, or a platform feature. That is how you move from firefighting to actually building things that scale. 

At Ericsson, that scale is real, and so is the impact. Stay curious, stay humble, and there will always be something new worth building here. 

Interested in a career at Ericsson? 

If you are looking for a place that does not just enable but actively encourages you to grow into the best version of yourself, explore open opportunities on our jobs page.