DevOps Consulting Companies: Who Actually Shows Up on Your Account?

Every shortlist of DevOps consulting companies looks the same by the third browser tab. The same services grid, the same AWS partner badge, the same promise of round-the-clock coverage. Ask for day rates and they land within fifteen percent of each other.

What decides how the next year goes is on none of those pages. It is which humans end up in your account, whose payroll they sit on, and what happens the week one of them leaves. Two firms at the same rate can mean one engineer who knows your settlement flow by heart, or a rotating pool who each meet your architecture for the first time at 2am.

So the question for every firm on the list is not what they do. It is who turns up, and what the contract says when that person changes.

Why do DevOps consulting companies all read the same?

Because the comparable parts are the cheap ones to state: a partner tier, a certification count, a logo, a tool list. And what the partner badge actually proves is less than the page implies. What separates two DevOps consulting firms once the work starts is who gets assigned, who they sub-contract and what a handover looks like, and none of that reaches a proposal unless you ask.

Are you buying named engineers or a share of a bench?

Both are real products and they sell at the same day rate. A named model gives you one or two engineers who learn your account: fewer hours, more context, and a single point of failure when one takes leave. A pooled model gives you a queue with genuine shift coverage, and nobody who remembers why the NAT gateway sits in that subnet.

The failure is not picking the wrong one. It is not knowing which one you bought. Four questions settle it:

• How many other accounts will this engineer work on this quarter?
• What fraction of their week is contractually ours?
• Who substitutes for them, and have we met that person?
• How much notice do we get before a substitution, and is there an overlap?

Then put the names and the notice period in the statement of work. A firm that will not name anybody runs a pool, which is worth knowing on day one. The rate arithmetic against hiring instead is in our comparison of a first DevOps hire with bringing in a team.

Is the company you evaluated the company doing the work?

Often it is, and you are allowed to ask before you sign. Most DevOps service providers sub-contract some of the time: a firm wins work it cannot staff this month, so a second company's engineer joins the standup carrying the first company's email address. That engineer is frequently excellent. Either way, the person holding credentials to your production account was vetted by somebody you have never met.

The RBI is blunt about this for a regulated entity. The Outsourcing of Information Technology Services Directions, 2023 want the agreement to carry, at Para 16(xviii), "clauses requiring prior approval/ consent of the RE for use of sub-contractors by the service provider", and at 16(xvi) "clauses making the service provider contractually liable for the performance and risk management practices of its sub-contractors". Para 14(viii) reaches further back: your own due diligence has to cover the "quality of due diligence exercised by the service provider with respect to its employees and sub-contractors".

Read as an engineering requirement, that is three asks. The list of sub-contractors who would touch the account. What vetting the firm runs on its own joiners. A clause that stops a new one appearing without your consent. The rest of the clause set is in our post on the outsourcing contract.

People are half of it. A vendor's pipelines reach into your account on their behalf too, and the access model to hand a partner covers telling one of their engineers from another once they are in.

Who is awake at 2am, and on whose support contract?

Use AWS's own numbers as the yardstick, because they are published and your vendor's are not. The AWS Support plan comparison commits Enterprise Support to a first response in under 15 minutes on a "Business/Mission-critical system down" case, and Business Support+ to under 30 minutes. A firm selling round-the-clock DevOps should not answer slower than the cloud underneath it.

Three things to ask. Who holds the Enterprise Support contract, and in whose account does it sit? Can the vendor's engineer raise a severity-1 case directly, or does it route through your CTO at 3am? Is there a rota with names on it, because round-the-clock cover with four engineers in one city is a phone on somebody's bedside table.

Ask that last one without judgement, then ask how long the rota has run. Two years is a staffing model. Starting the week you sign is a promise.

What happens the week their engineer rotates off?

Nothing you can see, if somebody planned for it. The week you notice is the week nobody did.

Attrition is arithmetic, not a scandal: every services company has a number, ours included, and so does your own team. What goes wrong is learning about it when a Slack handle turns grey. What you can control is where the knowledge sits when a person moves.

One cheap test: ask where the runbook for your last incident lives. If the answer is the vendor's wiki, their notice period is your outage window. If it is a markdown file in your repository, reviewed in a pull request you can still read, a rotation costs you a fortnight of pace and nothing else. The same argument across a whole engagement is what you should own on the last day.

Does the RBI care which individuals they are?

In two specific ways beyond the vetting above. Para 16(xxi) asks the agreement to treat the provider's core engineers as "essential personnel" so that "a limited number of staff with back-up arrangements necessary to operate critical functions can work on-site during exigencies", which is a requirement that two people can do the job rather than one. Para 17(10) asks you to assess "the impact of concentration risk posed by multiple outsourcings to the same service provider", and the same logic runs downwards: a single engineer is a concentration too.

Under all of it sits Para 4(1): "Outsourcing of any activity shall not diminish RE's obligations as also of its Board and Senior Management, who shall be ultimately responsible for the outsourced activity." You can buy the hours. The accountability stays where it was, which is why who holds those hours is your question and not the vendor's.

What can you run on Monday?

Two jobs, about an hour. The first is a question your own repository already answers: how much of your infrastructure knowledge sits in somebody else's head? In the repo that holds your Terraform:

git shortlog -sne --since='12 months ago' HEAD -- infra/ terraform/

The HEAD matters: leave the revision off in a script and shortlog reads stdin instead. Count the share by email domain. If more than half of the last year's infrastructure changes came from addresses you do not pay salaries to, the board should hear that number before the contract renews. Then find out who has already gone:

git log --since='24 months ago' --pretty='%ae %ad' --date=short \
  -- infra/ terraform/ | awk '!seen[$1]++'

That prints one line per author, newest commit first, for those paths; swap them for wherever your infrastructure code lives. An external address whose last commit is eight months old rotated off without a handover, and that gap is where the undocumented decisions are.

The second job is five questions, in one email, to every firm on the shortlist:

• Name the engineers who would be on our account, and say what else they work on.
• List every sub-contractor who would have access, and who vets them.
• Send last month's on-call rota, names redacted if you must, with the response times you actually hit.
• Who holds AWS Enterprise Support, and can your engineer raise a severity-1 case on it?
• What notice and what overlap do we get when somebody rotates off?

The replies sort a shortlist faster than any deck does. One firm answers inside a day with names. One asks what you mean by a rota.

When is the large consultancy the honest answer?

When the work is big and dated. Fifteen engineers for a nine-month migration with a regulator's deadline on the end of it is not something a specialist of twelve people can staff, and the bench that makes a large firm feel impersonal is exactly what you are buying.

Sometimes nobody should be brought in at all. Steady platform work that one good engineer can hold, with no compliance deadline inside the year, belongs in-house, and a partner in that seat is an expensive way to delay a hire.

We sell this work, so treat that as interested advice. We are the specialist option, and we have lost evaluations to both of the answers above for sound reasons. What we would hold any firm to, us included, is agreeing to a number up front: how to measure a DevOps engagement covers which ones belong in a contract.

The short version

• Named engineers and a shared bench cost the same and are different products. Put the names and the substitution notice in the statement of work.
• Ask for the sub-contractor list before signing. For a regulated entity, consent for them and liability for their practices belong in the agreement.
• Hold a vendor to AWS's own response times, and find out in whose account the Enterprise Support contract sits.
• Keep runbooks in your repository rather than theirs, and buy a two-week overlap on every rotation.

Start with the two commands. Read the last year of your infrastructure history, then count how many of those authors you could still reach this afternoon. If that number is uncomfortable, the shortlist is not your problem yet.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.