From Managing Infrastructure to Building It

In this article, I share what surprised me when I moved from IT administration to backend and infrastructure engineering, and which skills transferred better than I expected.

For several years, I worked in IT administration. I wasn't writing code every day. My role was to keep the company running smoothly: managing user accounts and permissions, coordinating tasks with our overseas IT teams, and choosing the tools the whole organization would rely on.

Whenever we needed a new endpoint detection and response (EDR) or mobile device management (MDM) solution, I was responsible for evaluating the options, running proof-of-concepts, and leading the deployment across all our offices.

Today, I'm a backend and infrastructure engineer.

Some of the technologies are familiar, but the job is completely different. Looking back, the biggest surprise isn't how much I had to learn. It's how much of my previous experience still helps me every day.

Seeing the same tools from a different perspective

One of the things I enjoy most is using the tools I used to administer.

As an IT administrator, I managed Jira, Confluence, Miro, and several other SaaS platforms. I configured projects, managed permissions, assigned licenses, and answered requests like "I can't access this board" or "Can you add me to this space?" I knew these tools inside out, but only from the administrator's perspective.

Now I'm simply another user.

I'm moving Jira tickets during sprint planning, brainstorming architecture on Miro, and writing documentation that my teammates will actually read. It's funny how different the same tools feel when you're using them instead of managing them.

That change also gave me a new perspective. Because I understand what happens behind the scenes, I usually know why a permission is missing or why a workflow behaves the way it does. At the same time, being a user has made me realize that some administrative decisions I made years ago probably felt frustrating for the people using those tools every day.

It's a small lesson, but an important one: once you've been on both sides, you naturally develop more empathy for everyone involved.

What I brought from IT administration

People often think moving from IT to software engineering means starting over. That hasn't been my experience. A lot of the skills I developed in IT transferred surprisingly well.

Rolling out an EDR or MDM solution wasn't just installing software. It meant gathering requirements, comparing vendors, running pilot projects, planning deployments, communicating with users, and supporting the rollout afterwards. That's not very different from delivering a software feature from idea to production.

Working with distributed IT teams also taught me how to communicate clearly, document decisions, work asynchronously, and collaborate across different cultures and time zones. Those skills matter just as much in engineering as they did in IT.

Security is another example. After years of managing identities, permissions, and access rights, concepts like least privilege, authentication, and authorization became second nature. The difference today is that instead of configuring those systems, I help build them.

The direction of the work has changed. Before, I was responsible for operating tools built by others; now I have the opportunity to build systems myself.

Becoming an engineer in the age of AI

There was one thing I didn't expect: I became an engineer at exactly the moment AI became capable of writing surprisingly good code.

Not long ago, developers were mostly judged by the quality of the code they produced. Today, AI can often generate clean, working code in seconds.

That naturally raises a question: if AI writes the code, where does an engineer create value?

I've spent a lot of time thinking about that, and I've come to a simple conclusion: the value isn't just in writing code anymore. It's in everything around it.

Owning a feature from start to finish matters. AI can generate a function, but it doesn't understand the business context, coordinate with teammates, deploy to production, or support the feature after release.

Helping your team matters too. Software is built collaboratively. Reviewing code, sharing knowledge, improving documentation, or helping unblock someone are things that make an entire team more effective.

And perhaps most importantly, understanding the client matters. A client rarely asks for exactly what they need. I learned that long before becoming an engineer while selecting enterprise tools for an entire company. Understanding the real problem behind the initial request, challenging assumptions, and turning business goals into technical decisions still requires human judgment.

AI is an incredible productivity tool, but it doesn't replace that kind of understanding.

If anything, AI has changed what it means to be a good engineer. Writing code is still important, but it's no longer enough on its own.

Closing thoughts

Moving from managing infrastructure to building it has been one of the best decisions of my career.

Instead of holding me back, my background gave me a solid foundation: project ownership, collaboration across international teams, a security mindset, and a better understanding of the people who use the systems we build.

Starting my engineering career during the rise of AI turned out to be an advantage in an unexpected way. From day one, I had to focus on skills that go beyond writing code: understanding the problem, owning the full lifecycle of a feature, and helping the people around me succeed.

If you're working in IT and wondering whether engineering is the next step, I'd say this: you probably already have more transferable skills than you realize.

Article Photo by Brett Sayles on Pexels