I've been working for six months as a junior DevOps engineer at a women's healthcare startup. I originally joined because the team needed more AWS experience, especially for deploying ECS workloads that support custom Prefect pipelines. Since then, my responsibilities have expanded to include observability with SigNoz and OpenTelemetry, CI setup, networking, a dedicated Traefik machine, wildcard domains, and SSL configuration.
Lately, though, I feel like I've stopped learning. The excitement I had for exploring DevOps tools is fading, and after work I mostly want to relax and play games. I'm concerned that I'm becoming too comfortable, especially early in my career, and that I should be building skills that will keep me useful as the industry changes.
How can I get my motivation back without forcing myself into burnout? Should I focus on going deeper into the systems I already manage, or learn something new such as infrastructure as code, autoscaling, or canary deployments?
4 Answers
First figure out what you actually enjoy. If networking was the part that pulled you in, you could explore areas like VPC design, routing, container networking, autoscaling, and progressive delivery. If you like variety, an SRE-style path may suit you. You don’t have to master every topic at once—choose one practical project, such as adding autoscaling or a canary rollout to an existing service, and finish that before moving on.
It’s also worth looking beyond infrastructure and getting closer to the application itself. Help developers improve their code, add useful metrics and tracing, understand how the pipelines behave, and work on observability from the user’s perspective. There are probably plenty of valuable projects already around you; you may just need to look for problems rather than technologies to study.
I think you’re right that this is partly a mental block. There are several things I want to explore, including the Pulumi setup we already have, but I keep putting them off.
You may not be stuck—you may simply be moving from learning new tools to taking real ownership of systems. That stage is less flashy but often more valuable. Pick one area and go deeper into its failure modes and operational details, such as ECS deployments and rollbacks, Pulumi or Terraform for repeatability, AWS permissions and secrets, backup and restore procedures, or incident response for the pipelines. Making the existing setup reliable, understandable, and supportable will teach you more than constantly adding another tool.
That makes sense. Responsibility has come up a lot in our meetings, and I hadn’t really thought of it as the next stage of learning.
Don’t assume that losing the urge to study after work automatically means you’re failing. If you’re working long hours or constantly staring at similar systems, it’s normal not to want to continue doing cloud projects in your free time. Rest can make you better at your job. Set a small, realistic learning goal during work hours, discuss it with your manager, and protect your evenings instead of turning every hobby into career preparation. If the lack of motivation affects the rest of your life too, then consider whether burnout or a separate personal issue is involved.
I may be overexposed to the same systems and tasks. I don’t feel like doing more cloud work in my free time, and accepting that I need some separation might help.
Networking was definitely what interested me at first. I enjoyed learning about VPCs, CIDR ranges, subnetting, and how container networking works, but I struggle to stay consistent when studying things like autoscaling or canary deployments.