DevOps Engineer First 90 Days at a New Job — What to Actually Do (2026)

Most DevOps engineers spend their first 90 days either lost or trying to prove themselves too fast. Neither works. Here's the plan that actually builds long-term credibility.

---

Days 1–30: Listen, Don't Fix

Your first instinct will be to fix things. Suppress it.

What to do in the first 30 days:

Understand the infrastructure:

• Map out every service and how they connect
• Read every runbook, even outdated ones
• Understand what breaks most often (ask the team, don't wait for it to happen to you)
• Shadow at least 2–3 on-call incidents even if you're not on rotation yet

Understand the team:

• Who owns what? Who's the go-to for Kubernetes vs AWS vs CI/CD?
• What are the unwritten rules? (deploy freezes, who reviews what, what needs approval)
• What does the team hate doing? (this is where you'll add the most value)

Understand the business:

• What does the company actually make money from?
• What's the most critical service? What's the SLA?
• What happened in the last 3 major incidents?

Don't do this:

• Don't refactor things in your first week
• Don't suggest "we should migrate everything to X" before you understand Y
• Don't merge anything you don't fully understand

---

Days 31–60: Ship Small, Visible Wins

Now you understand the system. Time to contribute — but deliberately.

Pick one pain point the team has mentioned repeatedly and fix it. Not the biggest problem, the most complained-about one. Small and visible beats big and invisible.

Good first-month wins:

• Automate a manual runbook step that everyone hates
• Fix a flaky CI/CD pipeline that blocks developers
• Add a missing alert for a known failure mode
• Document a process that exists only in someone's head
• Reduce a build time by 30%

Why these? Everyone notices them. They're scoped enough to ship in 1–2 weeks. They don't require you to understand the entire system.

How to communicate your work: Don't just merge a PR and move on. Write a brief Slack message: "Fixed the flaky Docker build step — it was retrying 3x and timing out. Cut avg build time from 12min to 4min." People remember this.

---

Days 61–90: Own Something

By day 60, you should know enough to take on real ownership.

What ownership looks like:

• Be the person others go to for one specific thing (monitoring, Terraform, CI/CD)
• Join the on-call rotation and handle incidents without escalating for common issues
• Drive a meaningful project from design to deploy (not just executing tickets)

How to pick what to own: Look for the area that's either underinvested or aligns with where the team is headed. If observability is a mess and the team just got a new service, volunteer to lead the Prometheus/Grafana setup for it.

Start writing design docs: Even short ones. "Here's the problem, here's what I propose, here are the tradeoffs." This is how senior engineers operate and it signals you're ready for more responsibility.

---

Things That Kill Credibility Fast

Pushing to production without telling anyone — even if you have access, communicate changes.

Saying "that's not how we did it at my last company" — it's fine to share context, but constant comparisons signal you haven't adapted.

Asking the same question twice — write things down. Keep a personal runbook from day 1.

Being unreachable during incidents — even if you're new, acknowledge pages promptly. "I'm looking into it" buys you 10 minutes.

Over-promising timelines — "I'll have it done by Friday" and then not having it done destroys trust fast.

---

One Thing That Separates Good DevOps Engineers

They make other engineers' lives easier.

Your job isn't just to keep infrastructure running. It's to make the developers who ship features go faster and sleep better. The DevOps engineers who advance fast are the ones the dev team thinks of as partners, not gatekeepers.

Ask developers regularly: "What's slowing you down?" Then fix one of those things.

---

90-Day Checklist

Days 1–30:

• Read all runbooks
• Mapped all services and dependencies
• Shadowed at least 2 incidents
• Know who owns what
• Set up your local dev environment fully

Days 31–60:

• Shipped at least one visible improvement
• PR merged with full understanding of what it does
• Know the deployment process for 3+ services
• Have at least one 1:1 with your manager about expectations

Days 61–90:

• On the on-call rotation
• Have ownership of one area
• Drove one project from start to finish
• Known by developers for helping them ship faster