The Idea in a Nutshell
In warehouse automation, faster implementation does more than reduce project duration: it shortens the feedback loop between planning decisions and operational reality. The sooner assumptions are tested against real performance, the sooner errors can be identified and planning methods improved. This may be an important reason why relatively simple, fast-to-deploy systems can outperform technically more sophisticated alternatives. Projects completed are not the same as learning cycles completed.
Reducing the Delay Between Cause and Effect May Matter More Than New Technology
In warehouse automation, discussions about innovation tend to focus on technology. The spotlight is usually on faster robots, higher storage density, or… just anything different to circumvent patents. In many cases, however, I believe the more powerful lever is not the technology itself, but the speed at which a system can be planned, sold, implemented, and brought into operation.
This is one of the reasons why AutoStore has been so disruptive.
And: no, I’m not working for AutoStore. (Will you please admit they are a decent benchmark for a thing or two?)
There are dozens of warehouse automation companies competing in the market. Many of them offer impressive technologies and products. Yet AutoStore, not exactly breathtaking, with a concept that’s older (and more mature) than the average college student, has consistently outperformed many of these alternatives in the market. The obvious explanation would be that its technology is superior in every respect. But it’s not. I believe one of the key reasons customers choose AutoStore is the pace of project execution; furthermore, I believe that’s one of the reasons why the execution tends to go well.
AutoStore systems can typically be planned and implemented far more quickly than any “traditional” automated solution. Compared with classic shuttle systems, miniload cranes, and other large-scale goods-to-person systems, the technological overhead is lower, as is the project overhead, and the path from concept to operation is significantly shorter. Exotec and, of course, AGV-based solutions also benefit from relatively fast rollout, but AutoStore is perhaps the clearest and most influential example of a system whose commercial success is tied not only to what it does, but to how quickly it can be realized.
That matters for an important reason that is often underestimated. Faster project execution does not merely satisfy customers who want quick results. It also reduces the delay between planning decisions and operational feedback. And that delay is crucial!
In systems engineering, learning depends on feedback. You form assumptions, design a system, implement it, observe its performance, and then compare outcomes with expectations. Ideally, that is how planning capabilities would improve, because that is how errors are discovered. But when the time between design and operational reality becomes too long, the learning cycle starts to break down.
This is a common problem in warehouse automation. A system is planned and offered to the customer, negotiated internally and commercially, then sold after months, sometimes years, then integrated into a building project, then installed, tested, and ramped up. By the time the system is actually operational and its real performance can be evaluated, four, five, or even six years may have passed. Not always, of course, but often enough.
That means that the people who made the original planning assumptions often receive feedback only after a very long delay, if they receive it at all. Some have changed roles or even employers. Even if the organization technically has access to the outcome, the connection between cause and effect has become weak. The planners who made the decisions are no longer close enough to the consequences of those decisions to learn from them properly.
Now, that’s a problem. Because of the significant delays, false assumptions survive far too long. A planner may repeatedly rely on the same weak logic, wrong or misleading analyses, or oversimplified design principles (using averages…) across multiple projects before the real consequences become visible. Therefore, mistakes are repeated. Some time ago, I attended a presentation by a warehouse engineer that I have known for a while. Listening to his presentation, I thought to myself, oh boy, he’s still doing that thing. After 15 years or so in the industry, he should have figured out this is not a good idea. But if the feedback loop is very slow, 15 years isn’t actually very long. It might be no more than three consecutive large projects from planning till hitting decent throughput. Also, customers struggle to detect planning weaknesses early enough. By the time deficiencies become obvious, the system is installed and operational, and corrective action would be expensive and painful. And importantly, when some of the customer’s assumptions don’t hold (e.g., growth rate, customer demography, competitive landscape, product portfolio), planning mistakes might go entirely unnoticed since they either don’t surface at all or can be explained away by reference to changed market conditions.
That’s why reducing the delay between cause and effect can be a competitive advantage. If you can move from concept to operation in a much shorter time, not only can you win customers who appreciate implementation speed, but you also win because you can learn faster. Your planning assumptions will be tested against reality much sooner, helping you identify planning errors earlier. Over time, this creates an enormous organizational advantage. Think about it this way: if you can learn faster than your competition, all other things equal, it is equivalent to having smarter people than your competition. And who wouldn’t agree that’s a good thing?
Many suppliers claim to have completed hundreds of projects. But experience is not a matter of project count; it also depends on how quickly a company can connect planning decisions to project outcomes. If the delay is too long, even a large number of projects may not translate into learning. You may simply end up repeating the same mistakes many times at scale. Put differently, projects completed are not the same as learning cycles completed. A learning cycle is only really completed when a planning assumption meets reality, the difference is understood, and the result changes what the organization does next. And this only happens after project execution, which in this industry can be years after systems engineering.
A long time ago, I published an article (in German only) titled “Der Customer Happiness Manager zur Gewinnung von Wiederholkunden“ [1]. One of the ideas behind the article was precisely that: staying in touch with customers long after project handover to learn what works well and what doesn’t. The Customer Happiness Manager can become a carrier of organizational feedback.
Also, this may be one of the hidden reasons why certain simpler, faster-to-deploy systems have been so successful. Their advantage is that they compress the feedback loop between idea and reality. They allow both supplier and customer to learn faster. And in a field where system design is full of assumptions about order structure, throughput, SKU shapes, labor interaction, replenishment dynamics, and future growth, faster learning may ultimately be more valuable than marginally better technical features.
This also has implications for how companies should think about innovation. The industry often assumes that progress comes from adding functionality, sophistication, and technical depth. But in many cases, progress may come from reducing complexity, shortening execution time, and making feedback available sooner. A system that can be realized in one year instead of two or three may generate more long-term value than a technically more elaborate system that locks everyone into a slow learning cycle.
Let me share a brief anecdote:
An acquaintance of mine, the founder of a successful e-commerce business, once told me a story from the installation of their first shuttle system.
During commissioning, he walked through the warehouse and noticed a technician from the supplier sitting in front of one of the shuttle aisles with a laptop. There were around thirty aisles in total. Curious, he asked what he was doing.
“I’m commissioning the shuttles.” One aisle at a time.
Some days later, my acquaintance walked the warehouse and saw the same guy again, now sitting in front of the next aisle. It turned out that commissioning took roughly a week per aisle.
Used to questioning accepted paradigms, and with a decent understanding of technology, he was astonished. What surprised him was not only that the process was slow (and therefore very expensive), but that everyone seemed to accept such a slow process as normal. On that note: when I witnessed the development of a new shuttle system back in the day, I don’t recall anyone talking about commissioning time. But everyone talked about features. Reducing implementation time does not seem like a very attractive topic for sales engineers, but it can make a difference for them. I’d say most never think about that. Swift implementation is not prominent enough as a feature.
If we want better systems engineering in logistics, we should not focus only on more features, but on faster learning. And one of the most effective ways to achieve faster learning is to reduce the delay between cause and effect.
This Idea Is Not New
The underlying logic here is neither novel nor original. It has been discussed in depth for decades in systems thinking.
Peter Senge, in The Fifth Discipline [2], treats feedback loops and delays as core building blocks for understanding dynamic complexity. In Chapter 5, he argues that systems thinking is about seeing interrelationships rather than linear cause-and-effect chains, and processes of change rather than static snapshots. He also emphasizes that delays between actions and consequences are one of the main reasons systems are misunderstood and learning is inhibited. In his words, delays can lead to overshoot, instability, and poor decisions precisely because people do not receive timely feedback on the effects of their own actions.
That maps quite well onto warehouse automation projects. In long project cycles, the people making design decisions are often separated by years from the operational consequences. When feedback from a decision arrives late, the relationship between action and outcome becomes harder for people to observe and learn from. The result is what systems thinking would predict: weak, slow learning, which in the long run harms competitiveness. That is highly relevant to logistics systems engineering and, in my view, still underappreciated in the industry. The learning process isn’t exactly working in many organizations, partly because much of the relevant systems engineering knowledge is mostly tacit, partly because learning takes so long.
References
[1] Beer, J.E. (2022) “Der Customer Happiness Manager zur Gewinnung von Wiederholkunden,” Dr. Beer Management & Logistik, 20 June. Available at: https://www.beer-management.de/der-customer-happiness-manager-als-mittel-fuer-mehr-wiederholkunden/.
[2] Senge, P.M. (2006) The Fifth Discipline: The Art and Practice of the Learning Organization. Rev. and updated ed. London: Random House Business Books.
