The Rationality Trap and Technological Debt: The Evolution of Booking.com in Light of Stijn Bronzwaer's Book 'The Machine'

• • 🇵🇱 Polski

The article analyzes the strategic and technological paradox of Booking.com, where the mechanisms responsible for the company's spectacular success simultaneously became the main barrier to its further evolution. The central thesis posits that the organization fell into a 'local rationality trap': an extremely efficient culture of A/B testing and optimization (evolution from 1 to 1.5) created a systemic rigidity that prevents radical 0→1 innovations. This blockage is threefold: cultural (the dominance of measurable data over strategic imagination), organizational (conflict between local autonomy and the global integration of 'Connected Trip'), and technological. The author argues that technical debt in the form of Perl architecture is not a youthful mistake, but rather the 'sediment of success' – a system so deeply integrated with business processes that replacing it while fully operational resembles trying to change an engine in a moving car. Consequently, Booking.com faces a fundamental challenge: how to transform from a specialized accommodation booking machine into an integrated travel ecosystem when every tool used to measure success rewards safe improvements over the risky creation of something new.

The Rationality Trap and Technological Debt: The Evolution of Booking.com in Light of Stijn Bronzwaer's Book 'The Machine'

Introduction

This article analyzes the strategic paradox of Booking.com, where the very mechanisms of its success have become barriers to growth. Discover how a culture of extreme optimization can lead to systemic rigidity.

We will examine the trap of local rationality, which hinders the transition from incremental improvements (evolving from 1 to 1.5) to radical 0 $\to$ 1 innovations. The text explains the impact of technical debt on business strategy.

Gil lian Tans and the Trap of Institutional Memory

Gil lian Tans, CEO from 2016 to 2019, embodied the company's ethos: informality and a skepticism toward corporate rituals. Her primary asset was deep institutional memory, supported by an informal network of influence known as the Dutch Mafia.

While this rooting helped maintain an entrepreneurial culture, it also created a closed interpretive circle. As a result, the organization may have struggled to challenge beliefs shaped by past successes.

An example is the conflict between the autonomy of the Amsterdam office and headquarters' drive for global brand portfolio integration, which hampered synergy within the holding company.

The Local Rationality Trap and the Optimization Barrier

Booking.com has perfectly mastered the optimization of existing systems, yet it has fallen into the trap of local rationality. The company favors projects with measurable BPD growth, which blocks 0 $\to$ 1 innovations whose value cannot be quantified via A/B testing.

Paradoxically, vast amounts of hotel data make creating new services more difficult. Predictive models work within known parameters but are useless when building an entirely new business category.

Consequently, new products compete for resources with the profitable core. Every investment in an uncertain future is viewed as an opportunity cost—a lost chance to improve conversion rates.

The Clash Between Experience Models and Distribution Machinery

In response to the rise of Airbnb, Booking.com leveraged its scale and distribution machinery to rapidly assimilate alternative accommodations. While Airbnb offered a narrative of authenticity, Booking focused on reducing booking friction.

The transition to the Connected Trip model (flights, attractions) proved more difficult than expanding into accommodations. This shift required interoperability across different markets and a reconstruction of technological foundations.

The primary obstacle became technical debt rooted in the Perl language. Although the system was efficient, it became a core rigidity, limiting the ability to quickly integrate new business verticals.

Summary

The story of Booking.com demonstrates that the most dangerous legacy is a system that still works brilliantly. Current efficiency becomes an argument against change, turning success into an invisible prison.

Migrating to the cloud does not eliminate architectural debt, as code preserves encoded business theory. The real challenge lies in the ability to dismantle the bridge that still carries us before it leads nowhere.

📚 Based on

The Machine
()
NRC Boeken
ISBN: 9789083629605

👤 About the book's author

Stijn Bronzwaer

NRC

Stijn Bronzwaer (born 1981 in Heerlen, Netherlands) is a Dutch investigative journalist and author specializing in the technology sector, corporate governance, and startups. He studied communication science at Radboud University Nijmegen and completed journalism programs at Utrecht University and the University of Amsterdam. In 2007, he joined the Dutch national daily newspaper NRC Handelsblad (and nrc.next), where he held various editorial positions including economics reporter, media editor, and deputy editor-in-chief between 2016 and 2019. During his editorial leadership, Bronzwaer co-founded NRC Vandaag, one of the Netherlands' most prominent daily news podcasts. As a technology reporter focusing on digital enterprise and artificial intelligence, Bronzwaer co-authored the high-profile investigative account of Booking.com with colleagues Merijn Rengers and Joris Kooiman, which won the prestigious Dutch-Belgian De Loep award for investigative journalism in 2022.

Mind map: The Rationality Trap and Technical Debt at Booking.com

📖 Glossary

Dług technologiczny
Sytuacja, w której szybkie i tymczasowe rozwiązania programistyczne z przeszłości utrudniają wprowadzanie zmian w przyszłości, zwiększając koszt rozwoju.
Pułapka racjonalności lokalnej
Błąd decyzyjny polegający na odrzucaniu innowacji, ponieważ w krótkim terminie i według obecnych mierników wydają się one gorsze od istniejących rozwiązań.
Zależność od ścieżki (Path Dependency)
Zjawisko, w którym wcześniejsze decyzje techniczne lub organizacyjne ograniczają przyszłe możliwości wyboru, nawet jeśli stają się one nieefektywne.
Organizacje oburęczne (Ambidextrous Organizations)
Firmy zdolne do jednoczesnego efektywnego zarządzania obecnym biznesem (eksploatacja) i tworzenia zupełnie nowych produktów (eksploracja).
Lift-and-shift
Strategia migracji do chmury polegająca na przeniesieniu aplikacji w niezmienionej formie, bez przebudowy jej architektury pod środowisko cloud.
Interoperacyjność heterogenicznych rynków
Zdolność różnych systemów (np. loty, hotele, restauracje) do współpracy i wymiany danych w celu stworzenia spójnego doświadczenia użytkownika.

Frequently Asked Questions

Who was Gillian Tans, and how did her deep roots in the Booking.com culture influence the company's management?
Gillian Tans is the former CEO of Booking.com, who took over the position in 2016 after a long career within the organization. Her deep rooting in the company's culture and institutional memory lowered coordination costs through networks of trust, but simultaneously may have created a closed interpretive circle that made it difficult to challenge existing beliefs.
Why does a company so effective at improving its products struggle to create entirely new services?
The company relies on historical data and the optimization of existing systems, which gives it a cognitive advantage over creating new services. New projects must compete with products that have been refined for years, and a culture requiring experimental proof of value makes it difficult to implement solutions whose future benefits cannot yet be measured.
How did Booking.com react to the rise in popularity of alternative accommodations, and how did its strategy differ from Airbnb's approach?
Booking.com responded to the rise in popularity of alternative accommodations by expanding its offering to include homes and apartments, based on user behavior analysis as well as its own scale and distribution channels. Unlike Airbnb, which built a narrative of authenticity and local experiences, Booking.com focused on being a tool that reduces friction in the booking process.
Why did Booking.com have difficulty introducing new services, such as flights or attractions, despite its success in the accommodation sector?
Booking.com optimized its processes and tools for a specific hotel transaction, which created a so-called path dependency limiting future possibilities. Introducing flights or attractions required the integration of entirely different supply architectures, transactional rhythms, and accountability models.
Was the Connected Trip project a total failure, and why is it so difficult to implement completely new products at Booking.com?
The Connected Trip project was not a total failure but remains part of the company's long-term strategy, although it faces difficulties and delays. Implementing new products at Booking.com is hindered by the high profitability of the current business and an idea evaluation system that favors predictable gains over risky strategic investments.
Why can having a vast amount of hotel booking data paradoxically make it harder to introduce radical innovations at Booking.com?
The vast amount of data creates an epistemic inequality, making new hypothesis-based projects seem less 'scientific' than the mature business. Furthermore, historical data serves to predict behavior within a known space, rather than to create entirely new travel models.
Why could Booking.com as a company be in conflict with its own holding company despite excellent financial results?
The conflict stemmed from the difference between Booking.com's local optimization and the global optimization of the holding's portfolio. While headquarters aimed for brand integration and leveraging synergies, Booking.com's management feared that interference in their model would weaken the group's most effective element.
Why does a company so successful at optimization struggle with creating entirely new products?
The company has an organizational system specialized in scaling innovations compatible with the existing core, which makes it difficult to build ventures requiring a reconstruction of the foundations. Additionally, a barrier is the historical technological architecture, which over time became inflexible and transformed a core competence into what is known as a core rigidity.
Why were A/B testing and current technology alone not enough to create a new travel ecosystem?
Current technology and A/B tests were insufficient because they served to optimize known behaviors (risk management) rather than to create a new strategy under conditions of deep uncertainty. Realizing the 'Connected Trip' vision required pushing the boundaries of possibility and rebuilding an outdated system architecture that had become a bottleneck for the necessary integration of products and data.
Is using an old programming language (Perl) the main cause of Booking.com's technological problems?
No, the use of older technology itself is not the primary cause of the problems, as the Perl-based system reliably processes a vast number of transactions. The key challenge is the growing technical debt and architectural complexity, which make implementing business changes involve disproportionately high effort and risk.
How does the old technological architecture affect team structure and the ability to introduce new services at Booking.com?
The old, tightly coupled technical architecture forces many teams into constant coordination, which limits their autonomy and slows down the pace of experimentation. Additionally, outdated business models encoded in the system make it difficult to implement new services, as they require alignment with obsolete assumptions regarding, for example, accommodations.
Why can't a company with resources like Booking.com simply rewrite its old system from scratch?
The old system contains a vast amount of proven business knowledge and handles critical processes that cannot be recreated without risk. The cost of replacing it is drastically high due to the network of dependencies and the fact that the platform must operate continuously, making it impossible to shut down temporarily for a code rewrite.
Why is removing old code and modernizing architecture so difficult and risky in a large company?
Modernizing legacy code is risky because experienced engineers are aware of numerous historical edge cases that, if removed, could break the system. Additionally, a lack of documentation turns legacy systems into "black boxes," and abrupt changes carry the danger of widespread and severe failures (the so-called blast radius).
Did migrating to Google or Amazon cloud solve Booking.com's technological problems?
The cloud alone does not solve architectural debt, as a lift-and-shift migration merely moves problems from one server to another. However, it can help in specific areas; for example, the search ranking system, where moving to AWS enabled more flexible testing of machine learning models and resource scaling.
Why does a company that deploys small changes so quickly struggle with rebuilding its technological foundations?
Deploying small surface-level changes quickly is easier than rebuilding foundations because deep architecture is more complex and carries a higher risk of critical system failure. The more value a system generates and the more functions depend on it, the harder it becomes to radically change it without interrupting business continuity.
Why can a system that still earns great money and works well simultaneously be the greatest threat to the company's future?
A system that continues to perform well financially can be a threat because its success provides arguments against radical changes and rebuilding. Over time, it becomes a costly legacy that makes adapting to a changing environment increasingly expensive.

🧠 Thematic Groups

Tags:

More in: Szkatułka kosztowności

 Content is created by Fundacja Dobre Państwo.
Edited and published by APA ONE, the Foundation's own AI-based editorial system.