Cost cutting is motion, not a strategy

Frederick Vanbrabant wrote a sharp piece this month called Movement is not progress, about how so many companies mistake activity for strategy. Cut costs, optimize the bottom line, then look up and realize the company is smaller but no clearer about where it is going. I have watched the same pattern from the engineering side, on the code and on the people who keep it alive, and I want to add the part I keep running into.

Movement is easy to measure, which is the trap

A cost cut produces a number this quarter. That is its appeal and its whole danger. You can point at it in a meeting. Strategy, the slower kind, produces almost nothing you can show for a long time, and then produces everything at once. So the reflex under pressure is to reach for the thing you can measure, and Frederick is right that this is a dog catching the car: motion with no idea what to do once you arrive.

The engineering version is familiar. The build is slow, so someone deletes the tests. The number moves, the build is faster, and the thing that made the codebase safe to change is gone. Nobody decided to make the product fragile. They decided to make a number better, and fragility was the invisible cost that did not show up on the same page. This is Goodhart’s Law in one sentence: when a measure becomes a target, it stops being a good measure. Optimize solvency alone and you will trade the company’s future to make this quarter look solved.

The long game needs long-running players

Here is the thing cost cutting hits that rarely makes it onto the spreadsheet: context. The most expensive asset in any product that has been alive for a few years is not the code. It is the accumulated knowledge of why the code is the way it is, which lives in the people who were there when the decisions were made. Why that refund path throws instead of silently succeeding. Why that migration is additive only. Why that one client integration cannot be touched on a Friday.

You cannot hire that back in a quarter. When a cost cut churns out the people who hold it, the org keeps the code and loses the reasons, and the next team spends two years relearning what walked out the door. I have argued before that you do not rewrite a system with a big install base, because the value is in the accumulated context, not the syntax. The same is true of a team. A long game is played by people who stay long enough to accumulate that context, and it compounds only if you let it. This is why I care so much about boring code you ship to your future self: durable code and durable teams are the same bet, that the person maintaining this in three years should not have to be a genius to be safe.

You need two kinds of people, not one

There is a temptation, especially when you are optimizing, to define the ideal employee and hire only that person. It is a mistake, because the work needs two temperaments that rarely live in the same body.

Some people are operators. Give them a defined job and it gets done, reliably, on time, without drama, for years. They are the reason payroll runs and the invoices reconcile and the on-call rotation is covered. Some people are entrepreneurs in temperament, whether or not they ever start anything. They see the thing that is not there yet, they are restless with the status quo, and they will drag the team toward the next version of the product. A company of only operators is efficient and slowly becomes obsolete. A company of only entrepreneurs invents constantly and cannot keep the lights on. You need the blend, and you need to stop treating one temperament as the “real” contributor and the other as overhead. Cost cutting almost always eats the entrepreneurial half first, because their value is the hardest to put on a spreadsheet, and then everyone wonders why the roadmap went quiet.

Raising questions is not a virtue, and neither is silence

The same balance shows up one level down, in how people work. There is a fashion for celebrating the person who asks the hard question in the room, and a matching fashion for celebrating the person who just ships without fuss. Both are half right.

Someone who only ever raises questions and never commits becomes a tax on everyone’s momentum. The meeting that could have ended in a decision ends in three more meetings. But someone who only ever ships, who never stops to ask whether this is the right thing to build, is how you get a beautifully engineered answer to a question nobody asked. I wrote a whole post about the three questions I refuse to start billing code without, and the point of it is not that questions are free. It is that a few of the right ones, asked early, save you from expensive silence later, and then you stop asking and go build. The skill is knowing which mode the moment calls for, and a healthy team has people who lean both ways and the trust to switch.

Cost cutting has a place, as a step, not the plan

I want to be as fair as Frederick was: cutting costs is sometimes exactly right. If the company is genuinely burning more than it can raise, discipline is not optional. The distinction is whether the cut is step one of a plan that has a step two, or whether it is the entire plan dressed up as one. A cut with a vision behind it buys you the room to get somewhere. A cut with nothing behind it just resets the clock until you have to do it again, with less trust from your customers and less context on your team each time. That is the difference between deciding when to build and when to buy as part of a direction, and thrashing between them because the quarterly number demanded a story.

FAQ