A chief executive never receives information about his own technology. He receives a translation of it, produced by the people whose work that same information is used to judge. This is not a communication problem that better dashboards will solve. It is a governance problem, and the structural answer to it is a translator who works for him and for nobody else.
Every technology decision a chief executive makes is made on a translation
No chief executive reads the state of his own systems. He reads a rendering of that state: a slide, a status colour, a sentence in a steering committee, a paragraph in a board pack. Between the machine and the decision there is always at least one human act of translation, and often three or four stacked on top of each other.
This is not a failure. It is the only way a company of two hundred people can function. Nobody expects a chief executive to read logs, and a chief executive who reads logs is usually a chief executive who has stopped doing his job. The translation layer exists because it has to exist.
The problem starts one step later. The translation is produced by people who are inside the thing being translated. The engineering lead who tells you the platform is fine is also the person whose team would be blamed if it were not fine. The vendor who tells you the migration is necessary is also the vendor who invoices the migration. The head of product who reports amber instead of red is also the person who committed to the date in front of your board six months ago. None of these people is dishonest. All of them are translating with something at stake.
An interpreter with something at stake is still an interpreter. He simply is not a neutral one, and there is no version of the arrangement in which he becomes neutral because you asked him nicely.
The interpreter is the only person in the room you cannot audit
Sit in a negotiation conducted in a language you do not speak. You say a sentence. The interpreter turns and speaks. You watch the other party’s face, which tells you nothing, because a face does not translate. The other party answers. The interpreter turns back and gives you a version.
Everyone else in that room can be checked. You can check the contract afterwards. You can check the numbers with your own finance team. You can check the other party’s reputation with three phone calls. The interpreter is the single node in the entire circuit whose output you have no independent way of testing, and he is also the node through which every single piece of information travels.
That is a remarkable structural position for one person to hold, and it exists in your company right now. Not because anyone engineered it, but because information about technology travels along exactly one path: from the people who built the thing, to the people who manage those people, to you. Each hop is a translation. No hop has a second channel.
The interpreting profession understands this danger better than most corporate functions do. Professional interpreter bodies build their standards around impartiality and professional secrecy precisely because the interpreter’s position is unverifiable from the inside. AIIC, the international association of conference interpreters, maintains a code of professional ethics and a set of professional standards whose entire purpose is to compensate for the fact that the client cannot check the work in real time. The profession solved the trust problem with an external framework, because it could not be solved with goodwill.
Your technology reporting has no such framework. It has goodwill.
Smoothing is not lying, which is why nobody stops it
Ask any working interpreter what actually happens in the booth and you will hear a version of the same thing: some things get rounded. An aggressive sentence is delivered a little softer, because breaking the atmosphere is not in anyone’s interest. A vague conditional in one language has no clean equivalent in the other, so it becomes a yes or a no. A technical detail the interpreter did not follow is dropped, on the reasonable assumption that it was probably not the important part.
Every single one of those choices is helpful. That is the difficulty. Nobody involved has done anything wrong, and nobody involved could reasonably be asked to behave differently. The interpreter who refuses to smooth anything produces a conversation nobody can follow.
The same three moves happen in every technology report that reaches an executive committee. Severity gets softened, because a red status in month four has political consequences that a red status in month nine does not. Ambiguity gets resolved into a decision, because a chief executive who is told “it depends” three times stops asking. Detail that the reporter did not fully grasp gets dropped, because reporting something you do not understand is professionally risky, and dropping it costs nothing this month.
Individually, each of these is a rounding error. Stacked over two quarters, they produce a picture of the company’s technical reality that is not false in any single line and is wrong as a whole. And the person who discovers this last is always the person who does not speak the language.
Claude Shannon established in 1948 that a noisy channel can be made reliable only by adding redundancy: with a single pass and no second reading, the receiver has no way to separate the message from the error. Corporate reporting removed the redundancy on purpose, in the name of executive time. One channel, one summary, nothing to compare it against.
Four things a chief executive structurally cannot verify
Not “does not have time to verify”. Cannot. These four are unverifiable from the chief executive’s chair, by construction, regardless of how good he is.
Whether the risk he has been given is the risk that exists. A risk register is a translation of engineering anxiety into executive language. The conversion rate is set by the translator. When the same team reports a risk as moderate for four consecutive quarters and then the thing fails, nobody lied at any point: the word moderate simply meant something different inside the team than it meant on the slide.
Whether the option he was offered was the best option or the most comfortable one. Every technical recommendation that reaches a chief executive has already been filtered. Options that would have required admitting an earlier mistake, or that would have moved work away from the team proposing them, tend not to survive the filter. The chief executive sees three options and believes he is choosing. He is choosing among the survivors.
Whether the cost he is quoted includes the cost of the way it will actually be done. Estimates arrive as numbers, which look verifiable. They are not: they are a translation of a set of assumptions, and the assumptions do not travel with the number. The chief executive can audit the arithmetic and has no way to audit the assumptions, which is where the entire variance lives.
Whether what he decided is what got built. This is the one that hurts. A decision leaves the room as a sentence and arrives in the code as an interpretation of that sentence, made by people who were not in the room. Melvin Conway described the mechanism in Datamation in 1968: the structure of a system mirrors the structure of the organisation that produced it. The corollary is less quoted and more useful. If your organisation’s communication path to engineering has one lossy hop in it, your systems will encode that loss, permanently, in a form nobody can point at later.
These four are not the same problem four times. They are one problem: the chief executive holds the accountability for decisions whose inputs he is structurally prevented from testing. Kenneth Arrow described the general economics of this in 1963, in a paper about medical care of all things, and the mechanism transfers cleanly: when one party cannot evaluate the quality of what the other party is providing, the relationship stops being a transaction and becomes an act of faith. George Akerlof made the consequence explicit in 1970. Markets in which the buyer cannot verify quality do not merely become inefficient. They degrade, because the participants who benefit from opacity outlast the ones who do not.
A case: the migration that wrote its own business case
A company of roughly a hundred and forty people, profitable, growing at a rate that makes the board comfortable and the engineering team nervous. The platform is eight years old. It works. It is also, according to everyone who touches it, at the end of something.
In February the engineering leadership brings a proposal to the executive committee: migrate the core platform to a new architecture, eighteen months, a budget that is large but not absurd relative to revenue. The business case is well built. It contains a cost of inaction, a competitive argument, a hiring argument, and a risk section. Every number in it is defensible. The chief executive, who is not technical, reads it twice, asks four good questions, receives four good answers, and approves.
Here is what the business case is, structurally. It is a document written by the people who will execute the work, justifying the work, using information that only they hold, evaluated by someone who cannot check any of it. Every actor is honest. The document is still, in the strict sense, an interpreter speaking on behalf of both parties at once.
Look at what the translation does to each of the four arguments.
The cost of inaction is expressed as a probability of a serious incident rising over time. That probability is not measured, because it cannot be measured. It is an engineering intuition converted into a percentage, and the conversion happened in a room where the people converting it already believed the migration was necessary. The intuition may well be right. The number is not evidence, it is the intuition wearing the clothes of evidence.
The competitive argument says the current architecture prevents the company from shipping two features that customers are asking for. This is the part a chief executive feels most equipped to evaluate, and it is the part where the translation is most complete. In the engineering conversation, the actual sentence was closer to: those features are possible in the current architecture, but building them there is unpleasant, and the people capable of doing it do not want to. That is a legitimate constraint. It is a staffing and morale constraint, not an architectural one. Somewhere between the corridor and the slide, it changed category.
The hiring argument says the current stack makes recruitment harder. True, and unfalsifiable in the direction that matters. It is also the argument with the strongest personal alignment: the engineers proposing the migration would each become more employable on completion. Nobody says this, because it would be graceless, and because it is not the reason they believe the migration is right. It remains a fact about the incentive structure of the translation.
The risk section lists execution risks and rates them moderate. Not one of them is rated high. In a project of eighteen months touching the revenue-generating core of the business, that distribution is telling you something about the reporting culture rather than about the project.
Now the part that makes it a governance story rather than a story about a bad decision.
Month nine. Delivery is behind, in the way these things are behind: no single dramatic failure, a series of reasonable slips. The status reported to the executive committee has been amber for five months. Amber, in this company, means the team believes it can recover. It has meant that for five months, because the team has believed it for five months, and because the first person to say red will be the person who said it.
The chief executive asks the only question available to him: are we going to make it. He receives an honest answer from people who are exhausted and sincere: yes, if the next two sprints go well. The next two sprints do not go well. He asks again. Same answer, same sincerity.
At month fourteen the old platform is still running production and the new one is running eleven per cent of traffic. Both must now be maintained. The engineering team is split across two systems, which halves its throughput on everything else, which slows the migration further. This is the moment where the project stops being a project and becomes the company’s operating condition.
Nobody defrauded anybody. The chief executive made a defensible decision on the information he had, and re-made it a dozen times on the information he kept receiving. That is the point. There was no version of this in which better questions from him produced better answers, because every answer he got was a translation produced by the only people who could produce it, all of whom were inside the outcome.
What would have changed it is not a smarter chief executive. It is a second interpreter in the room at the February meeting: someone fluent in both languages, with no stake in the migration happening or not happening, whose entire function was to read the same business case and say which of the four arguments were architectural, which were about people, and which were about comfort. That conversation takes two weeks and costs a rounding error against eighteen months.
The company did not have that person. It had an excellent, honest, motivated engineering team, and a chief executive who trusted them, which is not a governance structure. It is a hope.
An independent translator is a control, not a comfort
In serious negotiation, each side brings its own interpreter. This is standard practice and it is not read as an insult. It is read as evidence that the parties are taking the conversation seriously.
The reason it works is not that two interpreters translate better than one. It is that each interpreter now knows he is being heard by someone competent. The mere presence of a second channel changes the behaviour of the first one, before anybody has corrected anything. This is the oldest control mechanism there is, and every mature governance function in a company already uses it. Jensen and Meckling gave it a name in 1976: monitoring cost, one of the three components of what it costs to have anyone act on your behalf. Monitoring is not what you pay because you suspect someone. It is what the arrangement costs, and refusing to pay it does not remove the cost, it defers it. An external auditor does not do the accounting better than the finance team. He makes the finance team’s account checkable. Nobody argues that hiring an auditor implies the chief financial officer is a liar.
Technology is the last executive domain where a company of two hundred people routinely operates with one unverifiable channel and calls it trust. The reasons are historical and mostly bad: technology was a cost centre for thirty years, it arrived in the executive committee late, and the vocabulary is hard enough that the people who hold it were able to keep it.
The independent translator’s job is narrow and worth being precise about. He does not decide. He does not manage. He does not replace the engineering leadership, and if he starts competing with it he has become a second interested party rather than a control. What he does is make the existing translation checkable: name what was rounded, restore what was dropped, say which recommendation is architectural and which is organisational, and tell the chief executive what he was not told, including the parts that are inconvenient for everyone including the translator.
The test of independence is simple and it is not about competence. Does this person’s income, career or reputation depend on the outcome of the decision he is translating? If yes, he is a party. If no, he is an interpreter. There is no third category, and no amount of integrity converts the first into the second.
You do not need to speak the language
The instinct, once you see the mechanism, is to try to learn the language. That instinct is wrong and expensive. A chief executive who spends a year becoming semi-technical arrives at a worse place than where he started: he now has enough vocabulary to be argued with, and not enough to win, which converts every technical conversation into a negotiation he is guaranteed to lose slowly.
The useful move is smaller. Stop asking whether you understand the technology. Start asking who translates it, and on whose behalf.
That question has answers. Who wrote the document I am deciding on. What would have had to be true for a different recommendation to reach me. Which of these arguments would still hold if the person making it had nothing to gain. Who in this building is paid to tell me the thing nobody wants to say, and if the answer is nobody, that is not a personality gap in my team, it is a hole in the structure.
A chief executive does not need to speak the language of his own systems. He needs an interpreter he can trust, which means one whose interests do not sit on either side of the table. Until that person exists, every technology decision he signs is a decision made on a translation he cannot read, and the accountability for it is his alone.
What you cannot verify governs you. That is true whether or not you have noticed it.
Sources
- Kenneth J. Arrow, Uncertainty and the Welfare Economics of Medical Care, The American Economic Review, 1963. https://www.jstor.org/stable/1812044
- George A. Akerlof, The Market for “Lemons”: Quality Uncertainty and the Market Mechanism, The Quarterly Journal of Economics, 1970. https://www.jstor.org/stable/1879431
- Michael C. Jensen and William H. Meckling, Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, Journal of Financial Economics, 1976. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=94043
- Melvin E. Conway, How Do Committees Invent?, Datamation, 1968. https://www.melconway.com/Home/Committees_Paper.html
- Claude E. Shannon, A Mathematical Theory of Communication, The Bell System Technical Journal, 1948. https://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf
- AIIC, Basic Texts: Code of Professional Ethics and Professional Standards. https://aiic.org/site/about-us/basic_texts
FAQ
Why can't a non-technical CEO simply learn enough to verify technology reports themselves?
Because four things are structurally unverifiable from the CEO’s chair regardless of technical skill: whether a reported risk matches the real risk, whether the option offered was the best one or just the most comfortable one for the team proposing it, whether a cost estimate includes the true assumptions behind it, and whether what was decided is actually what got built. Learning some technical vocabulary just means you now have enough to be argued with, not enough to win — it turns technical conversations into negotiations you’re likely to lose slowly.
What is the fix for a CEO who cannot independently verify technology reporting?
An independent translator: someone fluent in the technical and business language, with no stake in the outcome of the decision, whose job is to say which parts of a report were rounded, which recommendation is architectural versus organisational, and what wasn’t said. The test of independence is simple — does this person’s income, career, or reputation depend on the outcome of the decision they’re translating? If yes, they’re a party to it, not an interpreter, no matter how much integrity they have.
