12 Questions to Ask Before You Hire a DevOps Partner

Somewhere between "our releases are a nightmare" and signing something monthly, there's a call with a provider. Most of that call is them talking. This is the list of questions we'd want you to bring to it instead — including when the provider on the other end is us.

Let's name the conflict of interest first: Managed DevOps is one of the things we sell, so a post about how to interrogate DevOps providers is not a neutral document. Read it as the list we'd hand a friend, and use it on us. It's published precisely because we can answer all twelve, and because the questions that separate a good provider from a bad one are not the ones most buyers currently ask.

Twelve questions, in four groups: what you're actually buying, how you'd leave, who you'd be working with, and how to judge the answers.

What you're actually buying

1. What exactly do you take responsibility for — and what stays ours?

The word "managed" carries almost no information. Ask for the boundary in writing, item by item: the release process, the environments, the monitoring, the cloud accounts, the databases, the third-party services, the working process on top. Then ask the mirror question — what's still your team's job? A provider who can't draw that line before the engagement starts will be drawing it during your first incident, which is the worst possible time to discover you disagree.

2. What does a normal month look like when nothing is on fire?

Bad answers are abstract ("continuous improvement", "proactive monitoring"). Good answers are boring and specific: releases go out on this cadence, this is the report you get, this is the board you can look at any day of the week, this is who you talk to and how often. You're buying a rhythm. Ask them to describe it as a calendar, not as a capability.

3. What are the first thirty days?

The honest answer is never "everything." Systems get taken over in an order, and the order tells you how a provider thinks — whether they start with the thing that hurts you most, or with a three-month tooling project that produces nothing you can feel. Ask what they'd touch first and why that one. Then ask what they'd deliberately leave alone for now. Providers who won't leave anything alone are selling a rebuild wearing a service's clothes.

How you'd leave

These three matter more than anything above, and they're the ones buyers skip because asking about the exit feels rude on a sales call. It isn't. It's the whole ballgame.

4. How would we take this back in-house?

Ask it exactly like that, and expect a written answer. The point of buying the function instead of hiring it is to stop concentrating "how everything runs" in one head — but a managed setup that lives in the provider's head hasn't fixed that, it has just moved the head outside your company where you have even less visibility into it. The only real defence is documentation produced as a byproduct of the work rather than promised for later. So: what would you actually hand us, on what day, and can we see an example of it?

5. What's the notice period, and why is it that length?

Both extremes should make you curious. A very long lock-in with no explanation is a provider protecting revenue. A "cancel anytime" with no handover plan sounds generous until the week you use it and find out nobody can safely take over from a standing start. Ask for the reasoning, not just the number. (Ours is 90 days, and the reason is the handover: three months is roughly what an orderly transfer of access, documentation, and context takes, so leaving is a process rather than a cliff.)

6. Whose name is on the accounts?

Cloud accounts, source code repositories, domain registrations, monitoring tools, CI systems. Every one of them should be owned by your company with the provider invited into it — not the reverse. A provider running your production inside their own cloud account, under their own billing, with your code in their organisation is the most common form of lock-in in this industry, and it's usually presented as a convenience. It is a convenience. It's also a hostage situation you agreed to in advance.

Who you'd be working with

7. Who does the work, and will they be the same people in six months?

You are buying continuity — that's the main thing that distinguishes a monthly engagement from a project. Ask who specifically will know your system, how many of them there will be (one is a risk, and it's the same risk you were trying to solve), and what happens when one of them leaves the provider.

8. When something breaks at 3 a.m., what have you actually promised?

Push for precision here, because this is where the gap between marketing and contract is widest. "We monitor around the clock" usually means automated monitoring and alerting run continuously — which is genuinely valuable and is not the same as a human being awake. Ask them to separate the two in writing: what's automated, what a person responds to, within what window, and on which days. Then decide what you actually need. Plenty of businesses genuinely don't need someone awake at 3 a.m.; the problem is only ever finding that out afterwards.

9. Can you work with the engineers we already have?

If you have a team, the answer shapes everything. Some providers are built to take over a function wholesale and get awkward when there are incumbents; some can set the standards and rhythm and let your people work inside them. Neither is wrong, but a mismatch here turns into political friction in month two. Ask what the split looks like in practice: who decides, who reviews, who's accountable when a release goes wrong.

How to judge the answers

10. Show us something you've written.

A documentation page, a monthly report, a review write-up — with client details removed. This is the single most useful artefact you can ask for, because the job you're buying is substantially a writing job: if they can't explain a system clearly to you, they can't explain it clearly to your team either, and the documentation promise from question 4 quietly evaporates. Vague, jargon-heavy writing is not a style preference. It's a preview.

11. Tell us about an engagement that went badly.

Everyone with real experience has one. The answer you want has a specific mistake in it and something that changed as a result. The answer that should worry you is a client-blaming story, or a claim that it's never happened — that means either no experience or no reflection, and you'll be paying to be the exception.

12. What would you tell us to do if we don't hire you?

The best providers have an answer, because they know what your situation needs independently of who supplies it. A provider whose only answer is "hire us" hasn't diagnosed anything — they've matched you to their product. Sometimes the honest answer genuinely is "you're one hire away from fine", and a provider willing to say so is telling you something reliable about how they'll behave once your money is involved. (We wrote the long version of that trade-off in you don't need a full-time DevOps hire — yet, including the cases where hiring is the right call.)

Red flags, condensed

• Pricing offered before anyone has looked at how you ship today (more pricing-specific flags in what DevOps as a service costs)
• No written scope boundary — "we handle everything" as an answer to question 1
• Your production running in their cloud account, their repositories, their tool licences
• Documentation described as a future phase rather than a byproduct
• Only one person who will know your system
• "Around the clock" in the marketing, nothing about response in the contract
• A recommendation to rebuild before anyone has read the existing system
• Discomfort with question 4

The cheap way to test all twelve at once

Don't try to resolve twelve questions on a call — talk is free and everyone sounds competent for an hour. Ask for something small, written, and real before money moves, and judge the questions against the artefact instead of the answers.

That's the entire reason our free DevOps review exists and is written rather than presented: we map how your software ships today — every manual step, every single point of failure, everything your team does by hand that machinery should do — and write up the plan we'd run. Yours to keep, including if you hand it to your own team, or to a competitor of ours, and never speak to us again. It answers questions 2, 3, 10 and 12 as a document you can re-read when we're not in the room, which is the only condition under which anyone evaluates a provider clearly.

Whoever you end up hiring: ask question 4 first, and get the answer in writing.