Familiarity is the enemy: On why Enterprise systems have failed for 60 years

This whole article smells a bit of someone being salty they couldn't sell their software.

Having worked in corporate with vaguely software-buying related stuff, I am confused at why so many small companies think an enterprise would be excited to go with them.

Even if I love your product, how do I pitch to the powers that be that we replace something we are already paying for with this new thing? The company might make billions but I've always had to fight for my budgets.

And tell me again why we should bet our core operations on a two man outfit with six months runway? What happens when you pivot? What happens when our competitor acquires you? What happens when you go on a transatlantic flight and a key expires?

Selling to enterprise early on is a poisoned chalice as well. They have much larger teams, so you'll be dealing with a horde of product owners, compliance specialists, data privacy experts, who might never touch your product but come with excel sheets with 300 rows of gnarly questions. Not to mention just getting the bills paid can be a huge fight.

It will drag you into their orbit, especially if 80% of your revenue is from a single customer. Soon your other customers will start going to someone who actually have time to care about them. And by then there's been a political shift in-house and the new VP of X gets a quote for an outsourcing bundle from his squash buddy at one of the big system integrators. Your line item gets bundled into this to motivate the cost even though it's not even relevant. And that the end of your company.

If you do want to sell, treat the enterprise like an ecosystem of SMEs, find a department or team who are more innovative and sell to them behind the backs of enterprise IT. Once you've entrenched yourself and the users love you, then you can expand to other teams and eventually enterprise IT will be forced to negotiate with you for a license and do the compliance dance. But even so this will take years of effort and luck.

"When the software is being written by agents as much as by humans, the familiar-language argument is the weakest it has ever been - an LLM does not care whether your codebase is Java or Clojure. It cares about the token efficiency of the code, the structural regularity of the data, the stability of the language's semantics across releases."

Isn't familiarity with the language even more the case with a LLM. The language they do best with is the one with the largest corpus in the training set.

    > Clojure was not a hiring barrier - it was a hiring filter.

    > Jane Street Capital's Yaron Minsky once said that contrary to popular belief hiring for OCaml developers was easier because the signal to noise ratio in the OCaml community is so much better than other, more approachable languages.

"Nobody gets fired for buying IBM"

This is still true today. Gartner makes a living out of it. Always prefer buying the "familiar" product rather than being successful with the right solution.

Fortunately history show that those who do their math right actually end up being extremely successful: Google using linux HW for their DB servers, AWS developing their own network equipment and protocols, etc. It takes guts but when it works it leaves competition years behind.

> “…the buyer bought what was familiar to them, not what was right.”

This friction, and the lead dividing solutions from consulting, gave me an idea—-they’re describing conditions where LLM revolution might track with the desktop revolution. Companies, groups within companies and small businesses will DIY it and say good enough.

Yeah, "Nobody every got fired for purchasing IBM"... a story as old as time itself.

But that is the "fear" side of the enterprise sales equation... The "greed" side of it is for the buyer to make the long / short hedge.

The exec who gets the value of the working product can potentially come out shining, when their peers will be furiously backpedalling next year. And this consummate exec can do it by name-associating with their "main bet" which is optically great for the immediate term but totally out of their control (because big corp vendor will drag its feet like every SAP integration failure they've seen), and feeling a sense of agency by running an off-books skunkworks project that actually works and saves the day.

A fine needle to thread for the upstart, but better than standing outside the game.

For context this is the authors website. https://axonlore.com/

So where its fair to say enterprise users buy safety, if he's referring to his own product I would offer the following.

He's in the AI tool space i.e. a better rag. So you're selling to AI developers and developers nearly always go open source first.

If they can't find an open source solution or if they don't even look, they prefer to build it themselves.

For this kind of product most enterprise buyers won't understand its benefits, you have to get the developers interested first.

And finally, in this market, you are 1 prompt away from someone cloning your whole business and calling it openaxon or something like that.

It's a tough time to be a software startup.

Imo, there is a real question about the value of better here. Also, the ability and likelihood of the enterprise to actually leverage better.

This dynamic is not new. Unsophisticated enterprise buyers making bad decisions in a bad way. We haven't had an overwhelming market discipline come down though.

Do these enterprises actually need "good?"

> The wiki is not the thing you add AI to. The wiki is the thing AI replaces.

HN discussions seems to miss this. What LLMs are before you use them for agentic something is a lossy compression of a large text corpus.

The original wikis have to survive so you can have access to the non lossy version though.

A strong appetite for familiarity implies a desire for avoiding effort. Effort - thinking, negotiating, planning, testing. Effort is cost.

The author has a new thing which is different - unfamiliar - and ostensibly better. To a customer, when is a claim for better credible, and when does better really better? How does better measure up as benefit?

The challenge for any product story is to a) illuminate the need - why is the status quo intolerable and b) communicate the benefit tangibly to your audience. That the audience thinks your new thing is worth the effort depends on them understanding the new thing, feeling the need, and feeling good about the effort needed to exploit your thing. You'd like to get to your customer saying "I want that".

I think the specific question for axonlore.com is communicating benefit - how does it impact whatever workflows it serves? The website is a "thing" story, vs a benefit story in my view. I like "enterprise intelligence" as a thing, but it's a tough product. It inevitably implies culture change, and in the decision making space, the key people think they are intelligent enough already -- they want to scale themselves. Someone mentioned "better RAG" - maybe the story is how agents can perform better and more cost effectively. I am not clear that "the market" knows that it needs that yet.

I don't think "familiarity" is the right framing. Application automation, or workflow automation, or whatever the enteprise framing is of agentic solution generation, is to me a question of variance and effort. Variance in the quality of a work product and the net effort to produce it. Variance is the complement to familiar.

- high variance / low effort: prototypes

- low variance / low effort: automating anything repetitive and complicated

- low variance / high effort: demonstrated need for precision and or reliability

- high variance / high effort: when there seems like potential huge upside, or existential risk.

From an IT perspective, enterprise status quo is towards low variance/high effort. The market "want" here now with "agentic" seems to the benefit of low variance/low effort solutions ... where, in enterprise, getting an adequate solution is no longer gated on negotiating with or relying on IT or dev. Ultimately, I think enterprises want low variance, low effort operations -- customers of enterprise customers pay for low variance. I think an Agentic-IT solution question will be how confidently can one iterate and converge to that from whatever is delivered in the first pass. What's the ultimate effort of getting something "right enough".

Understood that this is a pitch for his own platform (which is fair enough), there is a mixture of a few things here which are common tech tropes.

- Enterprise buyers are risk averse and buy the wrong thing - Language X is better because the people that use it are smarter - New tech is difficult for established players

Not really a fresh take but at least it's well written.

> The category has never once, in sixty years, produced a product that reliably made good

In the same article the author was mentioning a few expert systems from the past that were quite obviously successful.

> on the promise printed on its marketing

Ah, _that_ promise. That promise is never fulfilled anywhere nor it is expected to.

The core insight that enterprises select products on familiarity over anything else, is valuable. I’m going to keep it in mind for future customer engagements.

That's just human nature, to prefer what's familiar.

The insight here is that this also still applies to huge enterprise contracts where supposedly more rational decision making should apply.

> an LLM does not care whether your codebase is Java or Clojure. It cares about the token efficiency of the code, the structural regularity of the data, the stability of the language's semantics across releases.

Huh? All current and previous-gen models are most effective when coding in languages with the most test data.

While I agree the newest frontier model may be smart enough to reason at a lower level and be agnostic but its “relatively dumber / less capable” forebears .. need lots of examples to pattern match from.

Familiarity once again!

Eh, it's skipped in "the enemy" section an important bit, that was spelled out in the intro by the buyer, and wasn't listened: if the small vendor goes bust, who maintains the system after? if you plan for in 10 year cycles, greenfield buys look scary

That why vc look favorably to startup which go trough the motion of setting up partner led sales channel. an established partner taking maintenance contracts bridge the disconnect in the lifecycle gap between the two realities.

But no, corporate is bad, I guess.

> your system is not an intelligence tool, it is a compression primitive with a chat interface on top

One should not underestimate a "compression primitive with a chat interface". For certain tasks it is a superpower.

> And they put it succinctly: buying from a small innovative company is brave while buying from a big, well recognised name is an insurance policy and the risk-averse buyer must have the insurance.

As the article notes, the alternatives from the large companies suck. So this is like buying fire insurance from a company that promptly sets fire to your house. You are buying the insurance while knowing you will need it because the disaster is already happening.

> Enterprise knowledge has always been as much a human problem as a technology one. Nobody wants to do the structuring work, and every prior architecture demanded that somebody do the structuring work rather than their actual job

This is correct and very agreeable to everyone, but then after some waffle they then write this:

> Structure, for the first time, can be produced from content instead of demanded from people

These quotes are very much at odds. Where is this structure and content supposed to come from if you just said that nobody makes it? Nowhere in that waffle is it explained clearly how this is really supposed to work. If you want to sell AI and not just grift, this is the part people are hung up on. Elsewhere in the article are stats on hallucination rates of the bigger offerings, and yet there's nothing to convince anyone this will do better other than a pinky promise.

[dead]

[dead]

> The category error under all of this is the assumption that you can take a document library or a wiki [...] and make it intelligent by attaching a language model to it. But you cannot.

Imagine a model with a reliable 100M context window. Then all of a sudden you can.

> The information the intelligent answer needs was never in the wiki in the first place.

Oh well.