Software engineer layoffs: what is really behind them, and what to do

Layoffs in software get explained in two ways, and both are too neat. One says AI is replacing engineers. The other says it is all interest rates and AI is a cover story. I have been on the hiring side of this trade for fifteen years, and I have had to let people go in bad years. What I see is three causes stacked on top of each other, with different weights at different companies.

This page gives no figures, because the counts that circulate are unreliable and go stale within months. The mechanisms are stable, and they are what you need to make a decision.

Why companies cut

Money got more expensive

For a long stretch, capital was close to free. Investors rewarded growth over profit, and the cheapest way to show growth was to hire. Headcount itself became a signal of ambition. When borrowing costs rose, the instruction from investors reversed: show profit, or a path to it. In a software company the payroll is most of the cost base, so that is where the cuts landed.

This is the biggest single cause, and it has nothing to do with whether engineers are useful.

Companies had hired ahead of demand

During the boom, many companies hired for the business they expected to have in three years. Teams were built for products that never found customers. Some firms hired partly to keep talent away from competitors. When growth forecasts were revised, those teams had no work that justified them. Tax rules in some countries also changed how development salaries are deducted, which raised the cost of an engineer on paper for a period and pushed in the same direction.

Unwinding this takes several rounds. Companies rarely cut enough the first time.

AI changed what a team is expected to deliver

This is the newest cause and the hardest to measure. It works in two ways.

The direct way: tasks that used to occupy junior and mid-level engineers now take less time, so fewer people are needed for the same roadmap. I see this in my own shop, and I laid out the arithmetic in will AI replace software engineers.

The indirect way matters more at present. Leadership believes each engineer can now deliver more, and sets headcount on that belief before it has been proven inside their own company. A hiring freeze justified by expected productivity is a real loss of jobs, even if the productivity turns up late or smaller than hoped.

How to weigh the three

My reading, as an argument and with no data behind it beyond what I see in the market: the first two causes explain most of the cuts that have already happened. The third explains more of the hiring that is failing to happen, especially for junior roles, and its weight is rising.

Be sceptical of announcements either way. “We are restructuring around AI” sounds better to investors than “we hired too many people”. A company can also be quietly replacing roles with tooling while blaming the economy. The stated reason tells you about the communications plan. The pattern of which roles are cut, and which are reopened later, tells you the cause.

One test: if a company cuts engineers across every level and function, it is a money decision. If it cuts routine implementation roles, stops hiring juniors, and keeps or adds senior and platform people, the change in tooling is doing the work.

What it means if you run a shop

Layoffs elsewhere change three things for a services business.

Talent is easier to find and harder to choose

More good engineers are available, and they are more open to agency work than they were when product companies were bidding for them. Salary pressure eases.

The trap is hiring because talent is available. A shop that staffs up without signed work pays for the bench out of margin. Hire against contracts, and keep a short list of people you would hire the day the work lands. Many strong people who were laid off now contract, which lets you add capacity per project. The trade-offs are in staff augmentation.

Interview differently too. Years at a well-known company tell you less than they used to. Ask people to scope a vague problem and to review code they did not write. Those are the skills that kept their value.

Client budgets tighten, and the shape of demand changes

A client that has just cut its engineering team has less money and more scrutiny on what is left. Approvals take longer. Open-ended time-and-materials work is the first thing a finance team questions.

The same client also has a roadmap and fewer people to deliver it. That creates demand for a particular kind of offer: a defined result, a fixed price, a clear end date, and no long-term commitment. A team that cannot get headcount approved can often get a project approved. If your proposals are still built around supplying hours, rebuild them around outcomes. Value-based pricing covers how.

Do shrinking in-house teams outsource more or less?

Both happen, and it depends on what you sell.

Clients outsource less of the work that looks like extra hands: general capacity, long-running staff placements, routine feature work. A smaller in-house team with AI tools absorbs much of that.

Clients outsource more of the work that needs a skill they no longer employ: a migration, a security remediation, a data platform, putting AI to work in their own operations. They also outsource maintenance of systems whose original authors were let go. That last category is larger than most owners expect. Somebody has to keep the system running, and the people who understood it have left.

So the question for an agency is which side of that line its revenue sits on. If most of it is extra hands, layoffs at your clients are a threat. If most of it is specific capability with accountability attached, they are a source of work.

What it means if you were laid off

First, the plain facts. Being laid off in a round of cuts says very little about your ability. These decisions are made on spreadsheets, by cost center and reporting line. I have seen excellent people cut because their project was cancelled, and average people kept because their team was not on the list.

Second, the skills still have buyers. The market for full-time roles at product companies is tighter than it was. The market for people who can solve a specific problem for a business that has no one to solve it is healthy.

Sort the practical side first

Read your severance terms carefully, including any non-compete, non-solicitation and IP clauses, since those affect what you can do next. Work out your health cover. Calculate your runway in months, honestly. Decisions made with six months of runway are better than decisions made with six weeks.

Option one: another job

Still the right answer for many people. Aim at roles that include ownership: a system in production, a domain, a team. Roles defined as implementing tickets are the ones under the most pressure. The pillar, is software engineering dead, sets out which parts of the work are holding their value.

Option two: contracting

Contracting is the shortest path back to income. You do roughly the work you did before, for a client, for a fixed period. Price it properly. A salary and a day rate are different things.

A worked example. Say your salary was $150,000. As a contractor you pay your own benefits, taxes, equipment and insurance, and you will not bill every working day. Assume you want $150,000 after roughly $35,000 of those costs, so you need $185,000 in revenue. Assume 46 working weeks and four billable days in five: 46 x 4 = 184 days. $185,000 divided by 184 is about $1,005 a day. A contractor asking $600 a day because it “sounds like a lot” is taking a pay cut.

Option three: a consultancy

A consultancy differs from contracting in what you sell. A contractor supplies capacity. A consultancy sells a result and takes responsibility for it. It pays better and it requires you to find clients, scope work and write contracts.

It suits you if you have a specific expertise, a network that includes people with budgets, and the stomach for uneven income. The strongest opening right now is helping ordinary businesses put AI to work in their operations, because demand far exceeds the supply of people who can actually do it. The step-by-step version is in how to become an AI consultant.

Whichever route you take, the first clients come from people who already know your work: former managers, colleagues who moved on, clients of your old employer where your contract permits it. Write to them individually. The full method is in how to get clients.

If you are the one doing the cutting

Some readers of this page are owners deciding whether to reduce their own team. Do it once, do it early enough that you can afford decent severance, and tell people the real reason. A slow series of small cuts destroys the trust of everyone who stays. I have written out the process in how to lay off employees.

The steady view

Layoffs are painful and personal for the people in them, and I will not pretend otherwise. They are also a normal feature of an industry that hires in booms and corrects afterward. What is different this time is that one of the three causes is structural. Cheap capital comes and goes. Over-hiring gets corrected. The change in how much code one engineer can produce is permanent.

That is a reason to move toward work that needs judgment and accountability, whether you run a shop or work in one. It is no reason to leave the trade. The rest of my thinking on this is collected in the AI hub.