State of the proof
What this is not
It is not a one-off audit that ends in a slide. Each of the three specialties is measured against a baseline taken before the work starts, because a saving with no baseline is a claim and a claim cannot be defended in a budget round.
It is not cost-cutting. FinOps changes what an estate costs by changing what it does — reserved capacity, dead services, the query nobody has read in two years — and where the only remaining lever is capacity that the business needs, the mandate says the cost is correct.
GreenOps carries no published case today. It is declared, three sub-capabilities deep, and it stays visible with that state shown rather than dressed as proven work.
FinOps
What the estate costs, broken down to a line an owner can defend — and the changes that move the figure.
FinOps answers what an estate costs, broken down to a line an owner can defend in a budget round. The breakdown is the deliverable as much as the saving: a cost nobody can attribute is a cost nobody can argue for, and it gets cut by percentage rather than by judgement.
The work starts with attribution — tagging, allocation, and the uncomfortable exercise of mapping spend to the teams and products that cause it. Most estates discover two things there. A meaningful share of spend belongs to nothing anyone is still using, and another share belongs to a service whose owner has never seen its bill.
Then the levers, in the order that keeps the business running: dead resources, oversized instances, storage tiers nobody chose, commitments bought against real baselines rather than optimistic ones, and finally architecture — the query pattern, the chatty integration, the pipeline that reprocesses everything nightly because it once had to.
Where the only remaining lever is capacity the business genuinely needs, the mandate says the cost is correct. That is a finding, not a failure, and it is more useful than a saving extracted by degrading something that was sized properly.
A cloud bill is an architecture diagram written in money. This werk reads it that way: spend mapped to the workloads that cause it, a unit cost the business recognises, and the decision moved to the engineers whose design sets the number.
PMU · Société Générale · Celio
Commitment and rightsizing programmes run inside replatforming mandates, where the saving is reported as part of the migration rather than published as a cost engagement in its own right.
Tagging standards and monthly cost readings stood up alongside platform teams on mandate; no case published on the governance work separately.
Perf4Ops
How fast the estate answers under real load, and what it takes to hold that under growth.
Latency is measured at the percentile the business actually feels, not the average. A median that looks healthy while the ninety-fifth percentile times out is the ordinary shape of a performance problem, and reporting the mean hides exactly the users who are leaving.
Availability and latency are promises, and a promise with no budget attached is a hope. This werk states the promise in numbers, spends against it deliberately, and enforces it in the pipeline instead of in the post-mortem.
Response-time and load work carried inside delivery mandates — a performance budget wired into the pipeline — with no case published on the performance work in its own right.
Capacity modelling held on high-availability estates where peak load is the design constraint; not published separately from the migrations that carried it.
Signal design, on-call rotation and post-incident practice run inside platform mandates; reported as part of the migration record rather than as a standalone engagement.
GreenOps
What the estate emits, measured rather than modelled, and the trade-off against cost and latency.
Its state is stated plainly rather than softened: three sub-capabilities, all declared, no published case. That is not a gap in competence, it is a gap in published proof, and the two are worth keeping distinct — a buyer can weigh the first, and only a case can settle the second.
Carbon is the third bill a running system sends, and the one most often estimated by someone who never sees the architecture. This werk keeps it on the same board as cost and latency, and is honest that the proof here is a method rather than a published result.
How it is bought
Any expertise can be bought in six forms: fixed price, time and materials, short placement, long placement, permanent placement or named seat. Each specialty carries the forms that suit it.
Questions
- Is this an invoice audit?
- No. Cost that comes out through a negotiation goes back in within two quarters. What holds is a unit-economics model owned by the teams that spend, wired into the architecture decisions that actually move the bill — which takes a mandate rather than a report.
- Where is the real proof?
- In the PMU replatforming, where total cost of ownership fell 87% while a five-nines uptime target held. At Societe Generale, where a datacenter exit onto elastic AWS patterns cut TCO by 37%. At celio, where a data-mesh replatforming took 30% out of TCO while the digital business grew.
- How does this relate to PerfOps and GreenOps?
- They are the same dial read three ways. Rightsizing a fleet takes money and carbon out and can take the service level with it. Cost decisions are taken here, but arbitrated against the numbers held in PerfOps and GreenOps rather than against nothing.
- Who should not hire this werk?
- An organization that wants a saving without changing who decides. If engineering teams do not see and own their spend, the model is a spreadsheet and the bill returns.
- Why hold performance next to cost?
- Because headroom is bought twice — in the invoice and in the footprint. An SLO with no cost owner produces over-provisioning; a cost programme with no SLO produces outages. The trade-off is argued once, in the open, by someone accountable for both.
- Where is the real proof?
- In the PMU replatforming, where a five-nines 99.995% uptime target held on a live betting platform while total cost of ownership fell 87% — the service level was the constraint the cost work had to respect.
- What is honestly not published?
- Standalone performance engagements. Response-time, capacity and observability work is held by named operators and carried inside delivery and migration mandates; there is no published case sold as performance work on its own.
- Is this the same as platform engineering?
- No. Platform engineering builds the paved road; this werk is accountable for how fast it is and whether it stays up. They are frequently bought together and they answer to different numbers.
- Is this proven?
- No, and it is marked that way. GreenOps is declared: it is in scope, the method is standard provider telemetry and public emission factors, and no published case carries a sourced emissions figure. A buyer who needs an audited carbon baseline should bring a specialist and use this collective on the architecture and the trade-offs.
- Then why keep the werk?
- Because the decisions that set a footprint — instance families, placement, retention, headroom — are taken inside the cost and reliability work this collective already runs. Naming it keeps the third bill on the same board instead of leaving it to a report nobody can act on.
- What actually moves the number?
- The same moves that move the invoice, mostly: rightsizing, removing zombie workloads, tiering cold storage, and not buying headroom nobody uses. Where they diverge — region choice, scheduling against grid intensity — the trade-off is stated rather than assumed.
- Who should not hire this werk?
- Anyone who needs an assured, auditable carbon statement today. That is a specialist's signature, not this collective's.