How to Talk Tech Like a Businessman Should
A Rosetta Stone for the Room Where Decisions Get Made Wrong
How to Talk Tech Like a Businessman Should
A Rosetta Stone for the Room Where Decisions Get Made Wrong
Inventor's Mind | Herbert Roberts, P.E.
There is a meeting happening right now in a conference room somewhere in your industry. An engineer is explaining something true. An executive is hearing something else entirely. And a decision is being made on the gap between those two realities.
This is not a failure of intelligence on either side. It is a failure of translation — which is a different problem, with a different fix.
The engineer speaks in a language built for precision. Every qualifier is load-bearing. Every hedge is a signal. The executive speaks in a language built for decision velocity. Every delay is a cost. Every caveat is noise. When these two dialects collide, organizations do not get the best of both — they get the worst: cost overruns blamed on engineering, missed windows blamed on management, and a deepening mutual distrust that compounds with every failed project.
The Rosetta Stone was not a dictionary. It was a key — the same decree rendered in three scripts, side by side, until the pattern became undeniable. That is what this post is: the same engineering reality, rendered in the language engineers speak, the language executives hear, and the language the organization actually needs.
Two contradictions anchor this translation. They are the most common. They are the most costly. And they are the ones most likely to be in the room where your next major decision gets made wrong.
But before the tables — before the specific phrases and the specific misreadings — there is a premise that has to be established. Without it, the translation work that follows is just technique. With it, it becomes something the organization can actually sustain.
The Premise: Neither Team Is Subordinate
The translation failure between engineering and business leadership is not a communication problem wearing an org chart. It is an org chart problem wearing a communication costume.
Most organizations are structured so that one team reports to the other — which means one team, by design, is the authority and the other is the executor. In that structure, translation is never truly mutual. The team with positional authority sets the terms of the conversation. The team without it adapts or suffers. The result is not translation. It is compliance dressed up as alignment.
The premise this post operates from is different: neither team is subordinate — each is the other's customer.
This is not a soft claim. It is a precise one, and it cuts in both directions with equal force.
The business leadership team is the engineering team's customer. It defines the mission: the market to enter, the problem to solve, the window to hit, the resources available. Without that definition, engineering has no target. A team of brilliant engineers with no mission specification is a library — full of potential, producing nothing deployable.
The engineering team is the business leadership team's customer. It defines what is physically possible, what is technically sound, what the real risks are, and what the proposed solution will actually cost — in time, in money, and in downstream consequence. Without that input, business leadership is navigating by ambition alone. An executive team with no honest technical counsel is a ship with no depth finder — moving confidently toward something it cannot see.
Each team, therefore, must provide the other with what the other cannot provide for itself. The executive cannot engineer. The engineer cannot set market strategy. The moment either team treats the other as an obstacle rather than a source of essential information, the organization has broken the supply chain that innovation runs on.
What this demands of engineering teams: The obligation to provide honest, complete, and decision-ready technical input — not filtered for palatability, not compressed to avoid an argument, and not withheld because the last honest assessment was not well received. The engineering team that tells the business what it wants to hear has stopped being a customer and become a vendor of comfortable fictions.
What this demands of business leadership: The obligation to provide engineers with a decision environment in which honest technical input is welcomed, resourced, and acted upon — not punished, not bypassed, and not overridden by schedule pressure masquerading as leadership. The executive team that systematically ignores engineering counsel until a failure becomes undeniable has stopped being a customer and become a liability that the engineering team is quietly managing.
A short note before the break. Inventor's Mind is free, and subscribing stays free — no payment, no upsell, just an email. The break exists for one reason: feedback. Subscriptions are the cleanest signal a writer gets about what landed and what did not.
Page views measure traffic. Subscriptions measure trust. I am moving the second half behind a free sub so the columns that earn the trust can be measured against the ones that did not, and the next column can be sharper than the last. Please stay with me — subscribe so I can tune in to what you need. Thank you for reading.
What this demands of the organization: The structural commitment to treat technical resources — people, tools, time, and test infrastructure — not as costs to be minimized, but as the productive capacity that makes any business outcome possible. Innovation does not happen in a budget meeting. It happens in the lab, on the test stand, in the analysis, and in the head of the engineer who has been given the space and the tools to think. Organizations that starve that environment while demanding its outputs are not managing innovation. They are consuming the seed corn.
The equality between these teams is not sentimental. It is mechanical. A machine in which one component is systematically underpowered relative to the load placed on it will fail — not because anyone intended failure, but because the physics of the situation were ignored in favor of the politics. The same is true of organizations.
The tables that follow are not just a translation guide. They are diagnostic instruments. Every row is a place where the equality between teams has been broken — where one side has stopped treating the other as a legitimate source of essential truth, and started treating them as an obstacle to be managed.
Read them accordingly.
Contradiction One: Cost vs. Quality
The first technical contradiction in any development program is the oldest: you can have it cheap, or you can have it right, but the path to having it both requires a systems thinker in the room — and those are rare.
Engineers know this trade-off at the molecular level. They live inside it. Executives know it abstractly, the way you know a foreign city from a map. The map is not wrong. But it is not the city.
Here is what that sounds like across the translation gap:
Cost vs. Quality — The Rosetta Table
The root cause of every entry in that table is the same: the engineer is reporting on the present state of a system, and the executive is making a decision about the future state of a market. Neither is wrong. But neither is sufficient alone.
The engineer who says "this solution meets spec" without volunteering the boundary conditions of that statement has failed the organization. The executive who hears "meets spec" and stops listening has also failed the organization. The translation requires active effort from both directions.
What engineers must learn to say: Front-load the decision implication, not the technical finding. Not "we're seeing variability in the data" — but "we have an unresolved process risk that I recommend we resolve before release, and here is what that costs in time and dollars versus what it costs if we find it in the field." Give the executive the trade-off in their language. They will make a better decision.
What executives must learn to hear: Every engineering qualifier is information, not decoration. When an engineer adds "under these conditions" or "within this range" to a performance claim, that boundary is the most important part of the sentence. Precision is not timidity. It is the engineer doing their job.
Contradiction Two: Speed vs. Depth of Solution
The second contradiction is more dangerous than the first, because it masquerades as urgency — and urgency is always politically legitimate.
Speed kills in engineering the same way it kills on the highway: not because motion is dangerous, but because motion without adequate situational awareness removes the margin that absorbs mistakes. Every shortcut in the development process is a bet that the problem you skipped will not appear downstream. Sometimes you win that bet. The field return data suggests you win it less often than the schedule pressure convinces you that you will.
Speed vs. Depth — The Rosetta Table
The structural problem beneath this entire table is timeline asymmetry. The executive's decision window is measured in quarters. The engineer's failure mode may not materialize for years. When those two timelines do not overlap, the incentive system naturally rewards the decision that looks good now and punishes the caution that pays off later.
This is not a character flaw in executives. It is a systems problem — which means it has a systems solution.
What engineers must learn to say: Translate depth into deferred cost. Not "we need more time to fully characterize this" — but "the characterization gap represents approximately X dollars in probable field return exposure, based on the last program where we shipped with a similar open item. Here is the schedule cost to close it now versus the projected cost to manage it later." Make the executive's decision visible as a financial decision, because that is the language in which it will be evaluated.
What executives must learn to hear: Speed that compresses engineering depth does not accelerate the program — it relocates the cost. The schedule pressure that feels like it is saving three months in development will collect its invoice at first article, at production ramp, or at the customer site. The invoice always arrives. The question is only which budget it posts to, and whether you chose that consciously.
The Room Where This Gets Fixed
The translation failure described above is not inevitable. It is a design problem in how organizations structure the dialogue between technical and business leadership — which means it is solvable with the same systematic thinking engineers apply to everything else.
Three structural fixes close more of the gap than any amount of communication training:
(a) Require engineers to present trade-offs, not findings. The deliverable from any technical assessment should be a decision table — option A costs this, carries this risk, requires this time; option B costs that, carries that risk, requires that time. Engineers who present only findings force executives to make trade-off decisions without trade-off information. That is an unfair game, and both sides lose it.
(b) Require executives to formally accept risk, not informally dismiss it. When an engineer identifies a known risk and the organization decides to proceed, that decision should be recorded — in writing, with the decision-maker's name on it. This is not about blame. It is about making the risk decision visible, which changes the quality of the decision.
(c) Build translation into the program structure. The role of a Systems Engineer (S.E.) — when that role is functioning correctly — is precisely this translation function. The S.E. is the person who speaks both languages fluently enough to hold the boundary between them. Organizations that eliminate or marginalize this role to save cost are removing the Rosetta Stone from the room where it is most needed.
Closing: The Mutual Obligation
This post is written for both sides of the table, because the translation failure is mutual. Engineers who speak only to each other, using precision language in a decision room that runs on velocity language, have failed in their professional obligation to their organization. Executives who treat engineering qualifiers as noise, and engineering time estimates as negotiating positions, have failed in theirs.
The Rosetta Stone was not discovered by accident. It was found because someone decided that understanding mattered more than the convenience of assuming the other language was untranslatable.
The meeting happening right now in that conference room can go differently. It requires one person on each side of the table who has decided to do the translation work — and who understands that the gap between what engineers say and what executives hear is not a personality problem.
It is an engineering problem. And engineering problems have solutions.
Herbert Roberts, P.E., is a licensed professional engineer with 32 years in aviation research and development, 62 U.S. patents, and 8+ years of forensic engineering consulting. He writes at Inventor's Mind on systematic innovation, engineering judgment, and the structures that make technical organizations succeed or fail.
© 2026 Inventor's Mind Press | inventorsmindpress.com