Darwin’s Angels – Hospitality Net

Sell the future of an industry to someone who doesn’t want to change.

I’m borrowing that quote from Gleb Vorobiev, founder of a students’ club at Vienna’s tourism academy, who used it to describe SaaS sales in hospitality.  And he’s right. Uncomfortably so.

It extends far beyond mere sales. With the right skill set, you can sell change in the form of tools. Making that change stick – in processes, habits, and decisions – is something else entirely.

Software happens

Software is reshaping entire industries. Not gradually – but in ways that were unthinkable when many of today’s hoteliers learned their trade. AI would be the obvious example. But since we’re still somewhere between hype and hallucination, I’ll leave it aside.

Narrowly applied to the lodging industry, the tech stack usually builds on a PMS, the property management system. What is added onto that core system varies, depending on the type of operation. But it all rests on this single pillar that may so easily be misunderstood, because it does not really “manage” your property. It is nothing but a tool to manage your property.

You can fry a steak by setting your kitchen on fire. Or you can use the induction stove – if you actually put the pan on it.

“I bought Software. Now Software happens.” That seems to be a common expectation.

No matter how often thought leaders tell us that tool acquisition does not equal transformation, I see the “we have a system now” mindset all too often, and across various types of operators. A mindset that is framed in checkboxes to tick, in buttons to push at the right time in a predefined sequence. It reminds me more of the way you operate a weaving machine, or some sacred ritual. This even permeates many operators’ approach to using chatbot support: “If I say the right words, at the right time, in the right pitch, the genie will work its magic”. Except, it doesn’t. So they phone the vendor.

Genie in a button

Across various software implementations, I have been told – or given to understand in eloquent ways – to “stuff the technical explanations, just tell how it works”. The expectation clearly is that the software were the actual operator, which its owner can call upon to work its magic by rubbing it the right way. So, by extension, it’s the software vendor’s responsibility to make everything… “run”. Didn’t the vendor promise automation? So there.

I have the hardest time getting any system implemented the way it really benefits the owner to the fullest extent, when there is no interest in the set up, the detail config, the logic behind the system’s design and one’s own processes. Implementation is one of the later phases of successful software projects, with process design ideally being the first – before the selection even starts. If processes are not clearly envisioned, evaluated and designed, the quest for the “best match” software becomes one of pure luck. And oftentimes, the degree of success in implementing very much depends on the external partner and their ability to kick off process design on the go.

Knowing where to click is not the same as knowing what you’re doing.

Or what you want to achieve. Or whether you even should. Because nobody really owns neither the process, nor the system, nor the outcome. What everybody seems to know is who has the responsibility. What is crucially lacking is accountability which comes with real ownership.

Not trying to make saints out of staff or vendors. Both can be equally disinterested in assuming ownership, sitting firmly inside their comfortable boxes. Staff care for leaving at 5, vendor reps care for leaving with a signature. But mostly they are simply not in a any position to take ownership.

Owning your project means “owning” that you don’t get simplicity by skipping complexity. You get dependency. Understanding the system is what turns it into a tool that actually supports you in managing your property. Without that, you’re not using software – you’re negotiating with it.

And to be fair, this isn’t laziness. It’s something else.

FOGO

Running a hotel is not a controlled environment. It’s constant interruption, shifting priorities, and a steady stream of decisions that all feel urgent. In that setting, learning a system rarely feels like progress – it feels like a detour.

There’s also history. Many have seen systems come and go, promises made and quietly abandoned. So the instinct is not to invest, but to minimize exposure. Use what is necessary. Avoid what is unclear. Move on.

And then there’s risk. Configuration means responsibility. Responsibility means the possibility of getting it wrong – and in operations, “wrong” has immediate consequences. So it feels safer to stay on the surface, to operate rather than to understand.

None of this is irrational. But it does come at a cost. Where “fear of missing out” sells mere acquisition as the start of transformation, “fear of going on” sells superficial use as its completion. Worst case, one can end up having paid much for software one does not really make use of.

It’s not ignorance. It’s not even resistance. It’s a preference for continuity over uncertainty.

Darwin’s Angels

Time and again, I meet operators who want new software implemented without changing a single habit, process, or assumption around it. That, in a sense, is the quiet logic of Darwin’s Angels: a hope that the environment can change while one’s own behaviour does not.

The problem is that continuity is no longer on offer. The environment changes anyway – through competition, rising complexity, shifting guest expectations, cost pressure, and yes, technology. Refusing to engage with that change does not preserve stability. It only delays adaptation.

Transformation is not an event. It is adaptation under pressure. And in that sense, hospitality is no different from any other industry: not the strongest survive, but the fittest. The ones that adapt quickly enough, and make that effort count. Sometimes to stay ahead of the pack. Sometimes to defend a profitable niche.

New technology does not create that pressure by itself. But it arrives just in time to answer it. The challenge is the willingness to engage with it.

Software doesn’t create change.

People do.

Or don’t.