Where Misunderstanding Can Derail Even the Best-Intentioned Effort
Serialized from Contracting for Rapid Acquisition: A Practical and Personal Guide to Disrupting the Status Quo for a More Responsive Future
By Lorna E. Tedder
It seems both obvious and trite to say that “communication” is a potential problem. It’s always a potential problem. At work. At home. Everywhere.
We’ve all had that person in our lives who didn’t listen to anything we told them repeatedly, but as we were ready to cut ties, their question was, “Why didn’t you tell me this was a problem?” Communication requires transfer of information to and from both parties. When communication fails, it’s usually because one party didn’t transfer the information or one party didn’t receive it. Sometimes the recipient heard but ignored the information because it wasn’t to their advantage, they didn’t understand it, or they were just too absorbed in something else to realize its importance to the other party or to themselves.
We often think we’re speaking the same language. We’re not.
Of all the structural issues I’ve seen in acquisition, few are as frustrating—or as fixable—as the communication gaps between professionals. These aren’t just gaps in personality or style; they’re systemic voids between functional areas, between government and industry, and even within individual teams.
One of the most dangerous assumptions we make is that we understand each other’s words. We throw around terms like requirements, documentation, agile, and metrics as if they mean the same thing to everyone involved. But they don’t. And until we acknowledge that, we’re just talking past each other.
Worse: how do you realize you have a disconnect in understanding words that seem so obvious?
A Real-World Epiphany of Communication Gaps
Around 2020, I joined a new software acquisition assignment with about 30 software engineers and program managers—and just two contracting professionals. Some of our international customers spoke languages other than English, so my awareness of expressing myself was heightened and probably contributed to my discovery. I didn’t want to use an informal term that might be misconstrued and cause an international incident!
However, the non-native English speakers were not at all the problem when it came to communication.
Confession: this was not initially my first choice of assignments because it was specific to software acquisition, and I’d never really enjoyed buying standalone software or software that was integrated with hardware in major weapons systems. Not that there was anything wrong with it, but software procurement was sort of boring to me. I still remembered buying computer programs on shiny silver disks in cellophane-wrapped boxes in mall stores. As of early 2020, how the government thought of buying software was changing drastically as organizations struggled to upgrade and modernize their old systems and adopt the agile methodology. The Adaptive Acquisition Framework pathways, for which I had helped write language and learning tools, was brand new, and the release of the Software Acquisition Pathway was on the horizon. While software-related assignments weren’t my first choice, they quickly became the majority of my workload because this change in how we buy software was new and confusing, and customers needed my help specifically with this type of work.
It also came with its own jargon, but I didn’t realize it at the time. Or, if I did, I didn’t realize that software development jargon overlapped acquisition jargon and didn’t always match definitions. Understanding that we were talking past each other was a milestone epiphany in solving our problems.
Our team was predominantly software engineers with no experience in Contracting. That’s why they called in two of us as their Contracting experts. The team was well-run, the members were brilliant within their own functional silos, and we were “communicating” at least four hours of every day. But for the quantity of meetings, discussions, phone calls, and emails, there was something missing.
I was worried. I was failing.
After three weeks, the other contracting person left for a new assignment. She was completely lost, too. We had both been productive, but no big breakthroughs. I stayed for another three weeks, quietly working on my part of the project and hoping things would click. They didn’t.
I confided to a colleague on a different assignment that I had no idea what was going on and that I was lost. I wasn’t used to being lost. I was used to being able to walk into a room and figure out the problem right away and then make a difference. What was wrong?
My level of frustration should have been a clue.
Eventually, to complete my piece of this assignment, I met with two government Contracting officials—and it was glorious! We were in perfect alignment. Within an hour, I knew exactly where their pain points were and how to help. Breakthrough!
We literally spoke the same language, and the same words had the meanings we expected. I felt I’d found kindred spirits as the rest of my software developer teammates observed the meeting and were, I hoped, learning something.
After that meeting, I called together the entire team to share my excitement. I was giddy because I knew exactly how to help! Before I could share how productive the meeting had been, the rest of the team stopped me at mid-sentence to complain that it was the most useless meeting they’d ever attended. They were lost, lost the same way I’d been lost for six weeks. Worse, they claimed the government Contracting team didn’t even understand what the word requirements meant and that the Contracting Officer thought metrics meant lead times. Wow, crazy, huh, that anyone would think that?
That’s when the light bulb went off: even within our frequently communicating team, we weren’t using language the same way. We were aligned by mission but divided by definitions. It was a career-changing moment for me and how I treated communication among a multi-functional team.
When Jargon Collides, Communication Gaps Thrive
The biggest communication disconnect I’ve seen since 2020 has been with software acquisition. Everything is software now, or has software, and every functional team—technical, legal, contracting—brings its own jargon to the table. Same words. Different meanings. Blank stares.
As an English major, I’m sensitive to nuance, but this goes way beyond Oxford commas and errant adverbs.
Think of a common Southern phrase from where I grew up: “Bless his heart.” It can mean sorrow, amusement, or fury, depending on context. If you’ve not spent time around Southerners, you might think that sweetly said putdown is sympathy and not realize that the words that are special to you are special in a different way to someone whose function on the team is different.
That’s software acquisition. AI, included. A Contracting Officer hears “requirement” and thinks acquisition planning documents. A software engineer hears “requirement” and thinks user story or backlog. I’ve heard software engineers joke, “We don’t need no stinkin’ documentation,” and a second later, I’ve heard my contract attorney gasp because he was thinking of documentation as a legal agreement that protects both the contractor and the government.
Multiply those misunderstandings across multiple terms, multiple meetings, multiple milestones, and you can see how trust breaks down fast.
To fix this:
- Look for the frustration or where otherwise brilliant colleagues “just don’t get it.” When you feel frustrated or lost or that other members of your cross-functional team don’t understand the importance of something that is critical to your understanding of the situation, take this as a clue to investigate.
- Ask others how they define key terms before you assume alignment. A simple “What does this word mean to a cybersecurity engineer?” may be eye-opening. You don’t live in their silo and they don’t live in yours. Find out where the disconnects are.
- Create a lexicon or glossary. Keep it simple. Just a shared document with working definitions. It doesn’t have to be fancy—it just has to be consistent because this is your Rosetta Stone for understanding the contributions and concerns of other team members.
I’ve seen this need for a lexicon across every major software, AI, and tech transition project I’ve worked on since 2020. If you noticed lexicon documents showing up in software-intensive programs, even as a cheat sheet, this is why. It’s a good leading practice. You need to be on the same page, and you might as well make that page your lexicon document.
Understanding Acquisition vs Contracting
While we’re ironing out our communications problems, let’s also clear up one of the most persistent misunderstandings: Acquisition is not the same as Contracting. This confusion pops up frequently and contracting personnel often end up being blamed for things that acquisition personnel decided or didn’t decide, which means Contracting Officers might get hostile when you call them slow on Monday morning and they’ve had the paperwork from non-Contracting personnel only since Friday at close of business, slid under their office door or emailed to them after they’ve gone home for the weekend.
The terms Contracting and Acquisition are often used interchangeably in government and defense settings, but they represent two distinct aspects of the procurement process. Understanding the difference between them is crucial for aligning responsibilities, streamlining workflows, and avoiding misunderstandings. I’ve seen those misunderstandings happen from the intern level all the way up to the Senior Executive Service level, and it’s a no-win matter to tell an SES that a certain responsibility, according to statute, belongs solely to the Contracting Officer.
Acquisition refers to the full lifecycle involved in obtaining goods and services to support an agency’s mission. It includes identifying needs, conducting market research, securing funding, developing an acquisition strategy, managing contract performance, and eventually disposing of or closing out the product or service. This process is broad and strategic, involving a range of professionals such as program managers, engineers, logisticians, financial analysts, and contracting staff. The focus is on delivering mission outcomes in a timely and sustainable way. Think of acquisition as the big picture.
Contracting, by contrast, is a specialized function within the acquisition process. Think of it as a subset of acquisition. It centers on the legal, procedural, and regulatory aspects of awarding and managing contracts. Responsibilities in this area include drafting solicitations, negotiating terms, ensuring compliance with regulations like the Federal Acquisition Regulation (FAR), and administering contract performance. The focus is narrower and more transactional, handled by Contracting Officers, Contract Specialists, and Procurement Analysts.
In simple terms, acquisition sets the strategy and scope, while contracting makes the deal legally sound and executable. Both are essential, but they serve different purposes and require different skill sets. They even have different jargon and the same acronyms for different words. Think of the subsets of acquisition specialties as silos, and building bridges between the silos can be rare. Recognizing where one ends and the other begins helps teams work more effectively and avoid unnecessary friction. The same with each silo understanding the needs of the other silos so they can have a holistic view of how to solve their problems.
If we consider internal collaboration, or communication within the government but between silos, you soon realize that we can’t stay in functional silos. For acquisition to work, the pre-Contracting and Contracting sides must partner—early and often. That partnership starts with relationship building, which starts with communication.
Outside the silos, customers in the government as well as industry and academia, often confuse the two terms, acquisition and contracting. Try explaining the FAR to someone downrange who thinks the only part that matters is the delivery of whatever solution the contract provides to solve the problem—and that awarding the contract should be the easiest piece. Often, Contracting may be the final leg of the relay, but it depends entirely on what’s been passed forward from the program side: timely, well-articulated requirements, a strategy, market research, and more.
Communicating Beyond the Silos
If you look at the Trifecta of Effectiveness, this type of communication and understanding would fall within the relationships component of tools, mindset, and relationships as a type of external collaboration or partnership building.
Communication is fundamental to external collaboration. We not only need internal communications to work flawlessly, but we also need to build bridges between government teams and industry/academia partners. Tools like industry days, email outreach lists, webinars, and virtual engagements help. Going forward, every industry day—unless classified—should include a virtual component. We’ve made too much progress in reaching new vendors to revert just because “that’s the way we’ve always done it.”
I mean, I love reading about the Dark Ages. But I don’t want to live there.
From Industry Days to AI Days
At the same time, we need to look to the future because we are fast approaching a big transition, and I promise it’s almost here. The government can’t make decisions in a vacuum and needs those communications with industry/academia, but I foresee that very soon, the government will rely on AI for market research, which is always the foundation of acquisition strategy. Soon, AI will be able to analyze databases of vendors, centralized contracts for in-scope work, websites, and various sources of data. This analysis, I predict, will eventually replace proposals as we know them now (2025, as I write this).
As with all transitions, it will be more important than ever to communicate and collaborate with industry/academia about how this new future will look. If the government wants to be able to access data about the best ideas and most qualified sources to solve problems, then it will need to communicate with industry/academia on how to provide the data to be analyzed. At least for the near future, AI’s results are only as good as the available data. For a better understanding of how data might be misused or underused to create unintentional disadvantages, I recommend Invisible Women: Exposing Data Bias in a World Designed for Men by Caroline Criado Perez.
Sharing Success: The Missed Opportunity
Another place where communication fails? In silence.
I’ve interviewed major innovators in the government who produced something jaw-dropping, but no one followed up to find out how or if it could be repeated elsewhere. I had one interviewee whom every government leader I spoke with agreed was above and beyond what they had seen throughout their careers. He set a precedent that everyone in Contracting should consider. He was happy to be interviewed, and he told me he’d been waiting a year for someone—anyone—to ask how he pulled off such a success. He’d won all sorts of accolades for his work but despite the widespread understanding that he had something truly special to share, no one actually asked him to share it. Not in a point paper. Not over a webcast. I was the only person who had asked.
Why didn’t his leaders have him on a virtual roadshow to train others? Or just a quick briefing with PowerPoint charts to share across all Federal acquisition channels that were interested? Or let him spend a few afternoons on contracting and acquisition podcasts?
He’s not the only Contracting Officer to score a major success. How many months—or years—could we save if we simply asked, “How did you do that?” And then passed the answer along?
If your organization rewards people for extraordinary outcomes, ask yourself this: Do they get recognized for doing something bold, or for finding ways to work around your existing policies and structures? If it’s the latter, then those policies are probably due for a rethink—and that’s another signal that communication, culture, and governance all intersect.
Who Owns Communication?
We assume it’s someone else’s job, but communication is everyone’s responsibility, and that includes Contracting Officers.
To bridge gaps with Program Managers, those conversations need to start early—before key decisions get locked in. The same is true for bridging the distance between Contracting Officers and policymakers, between all functionals, between government and industry/academia.
Build relationships. Hold listening sessions. Empower contracting teams to contribute to strategy, not just execute it. Involve industry in market research, risk assessment, and potential strategies. Bring in agile coaches or guides to help you make the connections and understand each other better. Find out where your potential partner in collaboration hangs out, whether it’s a forum, a podcast, or some other kind of gathering space, and take your questions to them rather than expecting them to come to you or, unfortunately, to know you exist and have a need they might fill.
Communication is a prerequisite to collaboration. And collaboration is the only path to speed, clarity, and successful outcomes.
TL;DR
Communication Isn’t Just About Talking More. It’s About Understanding Better.
If you’re frustrated, confused, or watching projects stall, look to your language. What sounds obvious in your silo might mean something entirely different to someone else. Define your terms. Build a shared glossary. Start key conversations early—especially between Contracting, Acquisition, and technical teams. And when someone in your organization does something extraordinary, don’t just say “good job”—ask how they did it, and make sure others hear it too. Communication is everyone’s job. And it’s the gateway to collaboration, clarity, and speed.
Next up: Crumblestone #3: Governance Constraints—what’s really holding you back?
Discover more from Rapid Lorna - Agile Acquisition Blog
Subscribe to get the latest posts sent to your email.
