How to allocate engineering resources

Allocating engineering resources means deciding where engineers' time goes, and the honest answer in 2026 is that the old method, headcount against a roadmap, no longer describes where the return is. The highest-return allocations now go to the bottlenecks your delivery data exposes, to challenges rather than tools, and to the platform layer that lets one team's gains reach everyone else.

Allocation is the decision that shapes every other engineering management decision, because it sets what the organization can attempt before anyone writes a line of code. The method below draws on the clearest account we've heard of making that decision at scale: James Everingham's time running developer infrastructure for 40,000 engineers at Meta.

Two things have to exist before any allocation decision is defensible: a working definition of productivity for your organization, and delivery data that shows where work actually stalls. Without the first, every team can claim its request is the most productive use of people. Without the second, you're allocating against opinion.

Everingham's starting point is the definition, and he's blunt about how often it gets skipped.

"The holy grail of metrics is developer productivity. Like, is it lines of code? I don't think it is. You know, some of the most productive developers delete more code than they create, right? So, is it feature velocity? You know, what is productivity in your company?"

— James Everingham, CEO of Guild.ai and former Head of Dev Infra at Meta, on Dev Interrupted, Your engineers need an AI control plane, not more tools

Settle that before touching the org chart.

Resource requests arrive as headcount asks from the teams with the most backlog. The data usually points somewhere else. In LinearB's 2026 benchmarks, AI-assisted pull requests wait 4.6 times longer than unassisted ones to be picked up for review, and agentic PRs 5.3 times longer. That's a review-capacity problem, and it doesn't appear in any team's headcount request because it belongs to everyone.

Start allocation from the stage where work waits longest, which the cycle time diagnosis in this library shows how to find. An engineer moved into review capacity, tooling or ownership at that stage returns more than the same engineer added to a feature team upstream of it.

The reflex when leadership wants more from AI is to allocate budget to tools and mandate their use. Everingham watched that fail inside Meta, where the middle of the engineering population didn't move even with tools at feature parity with the market.

"The bulk of the engineers in the middle weren't actually, it wasn't moving anything meaningful."

— James Everingham, CEO of Guild.ai and former Head of Dev Infra at Meta, on Dev Interrupted, Your engineers need an AI control plane, not more tools

What moved the organization was allocating people against a problem that couldn't be solved the old way. The example he returns to is the holiday code freeze: Meta froze its codebase through its highest-traffic weeks every year, and instead of mandating a tool, leadership asked how to eliminate the freeze. Engineers built a diff risk scorer that made it possible.

"The way to do that, in my opinion, isn't to mandate. Like, hey, you all need to use these specific tools. I think what we ended up doing that really helped was to put business challenges out to your organization that forces them to think differently."

— James Everingham, CEO of Guild.ai and former Head of Dev Infra at Meta, on Dev Interrupted, Your engineers need an AI control plane, not more tools

The allocation unit is the challenge. The tool choice follows from it.

An incremental goal gets solved by polishing the existing process, which means the existing allocation stays. Everingham's test for a challenge worth allocating people to is that it can't be met by working harder.

"You have to put challenges out to your org that are crazy. You have to go order of magnitude. Go to your team and say, we have to 10x revenue in six months, or our CI/CD, like from land to production is six hours, get it to five minutes."

— James Everingham, CEO of Guild.ai and former Head of Dev Infra at Meta, on Dev Interrupted, Your engineers need an AI control plane, not more tools

Six hours to five minutes forces a different system. Six hours to four forces overtime.

The single most valuable allocation Everingham describes wasn't to a feature or a tool. It was to a centralized platform where engineers could see what agents existed, fork them and build on them. That's where an onboarding agent, built by one engineer for himself, became a tool that cut time-to-first-diff across the organization.

"The measure of a successful initiative or a successful platform is when the ideas are coming from your customers, and they're able to build on it."

— James Everingham, CEO of Guild.ai and former Head of Dev Infra at Meta, on Dev Interrupted, Your engineers need an AI control plane, not more tools

Without that layer, gains stay with the individuals who found them. That's the pattern LinearB's data on the AI productivity gap keeps showing: a small group pulls ahead while the organization's delivery numbers stay flat. A platform allocation, even a small one, is what turns one engineer's gain into the organization's gain.

Allocation isn't a one-time decision. Everingham's standard is that tools have to earn their usage, and the corollary is that some won't.

"The best developer tools, you have to earn the usage."

— James Everingham, CEO of Guild.ai and former Head of Dev Infra at Meta, on Dev Interrupted, Your engineers need an AI control plane, not more tools

Review the allocation quarterly against the delivery metrics from Step 1. If a challenge is producing tools that engineers adopt without being told to, fund it further. If a mandated tool shows usage without movement in the delivery data, that budget is available for something else. The adoption measurement guide in this library covers how to tell the difference.

The bottleneck stage from Step 1 shrinks. Ideas and tools start arriving from teams you didn't allocate to, because the platform from Step 4 is doing its job. And the allocation conversation changes shape, from "which team gets the next hire" to "which challenge is next."

Allocating to the loudest backlog instead of the longest wait. Mandating tools and calling it an AI strategy. Setting incremental targets that the current allocation can meet with effort. And treating the platform layer as overhead rather than the thing that multiplies every other allocation.

Should engineering resources be allocated by headcount or by outcome?

By the bottleneck and the challenge, which are outcome-shaped. Headcount is the input you move; it isn't the unit of decision.

How do we allocate resources for AI adoption?

Allocate against a challenge that requires AI to solve, not against a tool. Fund a shared layer where the solutions engineers build can be found and reused, and measure adoption by delivery outcomes rather than license counts.

How often should allocation be revisited?

Quarterly against delivery data, and immediately when a challenge is met or a tool fails to earn usage.