Hire DevOps Engineers: A Ninety Day Plan You Can Measure

Updated November 2026 · Written and maintained by the Progression Agency strategy team

If your release steps live in one person’s notes and a Friday deploy can take an afternoon, the problem has a name and five numbers attached. DORA measures software delivery by change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. When you hire DevOps engineers, take those five readings before they start and again after ninety days, and you will know whether the hire worked. Progression’s team is based in New York and places DevOps engineers with US companies, working remotely and on site when a release needs hands in the room.

A release that lives in one person’s notes

A hypothetical product team deploys from a list of steps in a chat thread. One engineer runs the list by hand, and releases wait for the days that engineer is in. Nothing is broken, and nothing is safe.

A DevOps hire turns that list into a pipeline anyone on the team can run, with a rollback step beside it. The five metrics below say whether that happened.

Why is a manual release a risk?

Because it depends on memory. One missed step, one absent engineer or one new hire who has not seen the list, and the release stalls or breaks.

Hire DevOps engineers against DORA’s five metrics

DORA has identified five software delivery performance metrics, evolved from the original four keys. Three measure throughput and two measure instability, and together they give a business a plain way to judge whether a hire is working.

• Change lead time: from a change committed to version control to deployed in production.
• Deployment frequency: the number of deployments in a period, or the time between them.
• Failed deployment recovery time: how long it takes to recover from a deployment that fails and needs immediate intervention.
• Change fail rate: the ratio of deployments that need immediate intervention, likely a rollback or a hotfix.
• Deployment rework rate: the ratio of deployments that are unplanned and happen because of a production incident.

The plain advice: measure one application at a time, as DORA advises, and never set a metric as a target the engineer is paid on. DORA also notes that speed and stability are not tradeoffs for most teams, so the hire is not asked to choose between them.

Why one application at a time?

Context differs between applications, and blending the numbers across very different services makes them misleading. Pick the service that hurts most and measure that.

The ninety day scorecard

Each metric gets a baseline before the engineer starts, a first change in the first weeks, and a reading at day ninety. No target values appear in the table, because the right target depends on the application.

Days 1 to 30: read the pipeline and the incidents

The engineer reads how releases actually go and reads the last incidents. The deliverable is a short list of causes in order of cost, and the baseline readings for all five metrics.

Days 31 to 60: automate the release

The first automation goes where the most time is lost. Usually that is the manual deploy, followed by a rollback step and the checks that stop a bad build before it ships.

Days 61 to 90: make recovery boring

Alerts, runbooks and a tested rollback mean a failed deployment is a routine event with a known fix. Day ninety is when the five readings are taken again and compared with day one.

• Take the baseline in writing before the first day.
• Review the readings with the engineer at day thirty, sixty and ninety.
• Compare the same application at each reading.
• Treat a rising number as a question, not an accusation.

DevOps engineer, developer or SRE?

The difference between developer and DevOps engineer is ownership. A developer writes features. A DevOps engineer owns the path from commit to production and the tooling around it. A site reliability engineer owns production reliability targets.

Small teams often have one person covering two of these. A team that needs all three as a service can look at DevOps services.

Can a developer do the DevOps work?

For a while, yes, and many do. The cost is that feature work slows down whenever the pipeline needs attention.

Hire DevOps developers for the pipeline you already have

Tool families matter more than brand names: continuous integration systems, infrastructure as code, containers and observability. The plain advice is to hire for the tools already in place unless a migration is planned. A new engineer who already knows the stack saves months.

If you hire a DevOps developer to replace a tool, the first quarter goes to the migration and not to improvement, and the five readings will show it.

Hire Azure DevOps engineers for Microsoft shops

Teams that run Azure Pipelines and Azure Repos want engineers who already work in them. The same measurement applies. See Azure app development for the wider Azure picture.

An AWS DevOps engineer shares account access rules

An engineer working in an AWS account follows the same sign in, permission and budget terms as any developer there. See hire AWS developers for those terms.

• Name the CI system, the repository host and the cloud in the brief.
• Name the container and orchestration tools if any.
• Name how monitoring and alerting work today.
• Say whether a migration is planned in the first six months.

What DevOps engineers cost to hire

Pricing depends on scope, is subject to change and is set in the written proposal. The going DevOps engineer hourly rate is a published market figure and not a Progression rate card.

• Ask whether the quote is for a fixed scope or a month of time.
• Ask what cloud and tool charges sit outside the fee.
• Ask what happens to the fee when the backlog is thin.
• Ask for the ninety day scorecard in the proposal.

On call, handover and the second engineer

A single DevOps engineer is a new single point of failure unless runbooks and access are shared from week one. On call terms are agreed in writing before the work starts, including who answers and when.

• Runbooks live in a place the whole team can edit.
• Access is granted to roles, not to one person’s account.
• A second person can run every release step.
• On call hours and handoffs are written into the engagement.

For engagement models that add a larger team, see software development outsourcing.

What if the engineer is away?

Then the pipeline and the runbooks still work, because they were built to be run by others. That is part of what the ninety day scorecard checks.

Mistakes DORA warns against

DORA lists pitfalls for teams adopting its metrics, and a business that has just hired is exposed to each of them.

What if the numbers get worse after the hire?

A baseline that was guessed can look better than the truth. Real measurement often exposes problems that were always there.

A work sample worth paying for

Before a longer engagement, pay for a small task on a copy of one service. A good example is turning a manual deploy into a pipeline with a rollback step.

• The pipeline runs from a clean checkout with no hidden steps.
• A rollback step exists and has been tried.
• The README says how to run it in plain words.
• Someone else on the team can run it and get the same result.

A strong result is boring. It is short, readable and runs the same way twice. Elaborate tooling for a simple service is a warning sign.

How big should the sample be?

A day or two of work on one service, not the whole system.

Questions to settle before day one

Five questions, each with one owner, remove most of the early friction. They cost an hour to answer and save weeks.

• Who grants production access, and through which role?
• Which application is measured first?
• Where do runbooks live, and who can edit them?
• How are incidents reported and shared?
• Who approves infrastructure changes?

Who should answer them?

Whoever owns the application on your side, with the engineer asking the questions in the first week.

Measuring without building a dashboard

DORA cautions against focusing on measurement at the expense of improvement. The data is available in several places already, and building integrations to get precise numbers may not be worth the first investment.

Starting with conversations, DORA’s Quick Check or a product that comes with pre-built integrations is often enough for the ninety day plan. A hand count of ten changes gives a baseline that is good enough to compare with itself.

• Count a sample by hand for the baseline.
• Automate the measurement only after the first change ships.
• Keep the method the same at every reading.
• Write down any change to how you count.

Is a hand count credible?

Yes, if it uses the same method each time. The comparison with your own past is what matters.

Where the engineer’s work stops

A DevOps hire improves delivery, and that is a bounded job. Some work belongs elsewhere, and saying so at the start avoids disappointment.

For adding developers across other stacks, see hire dedicated developers.

Does the engineer fix application bugs?

Only those that come from the pipeline, the environment or the deployment. Application bugs go to the developers.

Frequently asked questions