A typical Monday in a typical company. An important project is scheduled to ship next month. The steering committee (tech team, stakeholders, sponsoring executive) is reviewing launch readiness.
Bob, the senior engineer, says: “We should postpone the go-live. The load tests don’t scale past 3x current traffic, and the new endpoint has been firing 500s in test for a week.”
Alice, the sponsoring C-level, hears: techies complaining again. We’ve been working on this for months. Her reflex is to ask whether they can ship anyway and fix it after. Bob hears the reflex and concludes — not unreasonably — that the executive doesn’t understand the risk. Both leave the room frustrated. Nothing is decided. The conversation will repeat next week, with more pressure and worse terms.
This is not a failure of intelligence on either side. Both people are doing their jobs, in the language their jobs are built in. It is a failure of translation.
Wherever two layers must coordinate, translation is somebody’s job — and that somebody is whoever sits, usually in a leadership position, between them. The role changes. The work doesn’t.
Why translation is hard
Each layer in an organization operates in its own register. The engineer’s primary concern is designing, implementing for correctness and stability, and the things that go wrong on a Friday afternoon. The executive thinks in revenue trajectory and the bets the company is making on what it will become. Sales lives in the current quarter. Finance closes books on the year. Not only languages, also timescales differ.
A perfectly accurate statement in one register can be noise in another. The engineer’s “500s errors in API test” and the executive’s “are we on track?” are not the same kind of sentence but they are the same kind of concern. Without translation, they do not even properly disagree. They miss each other entirely.
There is also a second hidden source of misalignment: context traveling across layers. The people who weren’t in the room eventually pay the price of decisions made there. A choice that went through ten conversations and three rejected alternatives arrives downstream as: the change. Employees see the result, not the thinking. Most resistance to organizational change is not opposition to the decision, rather it is the absence of the context that produced it. The translation runs in this direction too: backwards into the organization, carrying the why alongside the what.
What are we translating between?
I learned several languages before I wrote my first line of production software, and the part of translation that is least understood is this: the hard part is not vocabulary or grammar. The hardest part is that the source culture’s assumptions do not map onto the target culture’s assumptions. The translator’s job is to reconstruct meaning, not transfer words.
A good translation produces, in the target language, the effect the speaker meant, which sometimes requires saying something quite different in literal terms. The Italians do not actually wish other people to be eaten by a wolf (“in bocca al lupo!”). The British do not wish them to break a leg. Both are wishing good luck. The surface form changes. The intent does not.
This is not an analogy when applied to organizations. It is the same mechanism, applied to a different sign system.
When Bob says “the load tests don’t scale,” he is encoding, for the customer support team: if we go live now, you’re going to be in for a very rough week. We’ve found a bottleneck that will cause the system to freeze as users pile in. Instead of celebrating a launch, you’ll be answering calls from frustrated people we can’t actually help yet. For the C-level, the same statement encodes: we’re at a crossroads. We can hit the deadline and risk a high-profile crash on day one, or we can stabilize first. A delayed launch hurts. A failed launch — in front of the partners we’re trying to sign — hurts considerably more.
Same problem. Different decoding. Neither wrong. Both necessary.
Translating in the other direction
The direction most leaders skip is the harder one, in the other direction.
An executive’s “we need to commit to this date — the partnership cannot accept delays” encodes a real constraint the engineer is not seeing because it doesn’t appear in the codebase. A revenue line. A relationship that took two years to build. A commitment made on behalf of the company in front of investors or important customers.
The worst thing a leader can do here is pass that pressure down unfiltered. I have seen it often and I’ve seen the incredibly negative effects it generates. The team hears urgency without meaning, and just feels not heard and pressured. “Why are those high-level people not able to understand how hard / bad this is?” The team doesn’t understand the constraint, so they can’t commit to it. They just feel like they’re being asked to do something impossible and even worse, for no visible reason.
The translation looks like: this new product funds the team’s growth next year. Shipping a working v1 in three weeks means some stressful days, yes, but it earns us the time to do v2 properly once the contract is signed and enough funds to hire the extra engineer we are missing. Here is the trade-off we are accepting, and why. The team can commit to a trade-off they understand. They cannot commit to pressure they cannot decode.
Where translation debt accumulates
Every organization has a translation debt: the accumulated cost of conversations where the layers didn’t meet. It doesn’t have a clear cost-center in the finance department, but is very visible in the postmortem.
Co-authored plans, cross-department initiatives, are among the cleanest repayment mechanism I’ve found. A roadmap written jointly by engineering, product, and finance is a translated document. All three can defend it in front of the board, and the trade-offs inside it are visible to all three. Compare this to the plan written in one department’s language and passed upward for approval by people who only “speak” another. The approval is superficial if any. The commitment is thin. And when the deadline slips, nobody is quite sure why they agreed to it in the first place.
One structural shift I did not anticipate: AI is redistributing part of the translation surface. In my organization, some POs now have read-only codebase access paired with an LLM configured to answer questions about logic, dependencies, and behaviour. A question that previously routed through an engineer’s calendar gets answered in two minutes, with the actual code as the source. The leadership move here is not just “deploy the tool”. It is to notice that the translation surface has shifted, and redirect the saved bandwidth toward the translation work that cannot by done by AI: the hard cross-horizon trade-offs, the moments where what matters is not the answer but the why behind it.
What a translator-leader is not
Not a yes-person. Not their team’s permanent defender, who always negotiates the next delay and absorbs every criticism on behalf of their team. An organization learns to deliver despite that leader, not with them.
Translation is also not concession. I understand and can articulate your position is not the same as I agree with it. The point is that an aligned organization is one where each layer can accurately articulate the others’ positions — well enough to defend them in a room where the others aren’t present.
The signal I listen for in hiring conversations: does the candidate describe their job as representing their team, or as translating between their function and the rest of the business? The second is the one that scales. The first, sooner or later, builds a wall they call advocacy.
Disagreement on a shared map is productive. Disagreement on different maps is the silo problem. The work of building alignment is not the work of building consensus. It is the work of building mutual comprehension and then staying in the room long enough for it to hold.