Why Your 30% Cost Savings Don't Hit the P&L: The Leverage of Centralized Cost Management

The article opens with a Warren Buffett quote: "If you find yourself on a continuously leaking ship, putting energy into changing ships may be more effective than patching leaks." This frames the core thesis: local optimizations (patching leaks) are insufficient; structural, centralized changes (changing ships) are needed for financial impact.

Two Types of Cost Reduction: Cutting vs. Avoidance

Cost reduction in finance falls into two distinct categories:

Cost Cutting : The bill gets smaller month-over-month (e.g., negotiated lower procurement prices, fewer machines purchased). Finance recognizes this directly.

Cost Avoidance : Business volume doubles but machine count stays flat; the money was never spent. It requires a baseline for proof: historical growth rates, list price vs. negotiated price, default config vs. enforced config. U.S. federal IT governance (OMB A-131, FITARA) and CMS training explicitly state that cost avoidance is not "soft cost" — it carries the same hard financial impact as cutting, only the measurement differs.

In growth businesses, avoided costs often dwarf cut costs: avoiding procurement of 20,000 servers is cutting; using the same 20,000 servers to handle 3x traffic is avoidance.

Physical Denominators: The Measuring Stick

Absolute dollar amounts fail as metrics because they scale with business. Large companies adopt a physical denominator that both business and finance track:

Tencent (early PC era) : Bandwidth — 1 Mbps supported hundreds of IM users. Became obsolete with video/live streaming (MB per user).

JD.com : Unit order resource cost, IT expense ratio. Orders up, unit cost should drop — scale effects must dilute fixed costs. If unit cost doesn't fall, technology isn't capturing scale dividends.

Principle: the denominator must be a number the business side already watches. Finance watches money, business watches orders, technology watches cores. Only cores/orders puts both sides at the same table.

Metric Gaming and Anti-Gaming Design

Efficiency metrics are easily gamed. Three observed distortions:

Splitting requirements : One large requirement split into three small ones — delivery count triples, code unchanged.

Self-created requirements : Teams file their own refactoring, optimization, migration tickets; they define denominator and claim output. Metrics look great, business feels nothing.

Manufacturing ultra-short-cycle tickets : Flooding the system with "<1 day" tickets drops average cycle time, but real work is fragmented.

Because indicators and behaviors are a game-theoretic pair, no metric is immune forever. The solution: shorten the gaming cycle relative to the review cycle. Practical converged rules:

Denominator owned by third party : Business proposes, business accepts, business confirms value. Self-proposed/self-verified tickets excluded.

Pre-defined anomaly exclusion : Tickets <1 day, long-dormant tickets auto-rejected or tagged, excluded from stats.

Paired result metrics : If per-capita delivery rises, must simultaneously check cycle time, defect rate, rollback rate. Single-sided improvement treated as anomaly.

Layered reporting is essential. Ant Group (per Fengxuan's "Ant Intelligent R&D Insight Practice") delivers the same data in three layers: executives see global rankings and satisfaction matrices; tech leads see simplified conclusions and weekly health checks; front-line engineers see direction and instant feedback. Without layering, executives don't understand, leads can't diagnose, engineers can't improve.

Why Saving 10,000 Cores Doesn't Change the Bill

Author's Tencent ops experience: physical era, average ops managed 10,000 machines; social line (core business) exceeded 40,000 per person. Engineers had strong cost habits: capacity waterlines, multi-region planning (not all services need 3-region-5-center), cost-appropriate middleware, dedicated line governance (every cross-city Gbps counted), code-level performance tuning, tidal load shifting.

Yet these are "small accounts." Example: optimize away 10,000 cores. Redundancy is mandated by capacity waterlines — cannot touch. Procurement proceeds unchanged; bill identical. In cloud, released cores return to elastic pool sized by peak waterline; not a single purchase order cancelled. You optimized the waterline, not the pool. Local savings evaporate into the pool's "evaporation."

At the infrastructure planning layer (cloud infrastructure department), such savings round to zero. An optimization's value depends not on how much you saved, but whether it touched the mechanism that determines total quantity.

Platform-Logic Levers That Hit the P&L

Real financial impact comes from the platform/logic layer — levers only platform and mid-platform teams control:

Raising oversubscription coefficient by 0.1 affects entire cluster procurement volume.

Extending post-warranty reuse by one year amortizes full fleet annual cost.

Changing billing strategy drops the bill a tier.

One billing strategy adjustment outweighs a hundred single-machine performance optimizations. Hence cost must be managed centrally. This echoes the previous article's "go with the flow": fragmented cutting has limited value because each team moves only its small piece with its own metric, lacking global view. Pushing waterline from 40% to 35% in your team vs. platform raising oversubscription from 1.5 to 2.0 are fundamentally different actions.

Leverage length depends on which planning layer you stand on. Machine layer saves one machine; platform layer rewrites the procurement formula. Efficiency gains follow the same logic: the 30% from end-to-end efficiency comes from structural change, not process tweaks.

One-Page Summary for Leadership

A consolidated table (read bottom-up): larger magnitude layers require more authority and mechanism to move. Line optimization is basic hygiene — skipping it causes incidents — but reporting 30% from basics is meaningless.

Three Quarterly Self-Check Criteria

If finance doesn't recognize your cost reduction number, it's an engineering metric, not an operating metric. Only bill-smaller-with-flat-business qualifies for P&L.

If your efficiency metric runs six months without anyone trying to game it, nobody takes it seriously. Un-gamed metrics usually aren't in performance reviews, hence useless.

If cost reduction stays at line/machine layer and never touches procurement, scheduling, or billing policy, that 30% is calculated, not realized.

Cost requires centralized management; efficiency requires end-to-end flow. Both ultimately point to one action: pull decision rights from local back to global.