As I complete 9 years at OpenTable this month, I've been reflecting on the most productive time I've spent here — my time building and maturing the Hospitality line of business.
I was a newly minted engineering manager, only a few months into the role, when my manager asked me if I wanted to lead one of the teams in a new line of business: Hospitality. It was an opportunity to work in a "company within a company", and it helped me learn a lot — not only from a technical standpoint, but from business and organizational perspectives as well.
In this blog post, I look at the evolution of Hospitality at OpenTable through the lens of organizational debt - how the friction of past success can become a hurdle for future growth, lock-in - how established patterns can inadvertently narrow our "collective mind," making it harder to see new possibilities, and data model as destiny, inspired by Matt Brown's essay - why shifting from a "transaction-first" (The Reservation) to a "human-first" (The Relationship) mindset was important.
NOTE: This article was originally published in the OpenTable Technology blog.
“Your data model is your destiny.”
When I first read Matt Brown’s essay on this topic, it felt like the perfect articulation of the central challenge my team at OpenTable confronts every day. Brown argues that a company’s core data model – the “center of gravity” – is the dark matter holding its product and market together. It shapes everything: the UI, the pricing, the entire go-to-market strategy, the organization itself.
I oversee the Guest and Retention Marketing engineering teams in the Hospitality line of business at OpenTable, and this idea deeply resonated with me. It makes sense. After all, a technology company is simply a business that models real-world problems in technology and uses it to solve them. From that perspective, it should be obvious that what you choose to model and how you choose to model it, become your core propositions.
For decades at OpenTable, that model was the Reservation. It was our center of gravity, and it served us and our restaurant partners incredibly well. It built an industry and helped us become the leader in it. But as the nature of hospitality evolved — first as the pandemic changed dining habits, and then as the competitive landscape heated up — we realized a deeper truth that was there all along: A reservation is a transaction, but hospitality is a relationship. To model that relationship, we had to confront two forces: the friction of our past success, which I call Organizational Debt, and the narrowing of our collective mind, which I frame as Lock-in.
In engineering, we often talk about technical debt: technical solutions that unblock us today at the cost of slowing us down tomorrow. It is an easy scapegoat. The systems don’t talk back (though in the future they might!), and it’s comparatively easier to solve than the harder, more pervasive kind of debt: the organizational debt.
Organizational debt occurs when your business is so successfully optimized for one worldview that it actively resists a new one. Because our Reservation engine worked so well, every database schema, user experience, pricing strategy, and the design of the organization itself was hardened to support it.
When we wanted to evolve into a relationship-centric model, we weren’t merely tackling a technical problem; we were fighting the gravitational pull of twenty years of success. The tightly coupled systems, the legacy clients, the teams designed for the needs of yesterday, and the product incentives — they were all optimized for the booking.
As a result, we ended up with guest records that were incomplete, messy, or missing entirely, not because of a deliberate choice by us or the users, but as a natural side effect of focusing on something else.
This manifested most clearly in what was built to be frictionless. Every transactional application worships conversion, and conversion is maximized by ease of use. At OpenTable, we spent years optimizing for effortless booking. Knowing someone was coming in tomorrow with a party of 4 at 6:30 PM for Table #21 was more important than knowing who was coming in.
When the product rewarded conversion, users, in the rush of service, either skipped guest profiles entirely, created guest profiles hastily with typos, or forced information in the wrong places, like typing “John Doe VIP” or “John Doe & Family” in the name field. This meant that we could not resolve a “John Doe,” a “John Do,” a “John Doe & Family,” and “Jon Doe,” — each with one visit — into one VIP with four.
Our product prevented us from seeing the relationship.
If Organizational Debt is the weight that slows us down, Lock-in is the cage that limits where we can go.
Lock-in, as beautifully explained by Jaron Lanier in his book You Are Not a Gadget, is broader, more insidious, and far harder to detect.
It is a socio-technical trap where a system starts simple to solve a specific problem, but gradually shapes people as much as the people shape the system. The “truths of yesterday” form the culture of tomorrow. Eventually, the data model becomes baked into the employees’ psyche and codified in every artifact. The user experience is optimized for one action. The monetization strategy, the KPIs, even the company vernacular bakes in certain assumptions and tribal knowledge related to it.
But the lock-in doesn’t stop at the boundaries of the organization. It extends to the users. Software doesn’t just solve a problem for the user, it trains them on how to think about their own business. When a user types “John Doe VIP” in the name field, they aren’t always being lazy, they are being shaped due to the system’s limitations. They’re expressing a latent demand, and modifying their behaviors to workaround the constraints of the system.
What the product taught them created a shared mental model where neither the organization nor the users could unsee the tool outside the context of the booking. Lock-in limits your affordances, your degrees of freedom, as a thinker and a doer.
In fact, it could be argued that the Lock-in is the cause, rooted in human psychology and our relationship with technology, and Organizational Debt is the effect. Lock-in creates a certain degree of comfort with what is, and a sense of fear or hesitation regarding what could be. The debt is the inertia of a mind that has been caged for too long.
To evolve, we had to tackle both.
We navigated this change not by abandoning the past — Reservation still serves as one of the most important pillars of the business — but by spinning up a second center of gravity in parallel.
Our strategy was simple: hire the right people to do the job. Because solutions to some of the most complex organizational problems start with people.
To eliminate lock-in, you need people who could see the alternate universe — one where relationships were more important than transactions. You need Visionaries. Once you build a vision for what could be, you need people who can bring that vision to life. You need people who can execute. When I look back at the people that were most influential in helping us realize the vision I can classify them into a few archetypes: Diplomats to navigate the organizational dynamics adeptly, Drivers to persist through the inevitable pushback at various turns, and Archaeologists to dig into the fossils of our legacy systems and reverse-engineer them.
This leadership strategy allowed us to execute a multi-pronged tactical path to construct the new reality, in which the relationship was at the front and center.
We built a centralized entry point in the backend that aggregates guest data from multiple sources. This shields our clients from the complexity of the past. By migrating our apps to this single source, we achieved data consistency and enrichment across the product and increased our development velocity. When we add new insights to a guest profile — like off-premise order insights — the clients don’t have to change a line of code. They get the enrichment for free through a schema-driven design.
We developed a suite of “Macro-components” — complete guest workflows with state management and business logic built-in. These aren’t just buttons or dropdowns; they are “Guest Search” and “Guest Contact” modules that any team can plug into their own product areas. This ensured that no matter where a developer was working, they were using the same “Guest-first” mental model.
We modernized our data infrastructure using the data lakehouse paradigm and the Medallion architecture to build a consolidated picture of a guest.
We built the team we wanted the product to reflect. We created a dedicated Guest organization with its own PMs, Design, and Engineering functions. By establishing these bounded contexts, we gave the new “Relationship” model room to breathe away from the gravity of the Reservation engine, and work horizontally across all the touchpoints in the product that had Guest information.
Finally, we recognized that richer guest books are not a technical problem alone. Since our product made it easy for messy data to flow in, we had to fix the points of ingestion. We introduced “Good Friction”: a deliberate force of friction that models good behavior.
For example, we found that restaurant users were changing diner contact details as a workaround for notes. We changed the logic: contact details on an OpenTable app booking can only be changed by the diner. If the restaurant needs to add context, we provide a dedicated “Nickname” field. This small change protects the integrity of the platform(and the identity of the guest) while providing the flexibility the restaurant users actually needed.
Matt Brown was right: Your data model is your destiny. But by choosing the right models, you can help shape your destiny.
For an established company, evolving that destiny is a deliberate, challenging, and constant process toward a new truth. It requires an honest self-assessment of your place in the ecosystem, your strengths and weaknesses. It requires identifying the Organizational Debt that slows you down and having the courage to break out of the Lock-in that cages your vision.
We are no longer just a company that manages tables. We are a company that manages relationships. And our data model finally reflects that truth.
Disclaimer: This article represents a personal lookback at the evolution of hospitality at OpenTable. While it highlights the real-world challenges of “Organizational Debt” and “Lock-in”, the perspectives shared here are my own and do not formally represent the company.
Get notified when new posts are published. Once a month, I share thoughtful essays around the themes of personal growth, health & fitness, software, culture, engineering and leadership — all with an occassional philosophical angle.