[{"data":1,"prerenderedAt":38},["ShallowReactive",2],{"blog-post-cost-cutting-is-motion-not-a-strategy":3},{"slug":4,"title":5,"description":6,"date":7,"updated":8,"tags":9,"pillar":14,"draft":15,"image":16,"imageAlt":17,"html":18,"markdown":19,"faq":20,"readingTimeText":36,"readingTimeMinutes":37},"cost-cutting-is-motion-not-a-strategy","Cost cutting is motion, not a strategy","Cutting costs moves the numbers without moving the company forward. The long game is won by people who stay long enough to hold context, and by teams that balance operators with entrepreneurs.","2026-07-13T00:00:00.000Z",null,[10,11,12,13],"strategy","teams","engineering-leadership","long-term","products-that-last",false,"/blog-covers/products-that-last.png","Products that last cover","\u003Cdiv class=\"post-tldr\">\u003Cdiv class=\"post-tldr-label\">TL;DR\u003C/div>\u003Cp>Cutting costs moves the numbers, not the company. The long game is won by people who stay long enough to hold context, and by teams that balance operators with entrepreneurs, and questions with shipping.\u003C/p>\u003C/div>\n\u003Cp>Frederick Vanbrabant wrote a sharp piece this month called \u003Ca href=\"https://frederickvanbrabant.com/blog/2026-07-10-movement-is-not-progress/\">Movement is not progress\u003C/a>, 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.\u003C/p>\n\u003Ch2 id=\"movement-is-easy-to-measure%2C-which-is-the-trap\" tabindex=\"-1\">Movement is easy to measure, which is the trap\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>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: \u003Ca href=\"https://en.wikipedia.org/wiki/Goodhart%27s_law\">when a measure becomes a target, it stops being a good measure\u003C/a>. Optimize solvency alone and you will trade the company’s future to make this quarter look solved.\u003C/p>\n\u003Ch2 id=\"the-long-game-needs-long-running-players\" tabindex=\"-1\">The long game needs long-running players\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>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 \u003Ca href=\"/blog/you-dont-rewrite-a-plugin-with-a-big-install-base\">you do not rewrite a system with a big install base\u003C/a>, 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 \u003Ca href=\"/blog/boring-code-is-a-feature-you-ship-to-your-future-self\">boring code you ship to your future self\u003C/a>: 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.\u003C/p>\n\u003Ch2 id=\"you-need-two-kinds-of-people%2C-not-one\" tabindex=\"-1\">You need two kinds of people, not one\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Ch2 id=\"raising-questions-is-not-a-virtue%2C-and-neither-is-silence\" tabindex=\"-1\">Raising questions is not a virtue, and neither is silence\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>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 \u003Ca href=\"/blog/three-questions-before-i-write-billing-code\">the three questions I refuse to start billing code without\u003C/a>, 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.\u003C/p>\n\u003Ch2 id=\"cost-cutting-has-a-place%2C-as-a-step%2C-not-the-plan\" tabindex=\"-1\">Cost cutting has a place, as a step, not the plan\u003C/h2>\n\u003Cp>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 \u003Ca href=\"/blog/build-vs-buy-for-billing\">when to build and when to buy\u003C/a> as part of a direction, and thrashing between them because the quarterly number demanded a story.\u003C/p>\n\u003Cdiv class=\"post-takeaway\">\u003Cdiv class=\"post-takeaway-label\">The takeaway\u003C/div>\u003Cp>Movement is not progress, and a company that only knows how to cut is only ever moving. The long game is won on the things that do not fit neatly in a quarter: the people who stay long enough to hold the context, the balance between operators who keep it running and entrepreneurs who push it forward, and the judgment to know when to raise a question and when to close it and ship. Cut when you must, but cut as one move inside a plan, not as the plan. The scale going down is not the same as getting stronger.\u003C/p>\u003C/div>\u003Ch2 id=\"faq\" tabindex=\"-1\">FAQ\u003C/h2>\n\u003Cdiv class=\"post-faq\">\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">Are you saying companies should never cut costs?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>No. Cutting costs is sometimes necessary and sometimes correct. The argument is that a cut should be one step inside a plan that has a next step, not the whole strategy. A cut with no vision behind it just resets the clock.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">What does “long-running players” actually mean?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>People who stay on a product long enough to accumulate the context of why it is built the way it is. That knowledge is the most expensive thing to rebuild and the first thing lost when you churn people to save money.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">Isn’t hiring only “entrepreneurial” people better for growth?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>No. A team of only entrepreneurs invents constantly but cannot keep the lights on, and a team of only operators runs smoothly into obsolescence. You need both temperaments, and you need to value the one that is harder to measure.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">How is this related to writing durable code?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>Directly. Durable code and durable teams are the same bet: that the person maintaining this in three years should not need to be a hero to be safe. Cost cutting that destroys context breaks both.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">Who is Frederick Vanbrabant and why reference him?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>He writes about the intersection of enterprise architecture, product, and business strategy. His post \u003Ca href=\"https://frederickvanbrabant.com/blog/2026-07-10-movement-is-not-progress/\">Movement is not progress\u003C/a> is what prompted this one, and this is my engineering-side companion to his argument.\u003C/p>\u003C/div>\u003C/div>\u003C/div>","\n## TL;DR\n\nCutting costs moves the numbers, not the company. The long game is won by people who stay long enough to hold context, and by teams that balance operators with entrepreneurs, and questions with shipping.\n\nFrederick Vanbrabant wrote a sharp piece this month called [Movement is not progress](https://frederickvanbrabant.com/blog/2026-07-10-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.\n\n## Movement is easy to measure, which is the trap\n\nA 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.\n\nThe 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](https://en.wikipedia.org/wiki/Goodhart%27s_law). Optimize solvency alone and you will trade the company's future to make this quarter look solved.\n\n## The long game needs long-running players\n\nHere 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.\n\nYou 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](/blog/you-dont-rewrite-a-plugin-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](/blog/boring-code-is-a-feature-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.\n\n## You need two kinds of people, not one\n\nThere 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.\n\nSome 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.\n\n## Raising questions is not a virtue, and neither is silence\n\nThe 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.\n\nSomeone 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](/blog/three-questions-before-i-write-billing-code), 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.\n\n## Cost cutting has a place, as a step, not the plan\n\nI 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](/blog/build-vs-buy-for-billing) as part of a direction, and thrashing between them because the quarterly number demanded a story.\n\n## The takeaway\n\nMovement is not progress, and a company that only knows how to cut is only ever moving. The long game is won on the things that do not fit neatly in a quarter: the people who stay long enough to hold the context, the balance between operators who keep it running and entrepreneurs who push it forward, and the judgment to know when to raise a question and when to close it and ship. Cut when you must, but cut as one move inside a plan, not as the plan. The scale going down is not the same as getting stronger.\n\n## FAQ\n\n**Are you saying companies should never cut costs?**\nNo. Cutting costs is sometimes necessary and sometimes correct. The argument is that a cut should be one step inside a plan that has a next step, not the whole strategy. A cut with no vision behind it just resets the clock.\n\n**What does \"long-running players\" actually mean?**\nPeople who stay on a product long enough to accumulate the context of why it is built the way it is. That knowledge is the most expensive thing to rebuild and the first thing lost when you churn people to save money.\n\n**Isn't hiring only \"entrepreneurial\" people better for growth?**\nNo. A team of only entrepreneurs invents constantly but cannot keep the lights on, and a team of only operators runs smoothly into obsolescence. You need both temperaments, and you need to value the one that is harder to measure.\n\n**How is this related to writing durable code?**\nDirectly. Durable code and durable teams are the same bet: that the person maintaining this in three years should not need to be a hero to be safe. Cost cutting that destroys context breaks both.\n\n**Who is Frederick Vanbrabant and why reference him?**\nHe writes about the intersection of enterprise architecture, product, and business strategy. His post [Movement is not progress](https://frederickvanbrabant.com/blog/2026-07-10-movement-is-not-progress/) is what prompted this one, and this is my engineering-side companion to his argument.\n",[21,24,27,30,33],{"q":22,"a":23},"Are you saying companies should never cut costs?","No. Cutting costs is sometimes necessary and sometimes correct. The argument is that a cut should be one step inside a plan that has a next step, not the whole strategy. A cut with no vision behind it just resets the clock.",{"q":25,"a":26},"What does \"long-running players\" actually mean?","People who stay on a product long enough to accumulate the context of why it is built the way it is. That knowledge is the most expensive thing to rebuild and the first thing lost when you churn people to save money.",{"q":28,"a":29},"Isn't hiring only \"entrepreneurial\" people better for growth?","No. A team of only entrepreneurs invents constantly but cannot keep the lights on, and a team of only operators runs smoothly into obsolescence. You need both temperaments, and you need to value the one that is harder to measure.",{"q":31,"a":32},"How is this related to writing durable code?","Directly. Durable code and durable teams are the same bet: that the person maintaining this in three years should not need to be a hero to be safe. Cost cutting that destroys context breaks both.",{"q":34,"a":35},"Who is Frederick Vanbrabant and why reference him?","He writes about the intersection of enterprise architecture, product, and business strategy. His post Movement is not progress is what prompted this one, and this is my engineering-side companion to his argument.","8 min read",8,1785070532919]