Most of us have been in a meeting where the vocabulary is impressive and yet, the assignment remains a mystery. In this meeting, we are building synergy, aligning priorities, eliminating waste, and preparing for transformation. Everyone appears to understand. Then someone asks what needs to happen by Tuesday, and the explanation introduces three more terms and a recommended book.

In our home, we like to call this the Flexicon. It is the ever-shifting collection of professional language that travels through conferences, leadership books, certification programs, and LinkedIn before arriving in a meeting near you. Some terms describe useful concepts. Others seem to earn their place through repetition. Either way, knowing the vocabulary can become an unofficial requirement for participating or landing a job, even when nobody in the room can explain what it means or offer a concrete example of how to use it.

My concern is what happens after the meeting. Someone has to translate the discussion into direction, decisions, tasks, and instructions. When that connection is missing, the people responsible for doing the work must figure it out themselves. Understanding the assignment then becomes the first assignment, and time that could have moved the work forward is spent trying to make sense of it. And if there is a deadline, it rarely accounts for that time spent in limbo.

Before we go any further, I should acknowledge that I am absolutely the person reading those books. My background is in industrial and organizational psychology, and I can happily spend an afternoon exploring the intersections of business, sociology, and anthropology. Yes, I am that nerd. I appreciate a thoughtful framework, a clean spreadsheet, and a dashboard that answers a question someone actually has.

That interest is part of why the Flexicon frustrates me. There is useful thinking behind many professional methods, but the explanation can become more complicated than the problem. Lean Six Sigma brings DMAIC, kaizen, and muda. Project management adds charters, dependencies, and work breakdown structures. Change management introduces readiness and adoption. Liberating Structures offers named approaches to facilitation. A team can encounter several of these vocabularies while trying to improve one ordinary process.

These terms are not interchangeable, and they are not all empty buzzwords. Muda, for example, has an established meaning within Lean. A project dependency describes a relationship that may be essential to planning the work. The question is whether the term helps the people in this particular conversation understand something and get the work done. Its usefulness within a profession does not guarantee that everyone else knows what to do with it or that it serves a useful purpose in the situation at hand.

Imagine a team trying to improve how requests move between departments. One person asks about waste, another asks about dependencies, and a third asks whether people are ready for change. Each question could reveal something valuable. But the people handling the requests still need to understand what is being examined, what they should contribute, and what a better process would look like. Without those connections, they are being asked to learn several methods before they can help solve a problem they already experience. Meanwhile, a simpler starting point may have been overlooked. Has anyone spoken with the other department to find out whether this is even the right process for those requests? That conversation might reveal something worth knowing before everyone gets busy improving it.

Research suggests that difficulty processing language can affect more than comprehension. In a 2020 experiment involving 650 participants, Hillary Shulman and colleagues found that jargon made scientific information harder to process, even when definitions were supplied. It also affected participants’ identification with the scientific community and their reported interest and understanding. The study examined science communication, rather than workplace assignments, but it raises a question worth bringing into our meetings. When people struggle to follow the language, do they start to question whether the conversation is for them?

Consider someone who knows a process inside out but has never studied its formal terminology. They can explain where requests stall, which information is missing, and why a workaround exists. Yet they may hesitate to contribute when the discussion shifts into language they do not recognize. Meanwhile, someone fluent in the vocabulary can sound prepared before offering a workable idea. We need to pay attention to whose knowledge becomes visible under those conditions.

The format can create hurdles, too. A process improvement workshop might depend on a wall of sticky notes. A facilitation exercise might involve quick exchanges in pairs. A planning session might begin with a dense template that nobody has seen before. Each activity assumes something about how people will receive information, develop an answer, and share it.

A participant may need accessible digital materials, interpretation, a question in advance, or additional processing time. Those needs differ between people and situations. They deserve consideration whether we are using Liberating Structures, mapping a Lean process, or planning a project. An activity intended to include everyone still needs to work for the people actually present. Otherwise, we can mistake difficulty with the format for a lack of ideas.

There is a related gap between adopting a formal approach and making it useful. In their 1977 paper on organizational structures, John Meyer and Brian Rowan examined how organizations can gain legitimacy by adopting accepted structures while keeping those structures loosely connected to everyday activity. Their argument reaches well beyond jargon, but I find it useful when considering a familiar workplace puzzle. How can an organization have a strategy, a framework, and a reporting system while people remain unsure what they are working toward?

A document can give us a place to record decisions, but someone still has to make them. A new method can help us examine a problem, but someone has to explain why it fits. When we skip that work, people are left researching terminology, finding examples, and comparing interpretations with colleagues. The effort may eventually produce something useful. It may also produce several reasonable answers to a question leadership thought it had already settled.

Before introducing another approach, I want us to get specific. Which problem are we trying to address? What should someone be able to do differently? Can we show an example and explain how we will know whether the change helps? Those questions give people something they can examine and challenge. They also help us discover whether we understand our own proposal well enough to ask others to carry it out.

I will keep reading the books and exploring the methods. But when I bring an idea into someone else’s working day, I owe them a clear explanation and a chance to question it. Before a meeting ends, asking people to describe the next steps in their own words can reveal what still needs attention. If the answers differ, we have found a gap worth closing together, before everyone spends Tuesday working on a different assignment. Or discovers on Wednesday that three people did the same work while something else went untouched.