30-60-90 day plan for DevOps engineers
On this page
A DevOps engineer is hired to make other engineers faster and production safer. That makes the first 90 days awkward to plan, because the work touches everything: the build pipeline, the cloud accounts, the infrastructure code, monitoring, secrets and the on-call rotation. A new hire who changes too much too early can take production down. One who spends three months "learning the stack" never becomes the owner of anything.
This 30-60-90 day plan for DevOps engineers is written for the engineering manager or platform lead hiring into an existing team. It gives the new hire a staged path to production access, a written baseline of the delivery system, a place in the on-call rotation and one measurable improvement by day 90. The general structure for any role is in the 30-60-90 day plan template for new hires; if you are hiring someone who will mostly write application code, use the 30-60-90 day plan for software engineers instead.
Decide the access path before day one
The most common stall for a new DevOps engineer is waiting for access. Cloud console roles, the infrastructure repository, CI/CD admin rights, the secrets manager, the paging tool and the monitoring platform are usually owned by different people. Write the access path down before the start date so each step is approved in advance.
| Stage | Example access (example only) | Unlocked when |
|---|---|---|
| Week one | Read-only cloud roles, dashboards, logs, repositories, CI/CD build history, paging tool as observer | Start date |
| Weeks two to four | Write access to development and staging infrastructure through the normal pull request process | First reviewed change merged |
| Weeks five to eight | Production changes through infrastructure as code with peer review; break-glass access documented but not routine | On-call shadow complete and runbooks read |
| Weeks nine to twelve | Primary on-call with the access that requires | Secondary on-call rotation completed |
Tie each step to something the new hire has done, not to a calendar date alone. That keeps the plan honest if they ramp faster or slower than expected, and it gives the security team a clear reason for every grant.
The 30-60-90 day plan
30-60-90 day plan — [Name], DevOps Engineer, [team]
Manager: [name] Onboarding buddy: [name] Start date: [date]
Cloud provider(s): [e.g. AWS / Azure / GCP]
IaC tool: [e.g. Terraform / Pulumi / CloudFormation]
CI/CD: [e.g. GitHub Actions / GitLab CI / Jenkins]
Paging tool: [name] Monitoring: [name]
DAYS 1-30 — Map the system and make reviewed changes
Goals:
- Read the architecture docs, the last [6] incident reviews and
the on-call runbooks; note every runbook that is out of date
- Build an inventory of environments, accounts, clusters and
pipelines owned by the team, with an owner for each
- Compare deployed infrastructure with the IaC repository and
list any drift or hand-built resources found
- Merge [3-5] small, reviewed changes, e.g. a pipeline cache fix,
a missing alert, a dependency upgrade in a shared module
- Shadow at least one full on-call week
Deliverables by day 30:
- Infrastructure inventory and drift list
- A delivery baseline: build time, deploy frequency, change lead
time, failed deploys and recovery time, from the last [90] days
Check-in: day 30
DAYS 31-60 — Take a share of the operational load
Goals:
- Serve as secondary on-call for one rotation
- Own one pipeline or service area end to end (e.g. the build for
[service], or the staging environment)
- Update or write runbooks for the [5] most frequent alerts
- Propose one improvement from the baseline with an expected effect
Deliverables by day 60:
- Revised runbooks reviewed by a senior engineer
- A one-page proposal for the day-90 improvement, with its measure
Check-in: day 60
DAYS 61-90 — Own an outcome
Goals:
- Serve as primary on-call
- Ship the agreed improvement and measure it against the baseline
- Lead one incident review or game day exercise
- Pair with a product team on their deployment pain points
Deliverables by day 90:
- The improvement shipped, with before and after numbers
- A short list of the next three platform problems worth solving
Check-in: day 90 — full review against this planBuilding the delivery baseline
A DevOps engineer cannot show improvement without a starting point, and many teams do not have one written down. Ask the new hire to build it from the systems of record: the CI/CD history, the deployment log, the incident tracker and the paging tool. The DORA research program's metrics guide (checked October 2026) describes delivery measures most teams use, including change lead time, deployment frequency, change fail rate and failed deployment recovery time.
| Measure | Where it usually comes from | What to watch for |
|---|---|---|
| Build and test duration | CI/CD run history | The slowest stages and how often builds are rerun without a code change |
| Deployment frequency and change lead time | Deploy logs and version control | Long waits between merge and deploy, often manual approval steps |
| Failed deployments and recovery time | Incident tracker and rollback history | Whether rollbacks are automated, scripted or done by hand |
| Alert volume and noise | Paging tool | Alerts that fire often and are closed without action |
| Cloud cost for the team's area | Cloud billing reports | Idle environments, oversized instances, untagged resources |
The point at day 30 is an accurate picture with sources, not a target. Numbers will differ widely between teams, and there is no universal "good" value to hold a new hire to. What you are checking is whether they found the data, explained what drives it and spotted where it is unreliable.
What "on track" looks like
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Inventory and drift list written; several reviewed changes merged; baseline with sources; on-call shadow done | Still waiting on access with no escalation; changes made by hand in the console; no written output |
| Day 60 | Secondary on-call completed with sensible escalations; runbooks updated; one area clearly owned | Rewriting large parts of the platform without agreement; avoiding pages |
| Day 90 | Improvement shipped and measured; primary on-call handled calmly; incident review led well | Improvement not measured, or measured only by "it feels faster" |
A filled example
Engineer: Marcus Lindqvist (invented), DevOps engineer joining a four-person platform team at a 300-person software company running on one cloud provider.
Day 30: Found that the staging cluster had been resized by hand twice and no longer matched the infrastructure code. Merged four small changes, including caching dependencies in the main build. His baseline showed the main build taking about 25 minutes, with roughly one in five runs retried without a code change (example figures for this invented team).
Day 60: Completed a secondary on-call week and rewrote runbooks for the five noisiest alerts, deleting two alerts that nobody acted on. Proposed splitting the integration tests so they run in parallel, with build time and retry rate as the measures.
Day 90: Shipped the test split. Build time fell to about 14 minutes over the following three weeks and retries dropped after he quarantined two flaky tests with the QA team. Led the review of a failed deploy and added an automated rollback step for that service.
On-call: staged, not thrown in
On-call is where a DevOps engineer learns the system fastest and where a bad start does the most damage. Stage it: shadow, then secondary, then primary. During the shadow week, the new hire should read every alert as it fires, follow the runbook alongside the responder and write down where the runbook was wrong or missing. Those notes are the raw material for the day-60 runbook work, and they tell you how carefully the new hire reads a system they did not build.
If the team's runbooks are thin, say so in the plan and move fixing them ahead of primary on-call. Putting a new engineer on primary with poor runbooks tests the documentation, not the engineer.
What the manager owes the new DevOps engineer
- The access path, approved in advance, with a named person for each system.
- An onboarding buddy who reviews their first infrastructure changes and sits with them during the shadow on-call week.
- The history: recent incident reviews, known fragile systems, open security findings and any migration that is half finished.
- Protection from ticket overload. Platform teams attract requests. Agree a cap on ad hoc tickets in the first 60 days so the improvement work gets done.
Mistakes that stall a new DevOps engineer
| Mistake | Result | Fix |
|---|---|---|
| Full admin access on day one | A well-meant console change causes drift or an outage | Staged access tied to reviewed changes |
| No access for weeks | The new hire reads documentation and loses momentum | Request every week-one grant before the start date |
| The new hire becomes the ticket desk | Busy for 90 days, owns nothing | One owned area and a protected improvement project |
| Rewrite before understanding | A new pipeline or tool nobody else can support | Require a baseline and a written proposal before large changes |
| Improvement with no measure | No way to tell if the work helped | Agree the measure in the day-60 proposal |
Adapting the plan
- Site reliability roles: weight the baseline toward service level objectives, error budgets and incident trends, and make the day-90 outcome a reliability improvement rather than a pipeline one.
- Senior or staff hires: add a day-60 goal to review another engineer's infrastructure changes and a day-90 written proposal for a larger platform direction.
- Single DevOps engineer at a small company: there is no buddy or rotation to join. Replace the on-call stages with a written incident process, and ask an outside reviewer or the engineering lead to review production changes in the first month. The 30-60-90 day plan for IT managers covers inheriting systems with little documentation.
If the seat is still open, the DevOps engineer screening questions test for the habits this plan relies on, such as reviewing infrastructure changes and writing runbooks, and the 30-60-90 day plan for QA engineers is a useful companion when flaky tests are part of the delivery problem.
Questions people ask
Should a new DevOps engineer get production access in week one?
They should get read access to production systems, dashboards and logs in week one so they can learn how things actually run. Write access to production infrastructure is better granted in steps, after they have made reviewed changes in a lower environment and shadowed an on-call shift, so the first change they make to production is planned rather than urgent.
When should a new DevOps engineer join the on-call rotation?
Usually as a shadow in the first month, as secondary responder in the second, and as primary in the third, once they have worked through the runbooks for the most frequent alerts. The exact timing depends on how good the runbooks are; with weak runbooks, put fixing them ahead of the rotation.
What metrics should a DevOps engineer's plan track?
Measures of the delivery system they will work on, such as deployment frequency, change lead time, change fail rate and recovery time from failed deployments, plus build duration, alert volume and cloud cost for their area. The new hire should build the baseline in the first month rather than be held to a target number on day one.
How is this different from a plan for a software engineer?
A software engineer's plan is built around shipping features in a codebase. A DevOps engineer's plan is built around the systems every other engineer depends on: the pipelines, infrastructure, monitoring and on-call process. Their ramp is measured by whether those systems become faster, safer and easier to operate, not by feature output.