This guide is for the person who signs: a CTO, a VP of Engineering, a founder who has been carrying the pager alone. It is deliberately general to DevOps work — pipelines, infrastructure as code, Kubernetes platforms, cloud cost — and sits alongside three narrower pages: the SRE consultancy checklist for reliability-specific questions, the best DevOps consulting companies for who is in the market by category, and managed DevOps vs hiring in-house for the build-vs-buy math. It quotes no prices on purpose; for market pricing, see DevOps consulting rates.
Key takeaways
- Decide what you are buying first: an outcome (consultancy), one person’s time (freelancer), seats on your team (staff augmentation) or ongoing operation (managed service). Each puts ownership and scope risk in a different place.
- The people in the sales call should be the people in your repos. Ask for names before you sign, then check that those names show up.
- A good firm starts read-only and writes things down — findings, plans, change requests and runbooks exist as documents your team keeps.
- Your code, your accounts, your exit: infrastructure code, pipelines and documentation live in your repositories and cloud accounts from day one, and the contract says so.
- Measure what you already care about — DORA delivery metrics, SLOs, cost — agreed and baselined before work starts, not reconstructed at the end.
Consultancy vs freelancer vs staff augmentation vs managed service
Many disappointing engagements start as a category error. A team buys staff augmentation and expects someone else to own the outcome, or buys a consultancy when what it needed was one experienced pair of hands. Name the model first; the questions that follow depend on it.
| Dimension | Consultancy | Freelancer | Staff augmentation | Managed service |
|---|---|---|---|---|
| What you buy | A defined outcome from a team: a scoped project, an assessment or advisory | One person’s time and skills | Engineers who join your backlog and take your direction | Ongoing operation of defined systems against written service levels |
| Who owns outcomes | The firm, against written deliverables and acceptance criteria | You; the individual owns their tasks | You; they deliver what you assign | The provider for what the service covers; you for everything outside it |
| Who carries scope risk | Shared: fixed scope moves estimation risk to the firm, and change requests move it back | Mostly you, especially on open-ended time and materials | You, entirely | The provider inside the defined service; new work is a change |
| Continuity and knowledge retention | A bench covers absences; knowledge stays with you only if transfer is a written deliverable | A single point of failure; knowledge leaves with the person unless it is written down | Individuals rotate; knowledge sits with whoever worked beside them | Continuity is the product; knowledge sits with the provider unless runbooks are handed over |
| When it fits | A bounded problem that needs senior judgement: a CI/CD rebuild, a platform, a migration, a cost or reliability programme | A well-defined task, with someone in-house who can review the work | You have strong technical leadership and need more hands | Production needs round-the-clock cover and the workload does not justify a full in-house rotation |
| Watch-outs | Senior pitch, junior delivery; deliverables that are slides | Availability, holidays, and an individual holding production access | Paying for seats, not results; nobody owns the architecture | Proprietary tooling and weak exit terms that make leaving expensive |
Plenty of firms sell more than one of these, and a single engagement can move between them: a consultancy builds a platform, then runs it as a managed service, then hands it to the team you hired. That is fine as long as the contract says which model you are in at any moment, because ownership, scope risk and exit terms change with it. When hiring beats all four, managed DevOps vs in-house works through the signals.
15 questions to ask a DevOps consulting firm
Ask these in the first technical call, with an engineer from your own team in the room. For each one there is a sketch of what a good answer sounds like. Listen for specifics — names, documents, examples, trade-offs. Confidence without specifics is not an answer.
The team and the first week
- “Who will do the work day to day, and can we meet them before we sign?”
A good answer sounds like… “You’ll work with the engineers on this call. Here is who is senior, how much of their week is yours, and who covers when someone is out. If anyone changes, you hear it from us first, and you can say no.” A weak answer is “we’ll assign the right resources after kickoff”. - “What happens in the first week?”
A good answer sounds like… “Read-only access, conversations with your engineers, and a written findings document at the end of the week: what we saw, what we would change first and why, and what we would leave alone. Nothing changes in production until you have agreed a written plan.” A firm that wants write access on day one is asking you to trust a plan that does not exist yet. - “How will you access our systems, and how do you give that access back?”
A good answer sounds like… “Named individual identities, never shared accounts. Least-privilege roles that you create and can revoke, short-lived credentials, and everything visible in your own audit logs. At the end we give you a list of every access we held, you revoke it, and you rotate any secret we could have seen.” The cloud providers document the same pattern. AWS’s guidance for third-party access is a role you create in your own account, assumed with an external ID, rather than an IAM user with long-term credentials. Azure Lighthouse lets a customer delegate specific scopes and roles to a service provider, audit its actions and remove access completely at any time. On Google Cloud, the basic roles (including the read-only Reader and the legacy Viewer) carry thousands of permissions, so Google advises granting the most limited predefined or custom roles in production instead.
How the work gets done
- “How do you make changes to production?”
A good answer sounds like… “Every change is a pull request your team can review. Infrastructure changes show their plan before they apply. We sequence the work from the most reversible change to the least, and anything risky gets an agreed change window and a rollback step written down in advance.” Console clicks that nobody can review are how drift and mystery outages start. - “What will we have in writing, and when?”
A good answer sounds like… “A statement of work with deliverables and acceptance criteria before we start; the week-one findings; a plan for each milestone; decision records for anything contested; runbooks and architecture documentation as each piece lands; and a short written update every week.” If a deliverable reads “improved DevOps maturity”, ask which document proves it. - “How do you handle scope changes?”
A good answer sounds like… “In writing: what is changing, why, the effect on timeline and cost, and your sign-off before the work begins. We will also tell you when a request is really a new project.” “We’re flexible” without a written change process means scope creeps quietly and the invoice follows it. - “How will we know how it’s going between milestones?”
A good answer sounds like… “A weekly written update: what shipped, what is blocked, the risks, and the decisions we need from you. A demo of working software or infrastructure at every milestone, not slides. Problems raised in the week we find them, not saved for the final report.”
Proof and measurement
- “Can we speak to references and see sample deliverables?”
A good answer sounds like… “Yes. Here are clients with a similar problem who have agreed to talk to you, and here is a redacted findings document, a runbook and a decision record from past work.” Where client names are under NDA, a serious firm still finds a way to show its work: redacted samples, a reference who can speak in confidence, or a short paid discovery whose output becomes the sample. When you call references, ask what went wrong and how the firm handled it; every firm has a good-news story. - “How will we measure success?”
A good answer sounds like… “We agree the measures before we start and baseline them in week one. For delivery, the DORA metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. For reliability, SLOs — in the Google SRE book’s definition, a target value for a service level measured by an SLI. For cost, spend per environment or per unit of what you sell. At the end you see those numbers move, pulled from your own systems.” Weak answers measure activity: hours delivered, tickets closed, a maturity score from the firm’s own framework. - “What would you advise us not to hire you for?”
A good answer sounds like… something specific: “that part of your stack is outside our depth”, “that is a hiring problem, not a consulting one”, or “a managed service would solve that without us”. A firm that is the right answer to every problem you describe has not been listening.
Ownership, operations and the exit
- “How does knowledge transfer actually happen?”
A good answer sounds like… “It is in scope from week one, not a handover sprint at the end. Your engineers review every pull request, we pair on the hard parts, runbooks are written as each system lands, and the last milestone is your team operating it without us — running the runbook themselves while we watch.” Then ask what their last handover looked like, and whether that client still calls them for day-to-day operations. - “Who owns the infrastructure code, pipelines and documentation?”
A good answer sounds like… “You do. Everything we write for you — Terraform or other infrastructure as code, pipeline definitions, scripts, dashboards, runbooks — lives in your repositories and cloud accounts from day one, and the contract assigns it to you. If we bring pre-existing modules, you get a perpetual licence to keep using and changing them.” A firm that keeps your infrastructure code in its own repository “for convenience” is building leverage, not a platform. - “Which tools will we have to adopt, and could we run them without you?”
A good answer sounds like… “We work with what you have and recommend a change only when it pays for its own migration. Anything we introduce is open source or a product you license directly, and you can run it without us.” Proprietary agents, closed modules and “our platform” are lock-in by design, however good they are. - “Who is on call, and what happens during an incident?”
A good answer sounds like… for a project, “during the build we agree who responds to what, and we hand over a rotation your team owns, with runbooks”; for a managed service, “written response and acknowledgement targets, an escalation path, a definition of what counts as an incident and what is excluded, and a written post-incident review”. Ask the simple version too: if their change breaks production tomorrow night, who picks up? - “How does this end?”
A good answer sounds like… “At any milestone boundary, with a handover period defined in the contract, a list of access to revoke, documentation that is current on the last day, and no handover fee that wasn’t agreed at the start. The best outcome is that you stop needing us.” A firm that cannot describe its own exit has not planned for yours.
Red flags when hiring a DevOps consultancy
Any one of these is worth a direct question. Two or three together usually mean you are talking to a staffing business dressed as a consultancy.
- Open-ended time and materials with no written scope. You carry all of the estimation risk and have nothing to hold the firm to.
- No read-only start. Admin credentials requested in week one, before anyone has written down what they found or what they plan to change.
- Proprietary tooling you can’t keep. An agent, a module library or a “platform” that stops working, or stops being licensed to you, when the engagement ends.
- No written deliverables. Outcomes described as “improved posture” or “best practices applied”, with no document, repository or metric that proves them.
- Junior staffing after a senior pitch. The architect on the sales call disappears after kickoff, and nobody can say how much of their week is yours.
- Refusing references or samples. Confidentiality explains redaction, not an absence of any evidence at all.
- Shared or long-lived credentials. A request for a shared admin user or static access keys, instead of named identities and roles you control.
- A solution before discovery. Kubernetes, a service mesh or a new CI platform recommended before anyone has looked at your workload.
- No exit clause. Termination terms that are vague, or a handover that is priced as a separate project nobody mentioned at the start.
How to run a 2–3 week evaluation
You don’t need a months-long procurement process to choose well, and you shouldn’t decide from a single call either. Two to three weeks is enough for most teams if the steps are fixed in advance.
- Before you start: write a one-page brief. The problem in your words, what done looks like, the constraints (compliance, change freezes, systems nobody may touch), who on your side owns the result afterwards, and the decision date. Send the same brief to every firm so the answers are comparable.
- Week 1: shortlist and technical calls. Three firms is usually enough; the category guide to DevOps consulting companies helps you pick firms that match the size of your problem. Run a technical call with each using the fifteen questions above, with one of your engineers present, and ask each firm for sample deliverables and references.
- Week 2: discovery and references. Take the strongest one or two into a short, scoped discovery on read-only access, paid if necessary. A few days of real work on your real system tells you more than any proposal. Call the references in the same week, and ask about the handover, not only the delivery.
- Week 3: proposal, contract, decision. Compare the written proposals against the contract must-haves below. Let the engineers who will work with the firm score the discovery output. Decide on the date you set, and tell the firms you didn’t choose why.
| Criterion | Evidence to ask for | When you get it |
|---|---|---|
| Seniority | The names and backgrounds of the engineers who will deliver, and how much of their week is yours | Technical call and proposal |
| Approach | A written findings document about your own system | Discovery, week 2 |
| Documentation quality | A redacted runbook and a decision record from past work | Sample request, week 1 |
| Delivery record | Reference conversations about similar problems, including what went wrong | Week 2 |
| Commercial clarity | A draft statement of work with scope, change process, acceptance criteria and exit terms | Week 3 |
| Team fit | Your engineers’ view after reviewing the discovery output with the firm | Weeks 2–3 |
Contract must-haves
Whatever the model, these belong in the signed documents, not the sales deck. Have your own counsel review the wording: how intellectual property assignment, liability and termination work varies by jurisdiction, and this is a checklist, not legal advice.
| Clause | What it should say |
|---|---|
| Intellectual property | Work product made for you — infrastructure code, pipelines, scripts, dashboards, documentation — is assigned to you. Pre-existing components the firm brings are licensed to you perpetually, with the right to modify them. |
| Where the work lives | Your repositories and cloud accounts from day one. Nothing needed to run, rebuild or change your systems lives only in the firm’s systems. |
| Access and offboarding | Named individual access, least privilege, logged in your systems; an access register kept current; at the end, all access revoked and exposed secrets rotated, confirmed in writing. |
| Knowledge-transfer deliverables | Named artefacts — runbooks, architecture documentation, decision records, pairing sessions, a handover session — accepted when your engineers can operate the system without the firm. |
| Exit and handover | Termination at milestone boundaries, a defined handover period and scope, return or deletion of your data, and no handover fees beyond those agreed at signature. |
| Scope and change control | Changes requested and approved in writing, with the effect on timeline and cost stated before work begins. |
| Acceptance criteria | Testable criteria for each milestone, so “done” is something you can check rather than negotiate. |
| Confidentiality | An NDA signed before any access is granted, covering how your data and credentials are handled. |
| Incident responsibilities | For managed services: response and acknowledgement targets, escalation paths, what is excluded, and how incidents are reported. |
When you do not need a DevOps consultancy
Sometimes the honest answer is a different purchase, or none at all.
- The work is a well-defined task and you can review it. One pipeline to migrate, one module to write: a freelancer or your own engineers will do, at far less overhead.
- You have strong technical leadership and only need capacity. That is staff augmentation or hiring. A consultancy’s value is judgement and ownership; don’t pay for either if you already have them.
- Infrastructure is your product, or a permanent full-time workload. Build the team in-house; use outside help only to bootstrap or audit. Managed DevOps vs in-house covers when that line is crossed.
- A product would solve it. A managed Kubernetes service, a hosted CI system or your cloud provider’s own cost tooling may remove the problem rather than staff it. Managed vs self-hosted Kubernetes is one example of that decision.
- Nobody will own the result afterwards. A project consultancy that builds something your team cannot run leaves you with an orphan. Either plan the ownership first or choose a managed service.
- You can’t yet say what done looks like. Write the brief first. Without it, any firm will happily sell you an open-ended engagement.
How InfraZen answers these questions
Since we asked you to judge us by the same criteria, here is where we stand. Week one of every engagement is read-only by policy. Work ships as pull requests your team reviews, so knowledge transfers as we go rather than in a rushed handover on the last day. Runbooks, architecture docs and pairing sessions are deliverables, not extras. Everything we build lives in your accounts and repos from day one. We are vendor-agnostic by design, and there is an NDA from day one. Managed engagements carry 24×7 on-call with a 15-minute acknowledgement SLA.
Where we are weaker, same standard as everyone else: we are a boutique, a deliberately small bench rather than a large programme team, and our case studies are representative engagements, anonymised because client names are under NDA. Ask us how we would meet the references and samples question anyway. Many of our clients reduce or end engagements once their in-house team owns the work, and we consider that a successful outcome.
Related: How to choose an SRE consultancy · Best DevOps consulting companies · Managed DevOps vs in-house · DevOps consulting rates · DevOps consulting services · What is DevOps? · DevOps vs SRE vs platform engineering