Your Board Wants 20% Fewer Engineers. Here Is What to Say.

Your board wants 20% fewer engineers. Here is what to say.

I have been in rooms where this conversation happens. A board member reads a McKinsey slide about AI replacing 20% of engineering work. The CFO nods. Someone says "so we can cut 20% of heads?" And the CTO sits there, caught between two realities that do not fit together.

On one side: over 100,000 tech workers lost their jobs in 2025. Boards see that and think the market agrees with them. On the other side: 85% of engineering leaders in recent surveys expect their headcount to stay flat or grow. Both things are true at the same time. The CTO has to explain why.

I ran a consulting practice and managed a $50M annual technology budget at a logistics company that operates in 130 countries. I have sat through enough of these budget fights to know what works and what does not.

The 20% number is wrong, and here is why

The board heard that AI can do 20% of engineering work. They turned that into "we need 20% fewer engineers." That is a category error.

AI replaces tasks. Not roles. A senior engineer might spend 30% of their time writing boilerplate, 20% reviewing pull requests, and 50% on design, debugging, and talking to product teams. AI helps with the first two. It cannot do the last one.

Across a whole team, AI might absorb 15-25% of total hours. That is real. But those hours are spread thin across every person. You cannot fire 20% of the people and expect the other 80% to absorb the remaining work cleanly. It does not divide that way.

Try this in the meeting: if a new tool made your sales team 20% faster at writing proposals, would you fire 20% of the sales team? Or would you expect more proposals?

What to say instead

Do not argue philosophy. Argue numbers.

Come to that meeting with a simple table. Column one: the task. Column two: hours per month before AI. Column three: hours per month after. Column four: where those freed hours went.

Real example from a team I worked with: code reviews used to take 400 hours a month. With AI-assisted tooling, that dropped to 280. The 120 hours freed up went into reducing the security backlog, which had been a board-level risk item for six months.

That is the language your CFO understands. Not "AI is changing how we work" but "we moved 120 hours from routine review into security remediation, and here is the risk reduction in pounds."

If you cannot produce this table, you have a bigger problem. You do not know where your engineering hours go. Fix that before the board meeting.

The redeployment frame

This is the argument I have seen work: do not cut 20%. Redeploy 20%.

Every engineering org has a split between keeping things running and building new things. In most companies I have worked with, it runs about 60/40 or 70/30 in favour of maintenance. Bug fixes, security patches, migrations, keeping the lights on.

AI tools happen to be good at exactly that kind of work. Repetitive. Well-documented. Clear patterns. So instead of cutting people, move them. Take 20% of your maintenance capacity and redirect it to building internal AI tooling and platform work. Automation that compounds over time.

The pitch to the board becomes: "We are not asking to keep headcount because we like big teams. We want to redirect capacity from maintenance into building things that make us faster next year."

That is an investment argument. It changes the conversation from cost to return.

What you lose when you cut

Boards sometimes treat engineers as interchangeable. They are not.

A senior engineer who has been at your company for four years carries knowledge that exists nowhere else. They know why that payment system has the weird retry logic. They know which API partner sends bad data on the third Tuesday of every month. They know which parts of the codebase nobody wants to touch.

No LLM can replace that. LLMs work from documentation and code. But the most valuable knowledge in any engineering org was never written down. It lives in people's heads. It is the "ask Sarah, she was here when we built that" knowledge.

When you cut 20%, you do not lose 20% of output. You lose 20% of context. And rebuilding context is painfully slow. The remaining team spends six months answering questions that the departed engineers would have handled in two minutes. Velocity does not go up. It drops. For a long time.

I have watched this play out twice at different companies. Both times, the projected savings turned into a net cost within 18 months. Rework, delays, and the expense of hiring replacements when the board reversed course.

Build a counter-proposal the CFO respects

Walk into that room with a one-page proposal. Four numbers.

One: your current engineering cost per feature delivered. If you do not track this, start now. Everything else depends on it.

Two: projected cost per feature after AI tooling is fully adopted. This should be lower. If AI is doing its job, you deliver more for the same spend. Show the trend over the last two quarters.

Three: the redeployment plan. How many people move from maintenance to platform work. What they will build. What the expected return looks like in 12 months.

Four: the risk register. If we cut 20%, these projects stop. This compliance deadline gets missed. This technical debt grows by this much. Put pound figures on each item. Make it concrete.

Do not make it emotional. Do not say "my team is brilliant and we need everyone." Say "here is the maths. Cutting costs more than it saves. Redeploying costs the same and produces more." Let the numbers do the work.

The real conversation

The board is not wrong to ask the question. AI is genuinely changing how engineering teams operate. The productivity gains are real. Pretending otherwise makes you look like you are not paying attention.

But "AI makes us more productive" and "AI means we need fewer people" are different statements. The first is true now. The second might become true for some roles, eventually. Cutting 20% today based on where AI might be in three years is a bet, and the odds are not good.

Your job as CTO is to turn that bet into a plan. Show where the gains are. Show where you are redeploying them. Put the numbers on the table. Make the CFO's job easy.

And if they still push for the cut after all that, keep your data. You will need it for the rebuild.