When we think of reasons why a software project might fail, our minds tend to go towards technical aspects. Maybe the development team missed a crucial bug that severely impacts user experience. Perhaps the DevOps team missed a resource gap between the staging and production environments, causing a deployment issue. There is a long list of technical things that could go wrong in a project.
However, there is an issue that is far more insidious than any technical problem: poor communication. There are so-called “soft skills” that we are tempted to overlook in a technical project in favor of the “hard skills.” Communication is one of those abilities that tend to be taken for granted, but when prioritized, the results speak for themselves.
Let’s imagine we’re starting a brand-new project. If we don’t communicate well, and the client's requirements are not well captured, there is a high chance that the project will fail even before the first line of code has been written. Even worse, these issues could remain invisible until much later, when someone finally says, “Oh, so that’s what they meant."
That’s why we need to stop treating communication as a "soft skill" and start treating it as a core engineering discipline. If basic aspects, such as the scope, a feature’s acceptance criteria, or the expected timeline, are not well communicated and understood, there will be problems down the line.
We're going to break down the three common instances where clarity consistently dies, and then give you three practical habits you can start implementing today.
Where Project Clarity Goes to Die
1. The Trap of "Guess What I Mean."
This trap occurs when there is a mismatch between what stakeholders want and what the team understands they want. The same goes for what the team needs and whether the stakeholders understand it.
To understand this issue, we need to go to the basics of communication: there is always a message that will be communicated, the sender who will communicate it, and the receiver who will decode the message and understand it. The receiver then tells the sender what they understood through feedback.
Several things can go wrong in this seemingly simple process. Perhaps the message is not accurately articulated by the sender due to a lack of technical knowledge. Maybe they transmitted it through the wrong channel (verbally instead of through writing). Or it’s possible the receiver understood something not intended by the sender, and did not bother to confirm through feedback.
The Problem: Stakeholders assume their internal business context is universal. They forget that the development team doesn't live inside their sales funnel or finance department.
The Symptom: We deliver something that is technically perfect but completely misses the business objective. Hello, rework and scope creep.
The Answer: We need to always ask “why”. If we understand why we need to build a certain product or feature, it’s much easier to come up with follow-up questions that allow the team to fully understand what the stakeholders want.
We need to be mindful of delivering value to the client with everything we do. Therefore, if we do not fully understand what the value is, we should keep asking questions until it is crystal clear.
2. The Trap of "Different Vocabularies."
Trap no. 1’s sister: This is the failure of vocabulary misalignment. It doesn’t matter if both teams are speaking the same language; different industries and companies use different vocabularies. There are also cultural differences that go beyond nationalities: there are companies with hierarchical structures that actively disincentivize asking questions. In those cases, misunderstandings cannot be corrected because it is frowned upon.
The Problem: Developers use their jargon ("microservices," "latency") while the business uses theirs ("customer journey," "conversion rates"). We are using different dictionaries, and the meaning is lost in translation.
The Symptom: Endless circular debates where everyone thinks they agree, only to realize later they meant two totally different things.
The Answer: Enforce a simple, single shared glossary between teams for every core concept.
3. The Trap of "Only Bob Knows."
This is the failure of centralized knowledge. We’ve all had a certain team member who keeps the documentation or knows so much about the project that they end up being the documentation. The problem is, what happens when they go on vacation or exit the organization?
So many engineers hesitate to take time off and rest, as they feel their presence is a determining factor for the project’s success. This puts them at risk for burnout (a state of exhaustion that impacts a person’s functioning), and the project at risk of slower velocity. An additional risk is another teammate doing what they can with the information they have and unknowingly breaking something.
The Problem: Critical information (a specific rule, an architectural decision, a legacy workaround) resides in one person's head, one personal folder, or one buried Slack thread.
The Symptom: When Bob takes a vacation or leaves, the project stops cold. It creates crippling burnout for the "expert" and exposes the project to the terrifying bus factor (how many team members can be removed from a project until it becomes vulnerable to failure).
The Answer: Position documentation as risk mitigation and a first-class project deliverable. Even if the agile manifesto says we should prioritize working software over comprehensive documentation, that doesn’t mean having no documentation.
Conclusion: Clarity is Not Luck
Achieving clarity is not a magical outcome; it's a proactive choice. We apply engineering discipline to code, and we must do the same for our words. Communication is so much more than “just” a soft skill: it is the foundation of human interaction. After all, no matter how technical a project is, we’re all just humans talking to each other. The sooner we learn how to communicate with intention, the higher the chances of having a successful project.
Presented at DevFest Ecuador 2025.
Subscribe to our blog to stay updated with insights from the Stack Builders team.