The translator problem

An engineer says the integration is brittle. The program manager hears that it works, because today it happens to be working. Six weeks later it breaks in front of a customer, and both of them privately conclude the other person is the problem. Neither is. They were never speaking the same language, and no one in the room could translate.

I’ve spent most of my career in that gap. Defense programs, acquisition shops, government modernization efforts: the setting changes but the gap is always there. Smart engineers on one side. Capable program and contracting people on the other. Between them, a quiet and expensive misunderstanding that nobody is assigned to fix.

The first thing worth understanding is that both sides are behaving rationally. Engineers reason about the system as it actually is, its real state, its failure modes, the things that will bite you eighteen months from now. Program and acquisition people reason about what they are accountable for: cost, schedule, compliance, the commitments already made to people above them. Each group has almost no visibility into the other’s constraints, so each reads the other’s caution as obstruction and the other’s confidence as recklessness.

What makes this dangerous is that it doesn’t look like conflict. Open conflict at least gets attention. This is the opposite. Everyone leaves the meeting believing they reached agreement. The engineer thinks the schedule risk was acknowledged. The PM thinks the team committed to the date. Both write it down differently. The disagreement surfaces months later with money already spent, and by then it reads like a betrayal rather than a translation failure.

Translation between these worlds is a real skill, and it stays rare because you can’t fake it with a glossary. You can only translate a domain you genuinely understand. Someone who knows the software at surface level and the acquisition world at surface level produces summaries, not translation, and summaries are where the load-bearing nuance quietly disappears. Real translation means taking what one side knows and converting it into something that changes what the other side decides. That requires standing in both frames at once, fluently, which very few people manage because the path to that fluency is long and looks a lot like wandering while you’re on it.

Organizations under-invest in this for a plain reason. When translation is working, nothing happens. No expensive surprises, no programs quietly dying, no eighteen-month rebuilds. The output of a good translator is an absence, and absences are hard to put on a slide or defend in a budget review. So the role gets treated as a nice-to-have, right up until the program it was silently protecting falls over.

The words that cause the most trouble are the ordinary ones. “Requirement” means a fixed obligation to one side and a current best guess to the other. “Risk” means a technical reality to one group and a reportable item to another. “Done” might be the single most dangerous word in any program, because everyone is certain they know what it means and no two people mean the same thing by it.

If you run or build serious technical programs, you almost certainly have capable people on both sides. That was never the shortage. The shortage is anyone whose actual job is the space between them. That space sits empty on most programs, and an empty space between two rational groups who can’t quite hear each other is exactly where good programs go to die.