Roughly thirty cents of every cloud dollar is wasted. Flexera has run its State of the Cloud survey for more than a decade, and the self-reported waste figure has barely moved off that number the whole time — even as every vendor in the category bolted the word 'optimization' onto its deck. An industry that has been selling optimization for ten years and has not budged the one metric that defines it is telling you something about itself. The category that promises to fix that number markets itself as 'agile cloud consulting,' and the reason the number does not move is baked right into the name.
The phrase is three good words assembled to do one bad job: let the seller take credit for a process and a destination without ever owning the result. Agile, cloud, consulting — each is real on its own. Glued together on a services page, they stop describing a deliverable and start describing a posture. The posture is what sells, and the posture is exactly the problem.
The phrase is the tell
Read it word by word the way a buyer should. 'Agile' in the pitch means standups, a Jira board, a burndown chart, a two-week cadence you can show a steering committee. 'Cloud' means a migration — a place you arrive at and get billed for. 'Consulting' means advice: a roadmap, a maturity assessment, a slide showing where you are and where a more enlightened company would be. Notice what is absent from all three. Nobody whose name is on the commit when it pages at 2 a.m. None of the words, on inspection, commits anyone to building and running the thing.
That absence is not an accident. It is the product. The reason a firm can sell agility, cloud, and consulting as a bundle is that each word is structured to keep the seller one step removed from the outcome. The ceremony is performed, the migration is completed, the advice is delivered — and the firm is paid and gone before the cloud bill for the second quarter lands.
Agile was never the ceremonies
The agility that matters has nothing to do with the ritual calendar. It is scope discipline — the willingness to cut, to ship the smallest thing that is actually useful, and to say no to the features that feel important in a kickoff and turn out to be dead weight. Conventional agile consulting sells the opposite of that: velocity, throughput, more tickets closed per sprint. Measuring how fast you build the wrong thing is not agility. It is an expensive way to be busy.
The most agile engagement I have watched up close did not start with a board. We once picked up a stalled build — Meal4U — where the prior team had simply failed to deliver. The first week was not coding. It was tearing the scope apart, re-estimating the project something like ten times, and cutting thirty to fifty percent on each pass until what was left was the smallest version that could ship and survive contact with real users. That is the agile move: subtraction under pressure. No quantity of standups manufactures the judgment to delete a feature, and no consultant selling velocity is incentivized to.
The cloud is not a destination, it is code someone has to own
'Cloud' as it is sold is a place you move to, as if arrival were the achievement. The migration is the easy, billable part. The operational reality afterward — the part where instances run idle over the weekend, where nothing is right-sized, where a service nobody remembers provisioning is quietly costing four figures a month — is the hard part that the consulting model is built to hand off. That thirty percent of wasted spend is not a mystery of physics. It is over-provisioning and orphaned resources, every one of them a decision made by someone who did not have to pay attention to the bill afterward.
The structural failure is the org chart. A separate 'cloud team' that provisions infrastructure and hands it to a separate 'dev team' that writes the application guarantees that nobody owns the line item. Each side can point at the other. The fix is boring and unglamorous: the engineers who write the application code should own the infrastructure it runs on. At our studio that is not a policy, it is the default — DevOps belongs to the people writing the app, not to a department that gets paged into a problem it cannot read the source of.
When US-EAST-1 fell over on June 13, 2023 and took a chunk of the internet down with it, our client projects kept running. Not because we are clairvoyant, but because the people who built those applications also built and understood the infrastructure underneath them, and had designed accordingly. You cannot buy that resilience as a deliverable from an advisory engagement. It is a byproduct of the same hands owning both layers — which is precisely what the 'cloud consulting' framing splits apart.
Consulting is the word that lets them leave
'Consulting' is the most honest word in the phrase, because it tells you the engagement is designed to end. That would be fine if software ended. It does not. The system you stand up in a six-month transformation has to be operated, patched, scaled, and argued with for years. The consulting model resolves that mismatch the cheap way: a senior architect fronts the sales call, and the work is staffed by rotating juniors behind them — body shopping with a better vocabulary. The senior name on the proposal is rarely the hands on the keyboard.
And the people on the keyboard keep changing. Industry turnover in this business runs north of twenty percent a year, which means the team that learned your system is statistically gone before they have finished learning it. That churn is not incidental to the cloud waste and the half-owned infrastructure — it is the cause. Knowledge of why a thing was built the way it was leaves with the engineer, and the next one re-discovers it by breaking it.
This is the one place the alternative is structural, not aspirational. Our own turnover runs under five percent a year, the average client relationship runs around four years, and the longest is heading past a decade — the platform we built for MyFlyRight has been the same partnership since 2016. The point is not the loyalty. The point is that the same people who made the architectural decisions are still there to be held to them. 'Same team month after month' is not a comfort blanket; it is the only way anyone is ever accountable for the cloud bill, the scope, and the 2 a.m. page at the same time.
What to actually buy
So commit to the position: do not buy 'agile cloud consulting.' Buy the three things the phrase is engineered to obscure. Buy engineers who write the code rather than narrate it. Buy infrastructure owned by the people who deployed it rather than handed across an org chart. And buy a relationship that does not have a built-in exit, because the seller who plans to stay makes different decisions than the seller who plans to present and leave.
That is buyable without the wrapper. The shape we use — a free discovery week, then a paid pilot with no lock-in, then two-week sprints with every pull request reviewed by another senior engineer before it merges — is agile in the only sense that counts: you can see the work and stop anytime, and nothing ships that a second senior has not read. When Nautical Commerce needed a marketplace platform on a hard ninety-day go-live, the win was not a ceremony or a migration; it was inheriting a year-old codebase and shipping against the date, on infrastructure the same engineers owned. The platform we built went on to process more than 200,000 transactions a month. Agile, cloud, and ownership — delivered as engineering, not as a posture.
We've made the long version of this case in our full breakdown of when staff augmentation is worth it. For team composition, rates, and how engagements start, our staffing services cover it.
The bottom line
If a firm sells you 'agile cloud consulting' as a process, a destination, and a deck of advice, read the offer for what it is: you are paying for the three abstractions that let the firm walk away before the consequences arrive. The waste figure has not moved in a decade because the category is not built to move it. What moves it is unglamorous and hard to put on a services page — engineers who build, own what they built, and are still in the room a year later. Pay for that. Refuse to pay extra for the words wrapped around it.