I recently had dinner with an old friend. He's a local business owner, and as we caught up after years, we naturally turned to the challenges we're facing at work. Despite our companies being different sizes, a single theme quickly dominated the conversation: the staggering amount of time, money, and morale wasted simply because of poor communication.
This hits home for me. In the world of software engineering, communication isn't just a "soft skill." It is the single most critical component for success. It is the core mechanism that enables collaboration, aligns strategy with execution, and ensures that what is built actually solves the business problem. When it fails, the entire project fails, slowly or all at once.
This is especially true in today's environment of distributed and offshore teams, where a small ambiguity in a morning email can blossom into a week of wasted development by the next day. I have seen this gap consume projects from the inside out.
The Point of Failure
The most common mistake I see companies make—particularly small and mid-sized businesses—is attempting to use non-technical personnel to manage complex software projects.
To be direct, this almost always ends in failure.
It's not a question of intelligence or business savvy. The problem is one of translation. These managers may be experts in operations, marketing, or finance, but they do not speak the language of engineering. They cannot grasp the deep-seated intricacies of building scalable, maintainable software.
I am brought into conversations far too often where a client, or even an internal stakeholder, is operating on a set of completely incorrect assumptions. They think they know how a system works, and they make demands based on that flawed mental model.
The engineering team is then put in the impossible position of either:
- Politely explaining why a "simple request" is actually a two-month architectural rebuild.
- Giving up and just building what was asked, knowing it's the wrong, non-scalable, or technically-indebted solution.
Both outcomes are terrible. The first makes the engineering team look difficult and slow. The second guarantees the project will eventually collapse under its own weight, requiring even more time and money to fix.
Engineers hate wasting time—it doesn't matter if they are compensated for it. We are result-oriented individuals and nothing is more discouraging than spending several hours on a task that is completely misaligned with the business goal. This is where the wasted hours my friend and I discussed pile up into mountains of debt—both technical and financial.
The "Slightly Technical" Hazard
There is a scenario even more dangerous than a purely non-technical manager: the "semi-technical" or "technical-adjacent" leader.
This is the person who has read the buzzwords but has never lived in the code. They don't come from an engineering background, but they know enough to be dangerous. They will confidently throw around terms like "Kubernetes", "microservices," or "machine learning" without understanding the profound architectural trade-offs, operational overhead, or long-term maintenance burden each one carries.
This false confidence is devastating. They will override the genuine concerns of senior engineers, mistaking cautious, experience-based warnings for pessimism. They will promise stakeholders features on impossible timelines because they simply do not comprehend the complexity of the work involved.
In my career, I've seen this type of misunderstanding lead to complete chaos. Teams burn out trying to meet unrealistic demands, and the product becomes a fragile mess of "features" built on a rotten foundation. The leader, shielded by their perceived technical knowledge, blames the engineering team for being "slow" or "not good enough."
The Real Cost for SMBs
My friend at dinner pointed this out, and he's right: this problem is most acute at the SMB level. The justification is almost always financial.
But there is another common failure point: hiring a technical leader and then proceeding to underutilize their expertise. This often happens when a company isn't truly ready to trust its technical leadership. They treat the leader as just another manager instead of a strategic partner, effectively sidelining the very experience they paid for and creating the same communication gaps they were hired to solve.
I understand the logic, but it is fundamentally flawed. The "significant investment" required to retain this talent is not a cost; it's insurance.
The salary of a competent technical leader who can actually build systems and manage engineers is a fraction of the cost of a single failed software project. The cost of months of wasted salaries for an entire development team, the cost of lost market opportunity, the cost of rebuilding a failed platform from scratch—these are the true expenses.
Companies pay for that expertise one way or another. They either pay for it upfront in the form of a qualified leader, or they pay for it tenfold on the back end in the form of delays, rework, and total project failure.
The Role of the Translator
The solution is to have a leader who is bilingual. They must be able to speak fluently to both the business and the engineers.
They must be able to sit with the C-suite and translate the company's multi-year vision into a concrete technology roadmap. They need to understand the business challenges so deeply that they can propose solutions the business side hasn't even considered.
Then, that same person must be able to walk into a sprint planning meeting and have a credible, detailed conversation about database schemas, API design, or the trade-offs of a proposed CI/CD pipeline.
When a leader has this dual fluency—rooted in real, hands-on engineering experience—the entire dynamic changes.
Trust is built. Engineers feel understood and protected from ambiguity. Stakeholders get accurate forecasts and predictable results. The "wasted hours" my friend and I lamented over dinner begin to disappear, replaced by productive, focused work.
Protecting your technology investment isn't just about hiring good engineers. It's about hiring leadership that fundamentally understands what it is they are building and trusting them to do just that.
