I Have a Personal Rule: No Jargon Allowed

A few years ago I caught myself in a meeting saying the words "agentic RAG pipeline with human-in-the-loop orchestration" to a managing director who, I could see, had stopped listening three syllables in. He nodded politely. He had no idea what I meant. And honestly, neither did he need to. That was the day I made a personal rule: no jargon allowed. Explaining AI in plain language is not a courtesy — it is the actual job.

I stopped talking about technology and started talking about the problem the person in front of me actually has. The change in how those conversations went was almost embarrassing. Deals that used to stall in a fog of acronyms suddenly moved, because for the first time the client could tell whether I understood their business or was just performing expertise at them.

Why jargon is so tempting — and so lazy

Let me be fair to my younger self. Jargon is seductive for a reason. It is fast: one acronym can stand in for a paragraph. It signals membership; if I say "vector store" and you nod, we're in the same club. And it hides uncertainty beautifully. When you are not quite sure how to solve something, a wall of technical vocabulary makes it sound like you do.

That last point is the dangerous one. Jargon lets you sound competent while dodging the harder work of being clear. The test I use now is blunt: if I cannot explain what a system does, and why it is worth building, in words a smart twelve-year-old would follow, I do not understand it well enough yet. That is on me, not on the listener.

Explaining AI in plain language is a discipline, not a dumbing-down

There is a lazy assumption that plain language means simplistic language — that you're somehow watering things down for people who can't handle the real thing. It's the opposite. Translating a genuinely complex system into a sentence a busy operations director can act on takes far more understanding than reciting the architecture. Anyone can list the components. Explaining which one solves your problem, and which three you don't need yet, is the skill.

The clients we work best with are pragmatic and ROI-focused. They are not impressed by a long deck of capabilities, and they are right not to be. They want to know three things, in their language: what will this change, what will it cost, and how do we know it worked. None of those questions has a good answer in acronyms.

What changed when I dropped the buzzwords

Three things, concretely.

• Discovery got faster. When you describe the problem instead of the technology, the client can immediately tell you whether you've understood it. The wrong assumptions surface in minutes, not after a wasted proof of concept.
• Trust went up. Plain talk is weirdly disarming in a field full of hype. Saying "this part is genuinely hard and here's the risk" earns more credibility than any confident buzzword ever did.
• Scope got honest. Half of jargon's job is to make a small thing sound big and billable. Strip it out and you're left talking about what actually needs building — which is usually less than the slideware version, and ships sooner.

That last one matters because it shapes how we price and scope work. When the conversation is about the problem, an AI implementation becomes a sequence of clear, defensible steps rather than a vague transformation programme. You can read exactly what each stage costs on our pricing page — there's no acronym between you and the number.

The acronyms I still get asked to translate

To be clear, I'm not anti-terminology. The words exist because the concepts are real. The rule is just that the jargon never does the explaining — it follows the plain version, for the people who want it. A few I translate weekly:

• RAG usually means: "the AI answers using your own documents instead of making things up." That's it. If your team needs the deeper version, our LLM work goes there.
• An AI agent is software that can take a few steps on its own — look something up, decide, act — rather than just answering one question. Useful, but not magic, and worth being precise about.
• Fine-tuning is teaching a model your specific style or task by showing it examples. Often it's not what you actually need, and saying so saves real money.

Notice that every one of those starts with what it does for you, not what it is. That ordering is the whole rule.

A real example: the report nobody had asked for

Here's how the no-jargon rule plays out in practice. A logistics company came to us wanting, in their words, "a predictive analytics platform with a real-time anomaly-detection layer." Impressive sentence. The moment I asked them to describe the problem without those words, it became a different conversation: their planners were finding out about late shipments from angry customers, hours after the delay was already visible in their own data. That's not a platform. That's one alert, wired to the right people, fired at the right moment.

We built the small thing. It cost a fraction of the platform they'd imagined, shipped in weeks, and solved the actual pain. Had we accepted the jargon at face value, we'd have scoped a six-figure programme that mostly produced dashboards nobody would open. The plain-language version was cheaper for them and, frankly, less revenue for us in the short term — which is exactly why I trust the rule. It keeps the work honest. If a buzzword is doing the selling, someone is usually about to overpay.

This is also why we'd rather show a rough working version early than present a polished roadmap. A prototype you can click is the ultimate jargon-free explanation: it either solves your problem or it doesn't, and no amount of terminology changes the answer.

How to spot a partner who hides behind jargon

If you're choosing an AI partner, jargon is a useful diagnostic. Ask them to explain their proposed solution without using a single acronym. A good engineer will happily do it, because they're translating from understanding. Someone selling certainty they haven't earned will struggle — the buzzwords were load-bearing. The teams that actually ship tend to talk plainly and show you something working early; you can see the short version of that in our case studies.

This isn't about anti-intellectualism or pretending the engineering is simple. The engineering is often hard. But the conversation about whether to do it, and why, belongs in your language — the language of the problem, the cost, and the result.

The rule, and why I'll keep it

No jargon allowed isn't a marketing gimmick. It's a forcing function that keeps me honest: if I can't say it plainly, I don't understand it yet, and you shouldn't pay me until I do. Explaining AI in plain language is how I prove I've actually grasped your problem rather than just admired the technology. If that sounds like the kind of conversation you'd rather have, book a free consultation and we'll talk about your problem first — the acronyms can wait, possibly forever.

Frequently asked questions