A cost-cutting cycle gets announced as a company-wide number: reduce spend by some percentage, across the board. What actually happens on the ground is never across the board, and the pattern isn't random. It follows a specific mechanism, and understanding it tells you more about what's coming than any all-hands memo will.
The mechanism, not a percentage
Robert Anthony's responsibility-center framework, the standard model behind most corporate budget structures, splits departments into cost centers, evaluated on staying within a budget, and profit centers, evaluated on revenue minus attributable cost. A downturn changes the question every unit has to answer. In normal times, 'did we stay within budget' is a perfectly adequate answer. When the mandate becomes 'shrink the budget,' that answer has nothing left to say — a cost center has no accounting mechanism for arguing it shouldn't be cut, because it was never measured on value produced in the first place. A team that can show attributable revenue has a second, structurally stronger argument available: that cutting it destroys more value than it saves. Most engineering teams, especially platform, infrastructure and internal-tooling teams, don't have that second argument on file when the cycle starts, and building it during the cycle is much harder than building it beforehand. Turning what actually happens to engineering teams during a cost-cutting cycle into something a commercial team can run is the problem XenGrowth works on.
Cost-center-shaped team | Profit-center-shaped team | |
|---|---|---|
Defense available in a downturn | "We stayed within budget" | "We generate more than we cost" |
Whether that defense answers 'should this shrink' | No | Yes, if the number holds up |
Typical examples in engineering | Platform, reliability, internal tooling | Feature teams tied to a specific revenue line or deal |
When the argument needs to already exist | Before the cycle starts — rarely does | Often already tracked as part of normal reporting |
What the spend-vs-headcount split is actually doing
Gartner's CFO research heading into 2026 makes the current shape of this concrete. Technology budget growth expectations eased only modestly, from roughly 6% to about 2%, while headcount growth expectations fell considerably further. That gap is the tell: CFOs are not simply asking every line to shrink together. They're betting that tooling — increasingly AI-assisted engineering tools specifically — can absorb work that would previously have required more people, and directing the cut disproportionately at headcount rather than at total technology spend. For an engineering team, this means the cost-cutting conversation this cycle is less often 'reduce your tooling budget' and more often 'do the same scope with fewer people,' which changes what kind of case is worth building in response.
Being honest about what the evidence doesn't show
It would be easy, and wrong, to claim at this point that engineering specifically gets cut more than other departments in a downturn, or that platform teams specifically bear a disproportionate share of layoffs. Layoff-tracking sites aggregate headline numbers without reliable functional breakdowns, and the handful of surveys that attempt a functional split are small, self-selected, and don't establish disproportionality against each function's actual share of headcount. That data doesn't exist in a form rigorous enough to cite here, and inventing a precise-sounding number would be worse than admitting the gap. What can be said with confidence is the mechanism above: cost-center-shaped work has a structurally weaker defense, independent of any specific percentage, and that mechanism is sufficient to explain the pattern without needing a number that doesn't hold up.
The honest version of this argument is less satisfying than a headline statistic and more useful, because a mechanism travels to your specific situation in a way an industry-wide percentage never quite does.
What a cut removes that doesn't show up until later
A cost-cutting cycle rarely removes a single clean function. It removes slack: the extra on-call rotation slot, the engineer who mostly did unglamorous reliability work, the second reviewer on a critical path who made review faster and safer without appearing in any deliverable. None of that has a clean line item, which is exactly why it's first to go under cost-center logic — it's the least legible thing to defend. For the the operations side of this angle, see The XenGrowth resource library.
Richard Cook's research on complex system failure describes what happens next with unsettling precision. His third point states that catastrophe requires multiple failures acting together, because well-defended systems resist any single failure. Cut enough of the slack that provided that defense and the system doesn't fail immediately — it fails later, at a moment when several smaller things go wrong at once instead of being individually absorbed the way they used to be. And per his seventh point, the resulting incident gets investigated and blamed on a single root cause, almost never on the reduced redundancy itself, because an absence a year old is invisible to a postmortem looking for what happened this week.
Build the attributable-value case for cost-center-shaped work before a cycle starts, not during it — quantify avoided incidents, prevented capacity failures, or time saved for other teams in terms finance already tracks
Expect the cut this cycle to target headcount specifically rather than tooling spend broadly, per the current CFO-level pattern, and prepare a case framed in terms of scope-per-person rather than only total budget
Don't accept a specific disproportionality claim about which functions get cut most without asking for the actual data behind it — the honest answer, industry-wide, is that the rigorous number doesn't exist yet
After a cut, watch specifically for the slack that disappeared without a name — the informal redundancy nobody budgeted for because nobody could put a line item on it — and treat its removal as a real risk, not a rounding error
A worked comparison of two teams in the same round of cuts
Say a company needs to reduce engineering costs by 15% this year. The platform team, eleven engineers doing reliability and internal tooling work, has no documented account of incidents prevented or capacity crises avoided — the work has simply always happened, quietly, and nobody built the case for it because nobody needed to until now. The payments-integration team, seven engineers, has a standing dashboard showing the revenue processed through the systems they maintain and the cost of the one major outage they had two years ago, before the current level of investment. Both teams do work the company genuinely needs. Only one of them enters the review with a number attached.
Platform team (11 engineers) | Payments-integration team (7 engineers) | |
|---|---|---|
Documented value contribution | None on file | Revenue processed, cost of a specific prior outage |
Argument available in the review | "We stayed within budget" | "Cutting us risks $X in processed revenue, based on the 2024 outage" |
Likely outcome of a 15% cut | Absorbed disproportionately — cost centers are the more attackable target | Smaller cut, or cut absorbed elsewhere first |
What changes this for next cycle | Building the same kind of dashboard now, before the next review | Keeping the existing case current and visible |
Nothing about the size of the cut or the actual importance of either team's work changed between these two outcomes. What changed was which team had already translated its contribution into the currency the review actually runs on, months before the review happened — the same asymmetry that shows up in ordinary budget conversations, just with a sharper edge under downturn conditions, where the alternative to a strong case usually isn't a smaller ask, it's disappearing from the org chart. XenGrowth on AI agents and marketing automation covers the AI agents and marketing automation side of this.
Why 'do more with less' is the actual instruction, not just a slogan
Given the Gartner pattern of headcount falling faster than budget, the realistic instruction a surviving team receives after a cut isn't usually 'do less.' It's 'maintain the same scope with fewer people,' with the gap expected to be filled by tooling, including AI-assisted development. This has a direct consequence for what kind of internal case is worth making during and after the cycle: not just an argument against the cut itself, but a credible account of what scope will actually be dropped, deferred, or done at higher risk if the headcount reduction goes through as planned. A team that lets 'we'll manage' stand unchallenged is agreeing, implicitly, to absorb the gap invisibly — which is precisely the kind of unbudgeted, undocumented slack removal that Cook's framework says shows up later as an incident with someone else's name on the postmortem.
Naming the tradeoff explicitly, in writing, before the cut takes effect, does two things a resigned 'we'll manage' does not. It gives leadership an honest choice instead of a false one — cut and keep the same scope is not actually on the table, whatever the target percentage implies — and it creates the paper trail that turns a later incident into a documented, foreseen consequence rather than a mystery requiring a root-cause investigation that conveniently lands on whichever engineer was on call that week.
What this means if you're on a team that's about to be asked to do more with less
The useful response to this mechanism isn't panic or resignation, it's specificity. If your team is cost-center-shaped, the case that survives a downturn is rarely 'we're important' — it's a quantified account of what the team prevents, in the same units finance is already using to decide where the cut lands. If that case doesn't exist yet, the cycle itself is the wrong time to build it from scratch, but it's not too late to start now, for the next one. Every cost-cutting cycle eventually ends, and the teams that come out of it with their scope intact are disproportionately the ones that had already done the accounting work before anyone asked them to. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
None of this requires waiting for the next downturn to act on. The teams best positioned when a cost-cutting cycle arrives are the ones that treated the accounting case as ordinary hygiene during the good years — a dashboard nobody looked at twice a quarter, updated anyway, because the one time it gets looked at closely is exactly the time it's too late to build.
The uncomfortable summary is that a cost-cutting cycle doesn't reveal which teams matter most. It reveals which teams did their accounting homework early, and treats the rest as though the absence of a number meant the absence of value.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
Working on what actually happens to engineering teams during a cost-cutting cycle inside a commercial team? XenGrowth's marketing operations practice publishes operator guides on the revenue side of this work.
Five questions on the accounting mechanism behind cost-cutting cycles — and what the evidence does and doesn't actually support.
