Council Post: The Translator Gap Is Widening, And Closing It Is A Leadership Job

Nik Froehlich is the CEO and Founder of Saritasa, an Information Technology and Services company, since 2005.

getty

​One of the reasons I started Saritasa was that I kept seeing the same problem: Business leaders would ask for technology, developers would technically deliver what was requested, and yet the result still didn’t work for the business. Early on, I realized the issue was not talent or effort—it was language.

Management expects a finished, shrink-wrapped product, while engineering understands that custom software has a lifecycle: validation, testing, hardening and refinement. Someone has to translate the business expectation into technical reality, and then translate the technical reality back into business consequences. That disconnect is what I think of as the translator gap.

In many technology initiatives, management and engineering are not actually disagreeing. They are often using the same words to mean different things. The board wants to deliver superior products faster to stay competitive. Engineering wants depth of features and thorough testing before release. This is the age-old tension between strategy and execution.

Senior management can’t understand why a project is taking so long, while engineering can’t understand why priorities keep changing. You would think that as executives learn the technology and engineers learn the business, the two groups would converge. In many cases, they move farther apart.

Executives think in terms of outcomes, risk, ROI, timelines and market differentiation. Engineers think in terms of architecture, dependencies, technical debt, reliability and scalability. Both perspectives are necessary, but without active translation, companies end up with skilled teams that can’t align. This is the translator gap, and it is widening. It’s up to leadership to own it and close it.

What The Translator Gap Really Means

The gap is not about a lack of intelligence. Both groups are smart, but they simply work at different levels of abstraction and respond to different incentives.

A CEO may say, “We need a platform that is enterprise-ready.” For the business, that means larger customers and higher sales value. Engineering needs something more specific: auditability, uptime targets, built-in security and compliance. A project manager may say, “We need to refactor before we can scale,” which an executive hears as perfectionism and delay, when it actually means lower risk, lower support costs and greater reliability. Both sides are technically correct and strategically misaligned.

Why It’s Widening

On the business side, companies juggle multiple products, capital and compliance constraints and questions of security, privacy and data governance that shape sales cycles and retention. On the engineering side, systems have grown interdependent. A request for one customer-facing feature now touches authentication, billing, analytics, privacy, mobile performance and API limits. The request is easy to describe and hard to execute.

There is a common assumption that AI closes the gap by summarizing meetings, clarifying requirements and translating jargon. AI is useful, but it is not a panacea. It can improve output speed without solving alignment, and it often widens the gap by generating more communication without shared meaning. A confident summary can bury the unresolved tradeoff. Polished documentation can still leave engineering without the decision it actually needs.

Why It’s Leadership’s Job To Translate In Both Directions

The damage is done before you can detect it. Roadmaps drift, engineers tire of shifting priorities and executives tire of slow progress. The work gets done well; it just turns out to be the wrong work. Operating costs climb as teams rework deliverables, and trust erodes until every decision has to be relitigated. What looks like a delivery slip ends up undermining the strategy itself.

Leaders are responsible for turning outcomes into constraints and translating technical complexity into business consequences. Saying “we need to reduce technical debt” isn’t actionable. Saying “without this groundwork, each deployment takes longer, support costs rise and future changes get harder” makes the stakes clear. The job is to understand the tradeoffs and make them visible, not hide them behind slogans.

What Good Translation Looks Like

Translation is a learnable, repeatable discipline that a leadership team builds deliberately. Start by defining success in business terms (revenue impact, adoption, implementation time, compliance readiness, etc.) and making the assumptions explicit.

Technical founders and CTOs should take note: If they can’t do the translation themselves, they need to hire product and engineering leaders who can. Otherwise, they end up with roadmaps that have no strategy, executives who feel trapped by technology and teams blamed for not delivering on reality.

A few habits make this concrete. Set a rhythm: a monthly review of how the roadmap changed and why, and a weekly look at the few decisions, risks or constraints that actually matter. Give every major initiative two short documents that have to agree before work starts—a one-page business overview (problem, customer impact, success metrics, constraints) and an engineering reality check (dependencies, risks, options, recommended path). And keep a shared glossary, because “enterprise-ready,” “scalable” and “real-time” mean different things to different people.

The goal is eliminating hidden assumptions. The companies that win aren’t the ones with the smartest executives or the best engineers. They’re the ones who keep their teams aligned long enough to execute. As complexity compounds, the leaders who succeed are the ones who can translate meaning into alignment.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?