Revenue Quadrupled. Headcount Grew Seventy-Five Percent. That Is the Accomplishment.
Revenue Quadrupled. Headcount Grew Seventy-Five Percent. That Is the Accomplishment.
I keep hearing a version of the same flex from technology executives right now, hundreds of engineers, heavy investment in AI tooling, said the way people used to talk about server room square footage: bigger as its own kind of proof. It never comes with a number attached to what that size actually produced, only the number of people.
What actually bothers me about this is what the size is standing in for, not the size itself. A leader who can tell you exactly how many engineers report to them and cannot tell you what revenue their organization is responsible for has answered the easy question instead of the real one. This is an old mistake wearing an AI-shaped costume: IT for the sake of IT, valued for its own scale and sophistication instead of its tie to business outcomes, a pattern CTOs spent years working to leave behind.
The current version of this gets defended as a sign of the times. A large, well-resourced engineering organization reads as real capability right now. The companies winning are the ones investing heavily, building big, sophisticated, AI-enabled teams, so headcount focused on AI is treated as proof of seriousness on its own.
Here is what that framing actually produces. Once headcount becomes the signal of competence, the AI wave gives it fresh legitimacy, and hiring decisions start getting justified by growth for its own sake, or by matching what other organizations are doing, instead of by a specific revenue case. Nobody tracks the ratio anymore: whether headcount grew slower than revenue, whether fixed infrastructure costs held while revenue climbed, whether variable per-unit costs stayed flat or shrank. An organization can quadruple headcount while revenue grows fifty percent and still read as a win, because the flex itself, the raw size, the AI sophistication, substitutes for the case that should have been required to justify it.
Eventually, if revenue takes a hit, the correction arrives as a layoff. Even then, the story does not change. These leaders will still describe their tenure by how big the organization became. Not one of them describes it by whether the growth was the right decision in the first place.
The leaders who avoid this share one habit: they require a number before they approve a headcount request.
Know the revenue your team is responsible for today. Require every headcount increase to tie to either revenue growth or a specific build-out with real revenue potential. No business case, no hire. The real scorecard is a ratio: did headcount grow slower than revenue, did fixed infrastructure costs hold while revenue climbed, did variable per-unit costs stay flat or shrink. A leader who can state that ratio has actual proof the organization is worth what it costs. A leader who can only state the headcount has a flex, not an accomplishment, and the AI wave is currently giving that flex a legitimacy it has not earned.
Right now, without checking anything, could you state the revenue your team is responsible for today? Could you say whether your headcount grew faster or slower than that revenue over the last year? If you cannot answer either one immediately, that is the gap.
The LeadershipOS™ Scorecard maps whether your last headcount decision was actually justified, or just felt necessary: https://theleadershiposbook.com/scorecard
I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard
