The First 90 Days: A Step-by-Step Playbook for DevOps Engineers

Hey, new hire. I heard about you! 

You learned Kubernetes inside and out, automated everything that could possibly be automated, and managed pipelines. You studied CI/CD strategies, IaC tools, and YAML quirks like your life depended on it.

Congrats, you got the DevOps Engineer job!

They handed you access to the cloud console, the build pipeline, and possibly—horrifyingly—root on prod (no pressure).

Most DevOps onboarding is a brittle cocktail of “read this random doc from 2021,” “ask around,” and “don’t touch that script, we think it still does something.” 

The role is rarely well-defined, and expectations are stupid high while documentation is low. Also… some deployments feel like they might awaken an ancient curse.

While the interview may have been about tools, your first 90 days are all about people, processes, and priorities. This is where you earn credibility, uncover the undocumented, and lay the foundation for the infrastructure your team can rely on.

This playbook won’t fix your team’s infrastructure overnight. But it will help you avoid looking like the one who broke it.

Voices From the Field

“The most important lesson I’ve learned is how quickly you need to understand your customers—meaning developers—and their preferences. At Pixar, I once set up a CI system that no one used until I added email alerts. Turns out, that’s how they liked to be notified. At another company, we drove test adoption by gamifying it with live office leaderboards. Culture isn’t just a background detail—it’s the real delivery pipeline.” -Tara Hernandez, VP of Developer Productivity at MongoDB

The Role: DevOps vs. Platform vs. SRE

Let’s start with the eternal disclaimer: “DevOps is a culture, not a job title.” Sure, Jan – but the job title still exists. And in practice, that often means a hybrid of automation specialist, systems architect, SRE, and internal tooling expert.

You’re supposed to be an enabler, a multiplier, a delivery velocity champion. But the truth is, you’ll be the person people come to when:

• The build breaks, and no one knows why.
• Someone needs a new staging environment right now.
• A compliance audit is due, and secrets are floating in plaintext.
• “We should really automate that” becomes “Can you automate that?”

Platform Engineering is DevOps with better branding.
SRE is DevOps with an SLA.

Whatever they call it, your job is to make things scale, stay up, and not suck.

The First 30 Days: Don’t Touch Anything (Yet)

Tip #1: Map the infrastructure, not just the architecture 

Learn what you’re responsible for: cloud providers, CI/CD pipelines, container orchestration, secret management, and incident workflows. Create your own “infra map” to visualize the stack. Bonus points if you link to live dashboards or scripts.

A WEEKLY 5 MINUTE READ

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Your email*

By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

Name

This field is for validation purposes and should be left unchanged.

Tip #2: Find the blast radius

Every DevOps org has a “please don’t touch that” setup. Inventory everything that could explode if touched incorrectly. This includes:

• Deploy scripts that SSH into prod (why… whyyy?)
• Jenkins jobs last modified in 2019
• Manual runbooks stored in a PDF
• Terraform files that were never actually applied

Ask: What’s undocumented but critical? Who owns it? And what’s the rollback plan if it fails?

Tip #3: Sit in on a deploy—or better, shadow one live 

You’ll learn more from a single deploy (and its hiccups) than from hours of docs. What steps are manual? What’s flaky? What’s tribal knowledge vs. codified? You’re not here to drop genius ideas yet. You’re here to collect dirt.

You should be able to trace a commit from merge to production blindfolded. Understand:

• The CI/CD pipeline (where it breaks, where it bottlenecks)
• Secrets management (please don’t be in env vars)
• Approval flows (are we YOLO deploying from Slack?)

Don’t ship code. Just watch the plumbing and write stuff down.

Voices from the Field

“Good onboarding doesn’t always come with good documentation. Sometimes the only way through chaos is curiosity and persistence. When I joined a team and got handed a complex launch with no docs, I reverse-engineered the entire flow. That experience taught me: if the documentation is missing, you become the documentation.” –Anant Agarwal, CTO at Aidora

The First 60 Days: Identify Risks, Reduce Friction

Tip #4: Ship a 5-minute win

Look for high-friction, low-risk tasks you can script or templatize. These “1%” improvements make your life easier and build team goodwill. Just find one thing that takes 5 minutes too long and make it faster:

• Shell wrapper for local dev setup
• A CLI helper 
• A reusable Terraform module
• Script to nuke stuck test environments
• Slack notification for failing builds

Small wins build trust. Trust gets you leeway to make big changes.

Tip #5: Audit the CI/CD pipeline with extreme prejudice

Look at build times. Look at test coverage. Look at what breaks daily. Ask questions like:

• Can we parallelize tests?
• Could this have been prevented earlier in CI?
• Are we caching dependencies?
• Are we deploying on merge… or on a wing and a prayer?

You’re not here to point fingers. You’re here to make flow frictionless.

Voices from the Field

“On a recent high-traffic app takeover, there was zero documentation—we had to figure everything out by trial and error, fast. My advice? Use AI aggressively. From log analysis to reverse-engineering APIs, AI helped us onboard and stabilize faster than we ever could alone. It turns routine drudgery into real progress.” –Denis Tiumentsev, Lead DevOps Engineer at Integro Technologies

Tip #6: Create dashboards people actually use and clarify ownership 

 Grafana, Prometheus, Datadog—it doesn’t matter. What matters:

• Can your team see deploy success rate?
• Do alerts mean anything, or are they noise?

Is someone watching error rates before users complain? Who owns the build pipeline? The Helm charts? The DNS configs? Ownership boundaries are rarely clear. Make a list of gray areas and clarify them with your team. This prevents finger-pointing later.

You own visibility now. Make it count.

The First 90 Days: Build Trust Through Reliability

Tip #7: Ship something that increases stability 

This could be:

• Adding alerting to an under-monitored system
• Improving test coverage in pre-prod
• Reducing flake in CI pipelines
• Refactoring a bash script that was one rm -rf away from disaster

It doesn’t have to be huge. It has to make your team breathe easier.

Voices from the Field

“One of the first wins in a new DevOps role was implementing a centralized CI/CD pipeline with automated rollback and GitOps workflows. Before that, the team relied on fragmented scripts and manual hacks. This reduced deployment times by over 50% and shifted us from firefighting to proactive reliability. The credibility that came from that rollout made a huge difference.” –Divya Parashar, Senior Staff Engineer

Tip #8: Write a “DevEx” feedback memo

Gather anonymous or informal feedback from developers about where infrastructure slows them down. Present your learnings and suggest experiments (e.g., faster local dev, ephemeral environments, better logging).

Write a doc titled “Here’s what I learned and what I’m doing next.” This is a roadmap (and maybe a brag sheet ;). Share it with your manager and team.

Create a “Don’t Let Me Forget This” list:

• The weird quirks you uncovered
• The shadow infra no one admits to owning
• The tribal knowledge only Carl from IT seems to know

Convert that list into documents, automation, or tickets—or keep it handy. This shows leadership you’re building fireproof systems.

Voices from the Field

“Focus on the outcomes you can control today. Ground yourself in why your work matters to customers—that perspective shift makes all the difference during the first 90 days.” –Rukmini Reddy, SVP of Engineering at PagerDuty

Tip #9: Pick a single high-impact project and start framing it 

By now, you should have enough signal to identify a major area for improvement. Use the final stretch of your first 90 days to scope it, socialize it, and get alignment.

• Migrate flaky jobs to GitHub Actions
• Replace one snowflake server with infra-as-code
• Build a golden path for devs to create new services

Start small and prove your value. Document everything.

Final Word

Hopefully, within your first 90 days, you can stabilize things, get shit deployed, and, most importantly, keep the engineers from screaming into the void.

Those early days are all about building traction for the long haul. Find the cracks and document like a maniac! 

Voices from the Field

“You don’t have to prove yourself in one day. Breathe. Focus on stability first, speed second. Ask dumb questions early—they only get harder to ask later. And remember: a boring system that works is better than a flashy one that breaks.” –Pablo Gerboles, CEO at Alive DevOps

Not your first tech rodeo?

This DevOps playbook is part of a growing series for new hires who want to make an impact before someone hands them “legacy ownership.”

👉 Just getting started in a Security Engineer role? We’ve got you covered:
The First 90 Days: Cybersecurity Edition

👉 More into code commits than root access? Check out:
The First 90 Days: Software Engineer Edition

And yep—we’ve got more roles coming soon. Stay tuned, or better yet, subscribe to the newsletter so you don’t miss the next one.