Stop funding teams by headcount.

When you want a deck built, you don't call a contractor and say "send me eight carpenters for three months." You say: here's the deck, here's the budget, I'd like to grill on it by June. The contractor works out how to get there. Maybe that's three carpenters for a month. Maybe it's one carpenter and a rented auger. You don't much care, as long as the deck is solid and it's done by June.

Inside most companies, we fund product teams the other way around. We fund the carpenters.

We just call it headcount. A team gets eight people because it had seven last year and asked for one more. The budget conversation is all about the eighth person: their level, their start date, whether finance approves the req. Nobody says what the eight people are supposed to make true. If they had to, half the requests wouldn't survive the sentence.

Headcount is hours with a nicer name

A headcount budget pays for effort. It assumes more people produce more of whatever the company needs, and that the right number of people is roughly last year's number plus some growth.

Both assumptions were shaky before. They're worse now.

The first problem: a headcount budget can't tell you whether it worked. At the end of the year the team had eight people. Did it succeed? The budget has nothing to say. So next year's conversation starts in the same place. We had eight, we're busy, we need nine. Busy is easy to prove. Every team is busy.

The second problem is what it rewards. If the way to get more budget is to need more people, the teams that grow are the ones that ask loudest and the ones whose work expands to fill the room. A team that found a way to do the same work with five people has just made the case for its own smaller budget. You've built a system where getting more efficient is a career risk.

There's a quieter cost, too. Headcount budgets fund building. They almost never fund making sure what got built is actually used. I'd make the cost of underused product as clear as the cost of not building. Under a headcount model, the first one never shows up anywhere.

What I'd do instead

Here's the version I'd run.

Fund a problem, not a team. Write down the change you're paying for. Say, hypothetically, onboarding is leaking: "reduce onboarding drop-off from 40% to 25%" gets a budget. The numbers are made up. The shape is the point. The team shape follows from the problem. Some problems need six people for a couple of quarters. Some need one person and a contractor for a month.

Put one person on the hook for the result. That's the strategic lead, whoever holds that role on the work. The strategic lead owns the result, not the activity. A headcount plan lets everyone own activity, because activity is what it pays for.

Set the clock with the money. Two quarters to show movement, with a check-in at the halfway point. The money comes with a deadline, and that does more for focus than any planning ritual, because the team knows exactly when someone will ask what moved.

Let the team spend it how they want. People, tools, contractors, AI. If the number moves, the mix was right. This is the contractor's freedom: you bought a deck, so you don't get a vote on whether they rent the auger. Leaders hate giving this up, and it's the part that makes the rest work. A team that can't change its own mix can't find a cheaper way to get there.

Re-fund on evidence. The next round of money follows results, the same way it would for a startup raising its next round. Movement gets more money. No movement gets a hard conversation about whether the problem was wrong, the approach was wrong, or two quarters was the wrong clock.

In a company of twenty or a hundred people, none of this needs a finance department. It's the founder writing four or five problems on one page, putting a number and a deadline next to each, and saying out loud which ones the company is paying to solve this half. Everything not on the page is, by definition, unfunded.

Why AI makes this urgent

A team's output used to track its size, loosely. More people, more work shipped. That was the whole logic of the headcount budget, and it was close enough to true that nobody questioned it.

It isn't close enough anymore. I've watched designers build working software and a design team get further with AI in three weeks than in the six months before. ("A gym membership isn't a workout" has that story.) When a small team can ship what a bigger one used to, output stops tracking size. Funding by headcount then rewards the teams that didn't figure that out, and quietly punishes the ones that did, because their reward for getting more done is a smaller line in next year's plan.

Fund the problem and that flips. The team that finds a faster, cheaper path keeps the savings as room to take on the next problem.

Busy is easy to prove. Every team is busy.