For roughly a decade now, executives at industrial companies have been instructed to "be more like software companies." The instruction has produced, in most cases, an embarrassing set of imitations. Open-plan offices. Hoodies in the boardroom. A ping-pong table near the executive suite. The occasional design sprint, deployed to redesign a procurement form. None of this has produced the operating capability that the original instruction was pointing toward. The cultural surface has been copied. The structural source of the advantage has not.
This is not a failure of effort. It is a failure of diagnosis. The software companies that became great did not become great because of their offices or their dress code. They became great because they built operating systems for their businesses that had four specific properties: they ran on short cycles, they instrumented everything they shipped, they had explicit mechanisms for translating learning into the next cycle, and they were ruthless about killing things that did not work. These are not cultural attributes. They are management practices. They are copyable. Almost nobody in industrial leadership has actually copied them.
What is worth understanding is which specific practices produced the productivity gap, why those practices are transferable to industrial settings, and which ones are not.
- Software companies in the SaaS public peer set release product updates an average of over 100 times per year; the median industrial product company releases two to four times per year (Productivity Lab, OpenView).
- Among companies that have measured digital transformation outcomes, those with weekly operating cadences outperform those with quarterly cadences by roughly 40 percent on revenue growth and 60 percent on time-to-decision (MIT CISR, 2023).
- The single largest predictor of digital transformation success in legacy industries is not technology investment. It is the adoption of iterative operating rhythms (BCG Digital Acceleration Index, 2024).
The cadence
The most consequential and least-discussed difference between software companies and industrial companies is the speed at which the company learns. A modern software company will plan in two-week cycles, ship continuously, review weekly, and adjust monthly. The number of decisions the organization makes in a year is an order of magnitude higher than at an industrial peer, and the number of corrections is higher still. Each cycle produces information that the next cycle responds to. The information compounds.
An industrial company runs on cycles that are much longer. Annual planning. Quarterly review. Monthly close. The information that emerges from operations passes through a hierarchy that summarizes and delays it. By the time a quarterly review concludes that something is not working, the team responsible has been working on it for thirteen weeks without correction. Multiply this by the number of initiatives running in parallel, and you have an organization that is making decisions on information that is structurally three months stale.
The fix is not to copy the two-week sprint. Industrial processes have physical realities that do not collapse to weekly cycles. The fix is to identify which decisions can be moved to shorter cadence without breaking anything physical, and to move them. Pricing decisions. Channel decisions. Marketing decisions. Hiring decisions. Account strategy decisions. None of these have physical constraints requiring a quarterly review. They are reviewed quarterly because that is the inherited rhythm, not because the work requires it.
The chart shows what most industrial executives intuit but do not measure. The software company is not necessarily smarter. It is making four to five times as many calls in the same year, which means it is making four to five times as many small corrections, and small corrections compound.
The instrumentation
The second practice is the discipline of measuring what was shipped. Modern software companies treat any deployment without measurement as malpractice. They have built telemetry systems that report, within hours, what changed and what effect the change produced. The product manager does not have to wait a quarter to know whether the feature worked. The data exists by Friday.
Industrial companies routinely ship significant operational changes (a new pricing model, a new sales playbook, a new product line, a new distribution partner) with no measurement plan at all. The change goes live. The team moves to the next change. Six months later, in a strategy review, someone asks how the change performed, and the answer is a story constructed from memory and circumstantial evidence. The team has lost the chance to learn from the deployment.
This is not a technology gap. The data infrastructure exists at most industrial companies of any scale. The gap is a discipline gap. The decision to measure has to be made before the change is shipped, and the metric has to be defined in a way that the question "did this work" can be answered. Companies that have internalized this practice can answer the question. Companies that have not cannot, even when the data is available, because nobody specified in advance what would constitute the answer.
The feedback loop
The third practice is the explicit translation of learning into the next cycle. Software companies run retrospectives. The retrospective is not a meeting where the team narrates what happened. It is a meeting where the team produces specific changes to how they work, based on what happened, that are implemented in the next cycle. The output of a retrospective is a list of decisions, with owners, that affect what gets done next.
The industrial equivalent of a retrospective is the post-mortem, and it has been largely captured by safety reviews. Operational learning happens informally, around the coffee machine, and it does not produce documented changes in how the next cycle runs. The result is that the same problems recur, year after year, with the same people privately understanding why they recur and the organization collectively unable to fix them.
The fix is structural. The retrospective practice has to be installed as a recurring rhythm with an explicit output. "What did we learn this cycle, and what are we going to do differently in the next one." The output is documented. The next cycle's plan reflects it. If the same learning emerges twice without action, the failure to act is itself surfaced as a topic.
The difference is not the technology stack. It is the rate at which the company corrects itself.
The willingness to kill
The fourth practice is the willingness to kill things that are not working. Software companies have institutionalized this. Products get sunset. Features get removed. Teams get reorganized. The fact that a thing was launched does not entitle it to permanent resources. The default disposition is that any initiative needs to be earning its continued investment, and an initiative that has stopped doing so will be cancelled.
Industrial companies tend to have the opposite default. Once something has been launched (a product line, a regional office, a customer segment, a process), it has a constituency that defends its continued existence. The constituency is, in many cases, the people whose careers are attached to it. Killing it is socially expensive. So it persists, absorbing resources that could have been deployed against the things that are working.
The cost of this asymmetry is enormous and rarely measured. A company that cannot kill its bottom decile of initiatives is a company that is structurally underweighting its top decile. The capital is still going to work, but it is being spread across too many activities, most of which are not earning their cost of capital. Over a decade, the difference between a company that aggressively prunes and a company that does not is the difference between compounding returns and indistinct mediocrity.
What this looks like at an industrial company
The good news is that none of the four practices require software-company technology to adopt. They are management decisions. The industrial companies that have made measurable progress on this have done a small set of specific things.
They have moved their commercial operating rhythm from quarterly to weekly for the decisions that do not have physical constraints. The CEO and the commercial leadership meet for ninety minutes every Monday, with a structured agenda. Pricing decisions, channel decisions, account strategy decisions get made and committed in that meeting. The rhythm produces about 50 commercial decisions per quarter, instead of the 6 to 8 that would have come out of the quarterly review.
They have introduced a measurement requirement on operational changes. Any change of meaningful scope requires a one-page measurement plan before it can be deployed. The plan specifies the metric, the baseline, the expected effect size, and the review date. Changes without plans do not get deployed. The discipline takes about six months to install and is durable thereafter.
They have installed quarterly portfolio reviews of all initiatives. Each initiative reports against its measurement plan. Initiatives that have failed their criteria are killed. Initiatives that have succeeded are scaled. Initiatives that are uncertain are continued for another quarter with revised criteria. The review is the forcing function that converts learning into resource reallocation.
None of this is glamorous. None of this requires a new technology platform. All of this is observable in the operating systems of the companies that have closed the gap. It is also observable, in its absence, in the companies that have not.
The lesson from software is not the hoodie. It is the cadence. Companies that copy the surface get nothing. Companies that copy the system get a decade of compounding.