I recently started working at a software company that primarily serves banks. My current role is administrative management, and I'm responsible for coordinating much of the work delivered to customers. I'm comfortable organizing people, tracking tasks, improving processes, and managing deadlines, but I don't yet understand the technical details behind development, architecture, or DevOps work.
After about six months of working closely with our DevOps team, I've become interested in learning the field myself. I'd like to understand what happens when a server goes down, how systems are recovered, and how CI/CD pipelines can be made more useful. I'm not sure whether I want to remain in management or eventually move toward a technical DevOps or platform engineering role, but I want to build a solid foundation.
I've started with Linux and am currently studying basic commands, users, filesystems, and simple Bash scripting. However, the course I'm following covers a huge amount of Linux material, and I'm finding it difficult to tell what is essential for a beginner versus what can wait.
What Linux topics should I prioritize first for a DevOps path? What would be a sensible learning roadmap after Linux, especially regarding networking, Git, containers, CI/CD, cloud platforms, infrastructure as code, and Kubernetes?
4 Answers
A structured, hands-on course can prevent the roadmap from becoming an endless list. Work through Linux exercises, create a small virtual machine or cloud lab, host a simple application, put its code in Git, build a basic CI pipeline, package it in a container, and add logging and monitoring. Each project will show you what you need to learn next.
Learning resources such as roadmap.sh, Linux upskilling exercises, and beginner DevOps courses can provide structure, but use them as guides rather than requirements. The most important thing is to keep practicing and connecting each topic to a real operational problem.
Start with the fundamentals that you can actually practice: Linux, networking, Git, containers, CI/CD, cloud basics, and infrastructure as code. You do not need to master every Linux topic before moving on.
For Linux, focus on navigating the filesystem, understanding common directories, file permissions and ownership, users and groups, processes and services, package management, logs, environment variables, SSH, disk and memory usage, networking commands, and basic Bash scripting. Learn enough to troubleshoot a machine and explain what is happening, rather than trying to memorize the entire operating system.
A practical progression would be Linux and networking first, followed by Git, your company’s cloud provider, CI/CD pipelines, containers, and IaC. Kubernetes is useful, but it will make much more sense after you understand containers, networking, deployments, and the underlying infrastructure.
Be realistic about the transition. DevOps engineering usually is not an entry-level role, and management experience does not automatically substitute for hands-on experience with systems, code, and operations. Reaching that level may take years of progressively more technical work.
That does not mean the goal is impossible. Use your current position to learn from the engineers, take on small technical tasks where appropriate, build labs, and gradually develop evidence that you can troubleshoot and automate real systems. Avoid trying to speedrun every tool at once; strong fundamentals and consistent practice matter more than following a huge checklist.
I understand that it isn’t an entry-level path. I’m not expecting to become a senior engineer quickly, but I’ve seen people make the transition from a nontechnical starting point, so I’m willing to work toward it step by step.
Ask your DevOps colleagues which technologies they use every day and align your learning with that environment. Since your company builds software for banks, understanding reliability, access control, auditing, incident response, backups, monitoring, and change management will be especially valuable.
Keep developing your management skills as well. If you stay in leadership, learning DevOps culture and practices may be more useful than becoming an expert in every tool. Books such as *The Phoenix Project*, *Accelerate*, and *The DevOps Handbook* can help with that broader perspective. If you want a more technical direction, platform engineering is another area worth investigating.
That helps clarify what people mean by Linux fundamentals. I was worried I had to learn every command and subsystem before touching tools like containers or Kubernetes.