When the company cut 20% of my headcount, I increased satisfaction by 22%.

I had been Head of Technology for a few months when the cuts came.

It was 2023. The tech industry was going through a broad correction after years of over-hiring, compounded by inflation and the post-pandemic hangover. My company was not immune. Travel economics had taken a hit, costs were rising, and the decision came down: reduce headcount. In my area, that meant losing 20% of the people.

I was new to the role. The situation was not.

The pressure

The cuts landed on a mix of direct employees and contractors. Most of the reduction came from the contractor layer, which softened the legal complexity but not the human one. Watching colleagues leave, even those on external contracts, is not easy. It happened at a moment when the industry was supposed to be recovering, which made it feel worse.

On top of the headcount reduction, the budget for the area was being compressed on the operational side. The company wanted to protect its investment commitments, so the pressure fell on running costs, which meant people and operational overhead.

Then, on top of everything else, one of my engineering managers resigned. Not as part of the cuts, just timing. The system he was responsible for was one of the most critical in the area. I was new, the team was unsettled, the org was shrinking, and a key leadership position had just gone empty.

The diagnosis

The instinct in situations like this is to minimize disruption. Keep the structure as intact as possible, absorb the cuts quietly, and wait for things to stabilize. I did not do that.

A crisis is a forcing function. It removes the organizational inertia that makes change slow in normal conditions. Things that would have taken a year to negotiate become possible in a week because everyone understands the situation is serious. I decided to use that.

The first thing I did was build a clear ranking of who was essential and who was not. Performance-based, honest, not a political exercise. The people with low contribution, the ones the team was already quietly suffering, went first. The contractors with the lowest impact went first among the external layer. This is a harder call than it sounds when you are new to a role, because you are making judgments about people you have not worked with for long. I made them anyway.

The manager's resignation, which initially looked like an additional problem, turned out to be an opportunity. His position had budget attached to it. That budget was not on the cut list because the position was not being eliminated, he had resigned. I redirected it.

The approach

The budget from the departed manager went to salary increases for the strongest engineers in the area, roughly 20% of the team, the people who were delivering, who were staying, and who deserved to know that even in a difficult moment, performance was recognized. The message was deliberate: the people who work well are the last to suffer in a downturn, not the first. That mattered for retention and for morale in a period when both were fragile.

On the organizational side, I did not replace the manager. Instead, I redesigned the structure around his absence, redistributing ownership across the remaining managers in a way that reduced fragmentation rather than adding it. The previous setup had too many split responsibilities and too many coordination points. Removing one layer and reorganizing around fewer, clearer mandates actually improved how decisions moved through the team.

On the architecture side, I used the reorganization as an entry point. The platform the departed manager had been responsible for was over-engineered, a classic cathedral: too many services, too much complexity, synchronous communication added for academic reasons rather than practical ones. With fewer people to maintain it, that complexity was no longer sustainable.

We did not tackle technical debt in the traditional sense. We did not compile a list of bad code to fix. We compiled a list of services to eliminate. The question was not "what is written poorly" but "what should not exist at all." Services were merged, synchronous dependencies removed where they added latency without value, the overall surface area of the system reduced significantly. Less to maintain, less to break, less cognitive overhead for the engineers responsible for it.

The reorganization, the architectural simplification, and the new team structure were designed together, following Conway's Law deliberately: the shape of the system should match the shape of the team that maintains it. With a smaller, reorganized team, the architecture needed to match.

The result

The number that surprised me most was the eNPS. Employee satisfaction in the area increased 22% compared to the previous year, which had already been a good year under different leadership. This happened during a period of layoffs, budget cuts, and organizational change.

I think the reason is straightforward, even if it sounds counterintuitive. Removing people who were not contributing raised the average quality of the team and removed a source of friction that the remaining engineers had been quietly tolerating. Giving raises to the strongest people sent a clear signal. Simplifying the architecture reduced the daily frustration of working in an over-complicated system. And reorganizing around fewer, clearer mandates gave people a better sense of what they were responsible for.

Zero voluntary departures among senior engineers during the period. Delivery was maintained throughout the restructuring.

The other outcome, which I only understood fully later, is that the cases I described in the first two articles were made possible by this work. The teams that diagnosed and fixed the inventory and booking flow problems were the teams that came out of this reorganization. A cleaner structure, a cleaner architecture, and a motivated core group of engineers turned out to be the foundation for everything that followed.

What I took from this

Crises compress time. Changes that would take a year in a stable environment can happen in a quarter when everyone understands the situation is serious. That is genuinely useful if you know what changes to make.

The default response to a headcount cut is to preserve the existing structure as much as possible and absorb the reduction quietly. That response optimizes for comfort in the short term and makes things harder in the long term, because you end up with the same organizational complexity and less capacity to manage it.

The less obvious response is to treat the reduction as a design constraint and use it to build something leaner than what you had before. That is harder to do when you are new to a role, because it requires making fast judgments with incomplete information. But the alternative, waiting until you know everything before acting, is not available in a crisis.

One more thing. Recognizing strong performance in a difficult moment is not a nice-to-have. It is the most important signal you can send to the people who are staying. They are watching how you treat the situation. What you do in the first few months of a crisis tells them more about what kind of leader you are than anything you will do in the years that follow.