When people discuss why Europe is falling behind China and the United States, they often point to generous welfare systems, working habits, cultural differences and bureaucracy. But in my view, these explanations have yet to address a more fundamental problem: the way Europe’s entire system organizes innovation no longer keeps pace with the technological era.
Two engineering concepts help explain this problem: Waterfall, or sequential development; and DevOps, which connects development, deployment, operation and feedback through continuous iteration.
The Organizational Logic Left by Industrial Success
Europe’s past industrial success was closely tied to precise planning, standardization, clear divisions of labor and strict process control. Manufacturing complex machinery and organizing large-scale production require clear requirements in advance, a design for each stage, and work that proceeds in sequence. In the language of today’s software engineering, this is a Waterfall-style organizational logic: plan, design, produce and deliver, with each stage proceeding only after the preceding stage has met its conditions.
This logic was once highly effective. Precisely because it achieved such enormous success, it gradually extended beyond production itself into corporate governance, national governance and people’s habits of thought. The entire system tends to believe that sufficiently comprehensive advance planning, clear standards and strict approval procedures will produce reliable results in execution.
How Reality Participates in Product Development
Today, however, many technological fields face highly uncertain environments. Whether a product has value, how people will use it, what problems deployment will reveal, which features should remain and which directions should be abandoned can only become clear through actual operation. Even the most comprehensive plan cannot obtain all this information in advance.
DevOps embodies a different production model: propose a product, deploy it, observe its operation, obtain feedback, modify it and deploy it again. Development and use become a continuous cycle, with reality participating in the product’s formation throughout.
The Order of Market Entry and Feedback
I believe this is where the essential difference between technological development in China and the United States, on the one hand, and Europe, on the other, lies.
Technological development in China and the United States tends to bring products into existence first, then drive iteration through the market and deployment. Once a product is in use, its developers keep discovering problems and adjusting direction. Technology and the market evolve together.
Europe places extensive standards, procedures and approval requirements before market entry. A product must first satisfy these requirements before it can enter the market. If it cannot obtain regulatory approval or meet the standards, actual deployment may not happen at all.
People who live in Europe or work in European industry often have a very direct sense of this process-first approach. The progress of a project is continually accompanied by checks on procedures, standards and authority. How quickly a development team can finish its work is only part of the picture. How quickly the entire system allows that work to enter actual use determines the speed of the complete iteration cycle.
The consequences of this difference accumulate. When deployment is delayed, market feedback is delayed as well. Teams cannot promptly discover where their assumptions are wrong, quickly correct their direction or begin the next effective experiment. Waiting for approval consumes both delivery time and the time available for the entire organization to learn.
In highly uncertain environments, much of the crucial knowledge emerges after action. When an institution requires an organization to complete a comprehensive justification before it can act, it can lead people to spend enormous amounts of time defending assumptions that reality has not yet tested.
Why Scrum Cannot Get Moving
This is why Europe’s heavy regulation and procedural systems interrupt the iteration cycle that Scrum requires.
A team may meet every two weeks, arrange its tasks and complete a sprint. But if the product still cannot be deployed, budget changes still require lengthy approval and technical adjustments still have to pass through another series of reviews, the speed of the entire system has not changed. The team has completed a round of development without completing a cycle of deployment, feedback and revision.
Local agility is constrained by the external Waterfall-style system.
From Industrial Strength to Institutional Inertia
When I say Europe lacks a DevOps mindset, I mean that this mindset has not fully become the operating principle of the entire system. The fact that people in Europe have proposed it, or that some companies have adopted it, does not establish that corporate governance, regulation and national governance have been reorganized around continuous iteration. The existence of an idea and its ability to work within actual institutions are two different questions.
When budgets, responsibility, performance assessment and market entry are all organized around procedures established in advance, organizations naturally devote enormous attention to obtaining approval. Over time, completing the prescribed procedure becomes the clearest objective, while quickly validating a product’s value struggles to receive equivalent institutional support.
Europe’s past industrial strengths have been converted into precisely the obstacles that now impede its transition. The planning, standards and control methods that once brought success have become fixed, and they continue to be applied to fields that require ongoing experimentation, deployment and revision. The environment has changed, but the entire system’s basic understanding of work has not changed with it.
This also means that increasing research and development spending or hiring more engineers may not solve the problem. If access to deployment and feedback remains constrained by the same mechanisms, additional resources will encounter the same bottleneck.
Europe should confront the relationship between engineering and institutions. Personnel arrangements, the coordination of interests and policy slogans cannot substitute for an understanding of how the system operates. What needs to change is how governance accommodates uncertainty, how real-world feedback enters decisions promptly, and how products are allowed to improve continuously through use.
In my view, this is the most fundamental mechanism behind Europe’s competitiveness problem: an entire system that succeeded in the Waterfall era is using its old organizational methods to compete in the DevOps era.
If Europe cannot change this operating logic, it will lose one opportunity after another to learn and correct its course. Competitors keep obtaining new knowledge through deployment, while Europe continues to complete the procedures required to enter the next stage. Over time, the gap in the capacity to iterate becomes a gap in products, industries and competitiveness.
(Sadly, I fear this is already becoming reality.)