At Next Mile, we focus considerable attention on removing ambiguity. Metastatic ambiguity is the single most nefarious and pervasive villain disrupting successful engineering delivery. Preventing its harmful effects begins with agreement.

If 90% of arguments are semantic in nature, that makes semantics the most probable culprit in any communication disaster. Consider the following terms in your own engineering or delivery context:

• “Experience”
• “Requirements”
• “Design”
• “Integration”
• “Testing”
• “Release”
• “Done“

If you work in digital or product development, these words all mean something to you—perhaps something very specific. However, do your definitions match your teams' or company's? How about your vendor’s? The smallest disagreement on these definitions will introduce ambiguity that creates friction, misalignment, underwhelming results, and resentment.

It sounds so basic and may feel beneath one’s professional level, but intentionally addressing terminology is one of the best investments you can make in your project’s sanity.

Start by agreeing that you need to pause and define things. It's been our experience that after some initial eye-rolling, even the most entrenched stakeholders do participate. Everyone loves to be right.

• Focus on work stages like “design”, “develop”, “test”. Each of these are used broadly by outsiders but specifically by contributors. How often have you heard something like "this was tested, why doesn't it work?" It's possible people never agreed on what "test" meant.
• Next, consider words that describe work functions in each stage. Things like “integration”, “develop”, “support”, “deploy”. Each is at extreme risk of being misunderstood by the speaker—likely a subject matter expert-and the listener. Misreporting something from this list to the CEO is the fastest way to make everyone mad.
• Industry terms can be particular areas of ambiguity, especially across the insider > outsider divide. “DFMEA” is meaningful in some contexts, but not others. “DevOps” is a word that inspires project-breaking ambiguity. “Wireframes”? Ugh, don’t get us started on that one. Generally speaking, the more technologies and disciplines on your project, the more invasive your vernacular.
• Organizational jargon can be spewn with such aplomb that everyone assumes agreement that doesn’t exist. Many terms will be well-worn by lifers, but make no sense to the newcomer or onlooker. These are great targets for quick alignment when appropriate. Especially as teams change, work changes hands, or people join the program.
• Lastly, make sure and lock down process terms. These are the most dangerous because they're everywhere: “review”, “document”, “provide”, “deliver”. Similarly, some terms are presumed universal by engineering vendors but aren’t actually common: “sprint”, “epic”, “story”, “ticket”, and “ceremony”. Note that we're ignoring the basics like “end-of-day”, “ASAP”, etc.

Although some definition agreement is better than none, assume that most of the language your group uses is taken for granted and act accordingly. This isn't once-and-done work. Instead, consider the following:

Stop discussion to clarify

One powerful method is to confront words or acronyms to seek clarification in the moment. "When you say DFMEA you mean...?" It's been our experience that there's always someone in the meeting who doesn't know the definition, remember the definition in this context, and won't ask the question but will do better work knowing the answer.

It may feel disruptive in the moment, but notice how over time, people start using defined words more consistently and precisely.

Reiterate over and over again

Deploy this behavior throughout long-haul projects to help prevent slippage and hard feelings.

• Reiteration helps remind, reinforce, and realign people in simple ways with profound affect. "When this is done, and by that we agreed on (blank)" is an easy, powerful way to crush ambiguity.
• Reiteration also helps unearth new thinking. Referring to "done" again, merely by taking a moment on that word, a contributor might say "actually, I also remembered (blank) so done in this case won't include (blank)." How amazing to get that data!
• Finally, reiteration helps make space for positive change. "We said done meant complete, but how do we feel about calling done 'version 1.0', and beginning to track work for version 1.1 separately?" Pragmatism, alignment, and progress all in one sentence!

Correct publicly (but gently)

Similar to reiteration, correction, when done well, is a powerful antidote to ambiguity. How often have you heard something off-base, let it slide, then regretted the downstream impact? Small corrections and clarifying questions in the moment protect everyone from big problems later.

And remember that for anyone misspeaking about something, there are likely 2-3x (more) people with the same or other definitions. Public realignment helps everyone.

Collaboration is key

When there's only one person responsible for making sure teams start and stay aligned, that person always fails. A delivery team helps itself by communicating clearly. Foster a team that welcomes disambiguation by making it collaborative:

• Ask stakeholders to define as they present, transferring ownership
• Remind facilitators to seek alignment when needed, engaging more people
• Reward the behavior at the end of each meeting with gratitude and, yes, reiteration

Being the grammar police is a thankless job, especially if you think about it that way—as policing individuals—instead of what it really is: eliminating ambiguity to clear the path for the whole team. Excellence comes from basics done well, not fancy methodologies.

---

On any significant project there will be plenty of opportunities to disagree with each other in healthy (and silly) ways. If you're having trouble getting teams aligned around the fundamentals, Next Mile can help. Ambiguity fears us!