Jumping to Run at Verdant Health
Verdant Health has run public cloud for two years at $9.4M a year. Tag coverage on cost is 78%. There is monthly showback by team, no chargeback, and no unit economics. Native anomaly detection is enabled and generates roughly 400 alerts a month; the FinOps team has stopped triaging them. Commitment coverage is 12% and consists of a handful of RIs bought by an engineer who has since left. The new CTO has read about FinOps maturity, wants to skip ahead: automated rightsizing applied directly to production without approval, a 3-year all-upfront commitment program covering 70% of compute, and unit economics dashboards for all twelve service lines, all within one quarter.
1. Assess Verdant's position on the Crawl-Walk-Run ladder capability by capability, and state which two capabilities are furthest behind.
Read the worked answer
Rough placement, with the reasoning that matters more than the label:
- Allocation / tagging - Crawl, late. 78% coverage sounds respectable but the number is only useful if the untagged 22% is identified and shrinking. No chargeback means allocation has never been stress-tested by anyone with a budget.
- Reporting and showback - Crawl. Monthly, team-level, and the fact that anomaly alerts are ignored says the reports are not trusted or not read. A report nobody acts on is at Crawl regardless of how polished it is.
- Anomaly management - Crawl, and stuck. 400 alerts a month is roughly 13 a working day. That volume is a tuning failure, not a detection success: thresholds are probably percentage-of-baseline rather than tied to a dollar impact or a service's natural variance.
- Rate optimisation / commitment management - Crawl. 12% coverage from an orphaned decision is the signature of an unmanaged capability. There is no owner, no policy and no view of the steady-state floor to commit against.
- Forecasting and unit economics - Crawl / pre-Crawl. No unit metric exists at all.
Furthest behind: anomaly management (signal quality is degraded to the point of being useless and is the fastest thing to fix) and commitment management (no owner, no policy, and the largest single financial lever Verdant has left untouched).
Note that the ranking differs from what a maturity chart suggests: Verdant's constraint is not the sophistication of its reporting but that nothing it produces changes a decision.
2. Argue the CTO down from auto-applied production rightsizing and 70% 3-year all-upfront coverage. What is your counter-proposal?
Read the worked answer
Both asks are the right destination reached by skipping the intermediate steps, and both fail for the same reason: they assume Verdant's data and trust are better than they are.
Auto-applied rightsizing in production. Rightsizing recommendations are statistical; production is where a wrong call becomes an incident. At 78% tagging and no service-level cost ownership, Verdant cannot yet distinguish a genuinely oversized instance from one provisioned for a spike nobody documented. Counter-proposal: apply automatically in non-production where the blast radius is small, and run production recommendations through a named owner with a 5-day SLA. Once acceptance rate exceeds roughly 80% and the misses are explainable, revisit auto-apply. You get most of the savings and none of the incident risk.
70% of compute on 3-year all-upfront. Verdant has no measured steady-state floor and a service mix it has not baselined. Committing 70% of compute on a 3-year all-upfront basis converts a variable cost into a fixed asset and, at this maturity, will over-cover. Counter-proposal: commit in tranches against the measured floor, starting with 1-year partial-upfront Savings Plans, and raise coverage as the floor is confirmed for three consecutive months. Coverage is a ceiling question as much as a floor question - idle commitments are waste with a contract attached.
What I would fund instead this quarter: tune the anomaly signal, assign commitment ownership and policy, and pilot genuine unit economics on two service lines rather than twelve.
3. The 400 monthly anomaly alerts are being ignored. What is the actual diagnosis and what does fixing it require?
Read the worked answer
The diagnosis is alert fatigue caused by uncalibrated thresholds, and it has a second-order cost that is worse than the missed savings: the organisation has learned that cost alerts can be ignored. That habit will persist after the thresholds are fixed.
Evidence for the diagnosis: 400/month across a $9.4M estate is roughly 13 per working day, which implies most alerts are being generated by services whose spend is naturally spiky (batch, autoscaling, seasonal) rather than by genuine outliers. Volume that high cannot all be actionable, and any team that tried to triage it would have concluded the same thing within a week.
Fixing it requires four things, in order:
- A dollar threshold, not a percentage. Alert on absolute daily variance above a floor that matters, so a $40 swing in a $200 service does not page anyone.
- A per-service baseline model. Seasonality, batch cycles and known launches are excluded before an alert fires; a health system's month-end reporting load is not an anomaly.
- Routing to a named owner with an expected action and a time limit. An alert with no owner is a notification.
- A weekly review of alerts raised versus acted on. If the action rate is not rising, the thresholds are still wrong.
The CTO's automation ask should be deferred until this is done - automating a noisy signal multiplies the noise.