Stop Asking Engineers How Many Machines They Need  🔗 **Source:** [Stop Asking Engineers How Many Machines They Need](https://leaddev.com/technical-direction/stop-asking-engineers-how-many-machines-they-need) > [!note]+ Document Notes > tags: [capacity-planning, platform-engineering, engineering-leadership, infrastructure-cost, forecasting] > author: Ankur Gupta > source: leaddev.com > reference: https://leaddev.com/technical-direction/stop-asking-engineers-how-many-machines-they-need > date created: 2026-09-18 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > <!-- deep-read:sections start --> ## 🏷️ Title **Stop asking engineers how many machines they need** — Ankur Gupta, LeadDev, ~1,618 words. Practitioner field report on rebuilding hyperscale capacity planning as a platform capability rather than an annual spreadsheet ritual. ## 🧭 Table of Contents 1. Key takeaways; why the spreadsheet approach breaks at hyperscale 2. Root cause: the language gap between product and infrastructure teams 3. Five capabilities — centralize; workload intent; dependencies; products; efficiency 4. Maturity: forecasting as a continuous control plane 5. Six portable principles, and the trust problem underneath them ## 🔗 References (in-page) Not uncited — eight inline links, all internal LeadDev cross-references rather than external evidence: "budget," "doesn't scale," "machines," "data," "business growth," "Leadership," "transformation" and "earning enough trust." No vendor docs, no FinOps literature, no academic sources, no named employer. ## 📝 Summary **What happened.** An infrastructure leader at an unnamed hyperscale company replaced a spreadsheet-based capacity forecast with a centralized forecasting platform, built over multiple years as five layered capabilities: central registry, workload-intent calculators, dependency-aware cascading, product-anchored forecasts, and an efficiency loop against actual utilization. **Why it matters.** An interface problem, not a modeling problem. Product teams know traffic; infrastructure teams know SKUs. Forcing either to speak the other's language produces guesswork, and guesswork gets padded. **Stakeholders.** Product teams, capacity engineering, finance, leadership, procurement. **Risks.** Central conversion logic is a single point of failure; buffers can migrate into growth assumptions; idle deduction can penalize spiky workloads; the savings are avoided planned capacity, not cash. **Bottom line.** Stop collecting the answer; collect the inputs and own the arithmetic. ## 📖 Main Content At a few hundred engineers, capacity planning is a guess in a spreadsheet and leadership approves it. At thousands of services and hundreds of teams, the same ritual stretches to three or four months and still cannot answer what leadership asks: how much of this hardware growth ties back to business growth? Gupta locates the failure precisely. Product teams knew their own launches, traffic, QPS and storage growth but had no conversion function from business demand to machines; infrastructure teams held that knowledge but no visibility into every roadmap. With no shared bridge, each team invented assumptions and padded for uncertainty — each pad individually defensible, the sum fiction. Two pathologies follow: path dependence, as teams re-forecast familiar SKUs and multiplied fleet variation, and unfalsifiability, as forecasts could not be joined against capacity, utilization or driving products. The remedy is five capabilities in strict sequence. Centralize first: one queryable registry on a relational database, initially "a glorified spreadsheet," but traceable to a submitter and instantly aggregable. Then ask for workload intent, with calculators converting product-native inputs (traffic, ingestion, retention, replication, storage) into compute, memory, storage and network. Then make forecasting dependency-aware, so one projection cascades through the service graph, stateful platforms added later via lineage and attribution models. Then anchor requests to durable products rather than projects, and close the efficiency loop against fleet data, deducting idle capacity automatically. The least emphasized move is the most consequential: shifting from machine counts to capacity units (cores, memory, storage) decouples demand from hardware generation and turns an annual cycle into a continuous control plane. Results: three-to-four months compressed to roughly one, and hundreds of millions of dollars of planned capacity avoided — caveated as capacity removed during review, not cash. The hardest problem was social: earning trust for teams to abandon private spreadsheets. ### 🗒️ Notes - Sanitized internal case study: no employer, no baselines, no method shown for the savings estimate. - "Buffer stacking" is the load-bearing claim and the most transferable idea — it generalizes to sprint estimates, headcount and quotas. - Absent: failure modes, error detection, and whether forecast accuracy improved. ## 📚 References (primary sources preferred) The article cites no primary sources. To verify or extend its claims: - Google SRE Book, demand forecasting and capacity planning chapters (sre.google/sre-book). - FinOps Foundation Framework, Forecasting and Rate/Usage Optimization capabilities (finops.org). - Borg (Verma et al., EuroSys 2015) and Autopilot (Rzadca et al., EuroSys 2020) — the bottom-up rightsizing alternative to capability 5. - Kubernetes resource model docs — capacity units at fleet scale. ## 🗣️ Paraphrase (paragraph by paragraph) **Key takeaways.** Reasonable per-team margins, multiplied across hundreds of teams, silently inflate demand. Ask about growth, not machine counts. Durable products shorten the cycle to about a month. **Scaling problem and diagnosis.** Small companies plan with a guess and a spreadsheet and it works; at hyperscale it stretches to months and nobody can tie hardware growth to business growth. Product teams understood their own demand but not how it converted to machines; infrastructure teams knew the conversion but not the roadmaps. **Buffer stacking, path dependence, untraceability.** With no shared translation layer, every team improvised and padded; aggregated, those pads dramatically inflated demand. Teams also kept forecasting familiar SKUs, producing fleet sprawl, and forecasts could not be joined to capacity or utilization, so review became a multi-month negotiation. **Capabilities 1–3.** One registry made aggregation instant, and shipping the smartest version first would have killed adoption. Calculators then asked product-native questions — QPS for a stateless service, ingestion and replication for a streaming platform — and one projection cascaded through the service graph, with stateful modeling taking years. **Capabilities 4–5.** Forecasts moved to durable products, so leaders could compare a product's cost growth with its business trajectory. Fleet data then let idle capacity be deducted automatically, and capacity units decoupled demand from hardware generation. **Results and principles.** Three-to-four months became about one. Six principles: centralize before adding intelligence; ask for workload intent; let domain owners own conversion logic; model downstream demand instead of buffering; connect requests to durable products; close the loop against actual usage. The hardest part was earning trust so teams abandoned private spreadsheets. ## 📰 Newsletter (WordPress-focused) **Subject: Your hosting estimate is a spreadsheet wearing a confidence hat** Ask a plugin team "how many machines do you need for the next release?" and you get a number that is 40% engineering judgment and 60% anxiety. Ankur Gupta's [LeadDev piece](https://leaddev.com/technical-direction/stop-asking-engineers-how-many-machines-they-need) argues the question itself is the bug: product folks know traffic growth, infra folks know SKUs, and whenever one side must guess the other's domain, they pad. Pad enough times and your aggregate forecast is fan fiction. WordPress runs this at community scale. [WordPress.org systems](https://make.wordpress.org/systems/) absorbs demand from [Playground](https://wordpress.github.io/wordpress-playground/), [Openverse](https://openverse.org/) and [Tide](https://make.wordpress.org/tide/), plus a release cadence that spikes traffic on a schedule nobody writes down in capacity units. [Core Performance](https://make.wordpress.org/performance/) measures what sites do; [Hosting](https://make.wordpress.org/hosting/) knows what it costs; no shared calculator connects them. Ask for pageviews, not "how much RAM." ## ✅ Action Items - **DevRel** — publish an "ask for intent, not implementation" intake pattern. - **OSPO** — audit open source resource requests for buffer stacking. - **Community (program-level)** — ask organizers for attendees, not specs. **WordPress subteams** - **Core** — document release-day update-check traffic so demand is derivable. - **Core Performance** — publish pageviews → capacity-unit heuristics. - **Core AI** — size inference demand in tokens and GPU-seconds. - **Core Program Team** — add a capacity-intent checkpoint to releases. - **Mobile** — forecast API load from adoption curves, not device counts. - **Playground** — model the browser vs. server execution split. - **Community** — track streaming and archive storage against actuals. - **Training** — build a Learn lesson on estimating hosting from traffic. - **Marketing** — frame infrastructure cost as business growth. - **Support** — instrument forum load growth as a product forecast. - **Design** — build intake forms asking growth, not hardware. - **Documentation** — publish WordPress.org capacity assumptions. - **Photos** — forecast storage and egress from submission trends. - **TV** — model video storage and bandwidth from hours published. - **Polyglots** — forecast translate.wordpress.org load from locale growth. - **Accessibility** — hold new forecasting tooling to WCAG 2.2 AA. - **Meta** — own the conversion logic and central capacity registry. - **CLI** — expose usage counters making workload intent measurable. - **Hosting** — publish a shared capacity-unit vocabulary. - **Tide** — model audit compute from submission volume. - **Openverse** — forecast index load from provider onboarding. - **Themes / Plugins** — model review and serving load from update rates. - **The WPOCC (The WP Open Community Collective)** — use product-anchored asks in fundraising. - **FAIR** — model mirror load as a cascade from upstream updates. ## 🧪 Hypotheses (testable) 1. **Buffer stacking is measurable.** With >50 submitting teams, requested capacity exceeds consumed by a margin growing with team count. Test: regress (requested − consumed)/consumed on submitter count. 2. **Intent-based intake reduces padding.** Test: A/B a growth-input against a hardware form. 3. **Centralization alone drives most of the time saving.** Test: cycle time per capability rollout. 4. **Product anchoring increases capacity returns.** Test: returned capacity before/after registry integration. 5. **Idle deduction penalizes spiky workloads.** Test: correlate shortfalls with workload variance. 6. **Trust precedes accuracy.** Test: regress adoption on perceived control vs. model accuracy. ## 📊 Methodology Single-organization, multi-year retrospective case study by a participant. No control group, no pre/post design, no named employer, no baselines, no stated method for computing avoided capacity. Outcome measures are cycle duration (three-to-four months → ~one month) and avoided planned capacity, self-caveated as review-phase removal rather than cash. Capabilities evolved "often in parallel," so individual effects cannot be separated. Hypothesis-generating testimony, not evidence of effect size. ## ❓ Questions - How are the conversion calculators validated, and who owns a systematically wrong model? - What is the appeal path when idle capacity is deducted from a team needing seasonal headroom? - Did measured forecast accuracy improve, or only cycle time and aggregate size? - Did buffers disappear, or migrate into inflated growth assumptions? - What is the minimum viable version for a 200-engineer company? ## 🔮 Future Research - Quantify buffer stacking across organization sizes; no published coefficient exists. - Test whether intent-based intake removes uncertainty or displaces it into growth assumptions. - Compare centralized conversion logic against federated logic on a shared schema. - Extend dependency-aware forecasting to AI inference, where coupling is less linear. - Test the pattern in federated open source infrastructure, where no one can mandate a registry. ## 💡 Implications **Practice.** The transferable unit is the intake interface, not the platform. Any team collecting estimates from many independent parties should collect inputs and own the arithmetic centrally — sprint sizing, budgets, quotas, event capacity, not just hardware. **Policy.** Product-anchored requests with accountable owners create an auditable chain from business growth to spend, the precondition for meaningful FinOps or sustainability policy. **Security.** A central registry maps the service dependency graph, growth plans and unreleased roadmaps in one database — a high-value target needing tighter access control than typical internal tooling. **Education.** Platform and SRE curricula should teach demand modeling and unit economics. In WordPress, "how much hosting do I need" is folklore; it could be a calculator. **Funding.** Community infrastructure is asked for hardware totals when funders want growth-linked justification; capacity units tied to durable projects make multi-year funding tractable. ## 🧠 Learning Styles Assessment - **Visual**: Weak. Two decorative images; the dependency graph begs for a diagram. - **Aural**: Weak. No audio version, though the material is conference-talk shaped. - **Verbal**: Strong. Clear declarative prose, numbered structure, a title that states the thesis. - **Kinesthetic**: Weak-to-moderate. Six principles but no template, worksheet or starter schema. - **Logical**: Strong. Problem → cause → sequenced remedy → results, with "centralize first" justified. - **Social**: Moderate. Framed around cross-team dynamics, trust and negotiation. - **Solitary**: Strong. Self-contained ~8-minute read needing only infrastructure literacy. - **Naturalistic**: Weak. No energy or carbon framing, though overprovisioning is a sustainability issue. - **Reading level**: Grade 12–14; QPS, SKU and control plane assume professional context. ## 📊 Accessibility Assessment (WCAG 2.2 AA) 1. **Text alternatives (1.1.1)**: Partial. The lead image's alt "AI amplify developers" describes neither image nor purpose; the promo's alt duplicates adjacent text. 2. **Info and relationships (1.3.1)**: Good. Real heading hierarchy and genuine lists. 3. **Meaningful sequence (1.3.2)**: Good; reading order matches visual order. 4. **Contrast (1.4.3, 1.4.11)**: Not verifiable from the text capture; CTA and promo banners are the likely risk areas. 5. **Link purpose in context (2.4.4)**: Mixed, the clearest failure. "Budget," "data," "machines" and "Leadership" are ambiguous in a link list; "machines" points to an unrelated piece. 6. **Headings, focus, target size (2.4.6, 2.4.11–2.4.13, 2.5.8)**: Headings are descriptive; focus and target size need checking live. 7. **Readable and predictable (3.1, 3.2)**: Partial. QPS and SKU are expanded on first use; "control plane," "data flow lineage" and "attribution models" are not. ## 🌍 DEIB Assessment - **Cultural breadth**: Narrow. Exclusively US-style hyperscale corporate framing; no resource-constrained contexts, data sovereignty, or non-English-speaking teams using an English-only form. - **Inclusive language**: Good. No gendered defaults, ableist idioms or violent metaphors. - **Neurodiversity support**: Good. Predictable structure, short paragraphs, bold takeaways; missing diagrams are the gap. - **Representation**: Thin. One anonymous author and an undifferentiated "we." - **Psychological safety**: Notably positive. Blames the system, not people, and credits voluntary adoption over mandate. ## ✅ Logical Validity **Strong reasoning.** - The central mechanism — independently reasonable buffers aggregating into an unreasonable total — is a sound compositional argument matching documented estimation behavior. - The sequencing claim is argued, not asserted: centralization must precede intelligence because adoption and cognitive change cannot be demanded in the same cycle. - The author self-limits his strongest number, calling the savings avoided planned capacity rather than cash, and admits the work "took multiple years." **Fallacies.** 1. **Hasty generalization** — in the closing section, where one unnamed organization's experience becomes six principles for "leaders facing a similar problem." One case, no comparison org, no failure cases. *Fix*: reframe as "six hypotheses that held for us" and state the boundary conditions (org size, service count, an existing product registry) under which they transfer. 2. **Post hoc / single-cause attribution** — in the results paragraph, where the months-to-one-month compression and avoided capacity are credited to the platform, though headcount change, cloud migration, austerity and reorgs are plausible co-causes and capabilities evolved in parallel. *Fix*: report cycle time and forecast error per cycle alongside confounders. 3. **Suppressed evidence** (minor) — only what worked is reported. *Fix*: include one concrete failure and its remedy. **Tone of voice.** Measured senior-practitioner register, system-blaming rather than people-blaming; confident but not triumphalist. The main tilt is structural: an uninterrupted success arc invites more confidence than single-case evidence supports. ## 🛡️ DARVO Analysis **Deny**: Absent. The author acknowledges the old process failed, the first version was crude, and the headline figure is not cash. **Attack**: Absent. Teams are called "still guessing," but this is reframed as a rational response to a missing translation layer. **Reverse victim and offender**: Absent. The platform owner holds responsibility rather than assigning it to submitting teams. No DARVO pattern — the piece is a counter-example, using systems framing where blame-shifting would be easy. ## 🎯 Conclusion **Bottom line.** "How many machines do you need?" outsources a translation problem to the party least equipped to solve it, and the result is padded, untraceable numbers. Collect growth intent in the requester's language, own the conversion centrally, cascade it through the dependency graph, anchor it to durable products, and close the loop against actual utilization. Sequencing matters more than modeling sophistication, and the binding constraint is trust, not math. **Next steps.** (1) Rewrite one intake form to ask for growth inputs. (2) Measure requested-vs-consumed capacity for the last two cycles. (3) Build one conversion calculator, owned by its domain experts. (4) Publish forecast-vs-actual comparisons. ## 🧱 Refactor Appendix ### Literature Split Pad ### L1 — Reasonable buffers compose into unreasonable aggregates (atom/literature/h1) Strongest evidence claim; the mechanism is compositional. > [!quote] Without a standard way to bridge this gap, every team created its own assumptions and added buffers for uncertainty. Individually, those buffers looked reasonable, But when forecasts from hundreds of teams were added together, they inflated the total demand dramatically. ### L2 — Familiarity, not fitness, drives hardware selection (atom/literature/h2) Path dependence in SKU choice blocks standardization. > [!quote] The process also carried old hardware decisions into every new planning cycle. Teams forecasted the same hardware Stock Keeping Units (SKUs) because those were familiar, not necessarily because they were still the best fit. Over time, this created unnecessary hardware variations and prevented us from using more standardized, cost-effective purchases. ### L3 — Ask in the requester's language, own the conversion (atom/literature/h3) Calculators turn negotiation into specification. > [!quote] We bridged this gap by building system specific calculators that automatically converted business growth into hardware units. Instead of asking teams “how many machines do you need?” the system asked questions familiar to product teams, such as expected traffic growth, data ingestion, retention, replication, job volume, reads, writes, or storage growth. When you ask questions in their language, the conversation shifts entirely. A product team can confidently project 10% traffic growth based on specific initiatives. ### Atomic Split Pad (Zettel candidates) #### Z1 — Closing the loop removes the argument (atom/zettel/z1) Known allocation, usage and idle capacity turn review into arithmetic. > [!quote] Now, when a team asks for capacity, the system already knows its current allocation, actual usage, and how much capacity sat idle the previous year. Idle capacity was automatically deducted from the team’s future forecast. #### Z2 — Adoption sequencing beats sophistication (action/h1) Ship the crude central version; add intelligence after adoption. > [!quote] Do not try to solve everything in the first iteration. Centralize first. Get adoption. Add sophistication later. The temptation is to launch the smartest version in the first attempt, but asking people to change where they work and how they think in the same cycle is how these programs die. #### Z3 — Capacity units decouple demand from hardware generation (action/h2) Cores/memory/storage make capacity fungible across generations and teams. #### Z4 — Durable entities are the right accountability anchor (action/h3) Anchor traceability to the product, not the project. ### Fleeting Queue (atom/fleeting/f1) - Is there a published coefficient for buffer stacking? If not, that is a paper. - The registry maps service topology and roadmap — what is the threat model? <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Stop Asking Engineers How Many Machines They Need.md|Stop Asking Engineers How Many Machines They Need by Ankur Gupta]] ## Highlights - Without a standard way to bridge this gap, every team created its own assumptions and added buffers for uncertainty. Individually, those buffers looked reasonable, But when forecasts from hundreds of teams were added together, they inflated the total demand dramatically. ([View Highlight](https://read.readwise.io/read/01m2sasbs8m4r0mym0783xmnry)) - Note: L1 — strongest evidence claim: buffer stacking is compositional. Individually reasonable padding aggregates into an untraceable, inflated total. The portable finding; generalizes to sprint sizing, headcount, quotas. - Tags: atom/literature/h1 - The process also carried old hardware decisions into every new planning cycle. Teams forecasted the same hardware Stock Keeping Units (SKUs) because those were familiar, not necessarily because they were still the best fit. Over time, this created unnecessary hardware variations and prevented us from using more standardized, cost-effective purchases. ([View Highlight](https://read.readwise.io/read/01m2sasev02ntb2696zpcdx6cw)) - Note: L2 — path dependence in SKU choice. Second-order cost of asking for hardware instead of intent: fleet sprawl blocks standardized, cheaper purchasing. - Tags: atom/literature/h2 - Do not try to solve everything in the first iteration. Centralize first. Get adoption. Add sophistication later. The temptation is to launch the smartest version in the first attempt, but asking people to change where they work and how they think in the same cycle is how these programs die. ([View Highlight](https://read.readwise.io/read/01m2sasm97ts4m5ht402t9xj1b)) - Note: Z2 / action — adoption sequencing beats sophistication. Applies to any internal-tooling migration: ship the crude central version, add intelligence after adoption. - Tags: atom/zettel/z1, action/h1 - We bridged this gap by building system specific calculators that automatically converted business growth into hardware units. Instead of asking teams “how many machines do you need?” the system asked questions familiar to product teams, such as expected traffic growth, data ingestion, retention, replication, job volume, reads, writes, or storage growth. When you ask questions in their language, the conversation shifts entirely. A product team can confidently project 10% traffic growth based on specific initiatives. ([View Highlight](https://read.readwise.io/read/01m2sashxj5t6hvp2tq3d2d53p)) - Note: L3 — the core design move: ask in the requester's language, own the conversion centrally. Turns a negotiation into a specification. - Tags: atom/literature/h3 - Now, when a team asks for capacity, the system already knows its current allocation, actual usage, and how much capacity sat idle the previous year. Idle capacity was automatically deducted from the team’s future forecast. ([View Highlight](https://read.readwise.io/read/01m2saspq1pdex5mjmw9p7bbjk)) - Note: Z1 — closing the loop removes the argument. Automatic idle deduction is the enforcement mechanism. Open risk: may penalize legitimately spiky workloads (Hypothesis 5). - Tags: action/h2, atom/zettel/z1 - It also helped identify and avoid hundreds of millions of dollars’ in planned capacity through reduced overprovisioning, hardware simplification, and reuse of existing supply. This figure represented capacity removed during the review phase, not realized cash savings. ([View Highlight](https://read.readwise.io/read/01m2sasw50hmb9npdhckfqcazb)) - Note: Fallacy: post hoc / single-cause attribution. Over multiple years, headcount change, cloud migration, budget austerity and reorgs are plausible co-causes; the article says capabilities evolved in parallel, so attribution to the platform is unrecoverable. Credit where due: the author does caveat that this is avoided planned capacity, not cash. Fix: report cycle time and forecast error per planning cycle alongside confounders. - Tags: fallacy/post-hoc, atom/fleeting/f1 - For leaders facing a similar problem, I would carry forward six principles: ([View Highlight](https://read.readwise.io/read/01m2sass6y123r9pv5s5gwb6d9)) - Note: Fallacy: hasty generalization. One unnamed organization's multi-year experience is converted into six principles for all leaders — no comparison org, no failure cases, no boundary conditions. Fix: reframe as "six hypotheses that held for us" and state the conditions (org size, service count, existence of a central product registry) under which they should transfer. - Tags: fallacy/hasty-generalization, action/h3