In "The Case for Generalists," I argued that organisations chronically undervalue translation capability – the capacity to move between technical, financial, operational, and strategic conversations and make sense across all of them.[2] I also named the retention dilemma that follows: develop a translator well, and you make them more attractive to every better-resourced organisation around you. There is no clean answer to that.
This piece considers a structural answer, rather than a retention tactic. It's a different question entirely. This article asks whether you have designed your organisation so that retaining one specific person was never the thing standing between function and failure.
Why a Single Translator Is a Structural Risk
When a translator leaves – poached, burned out, on extended leave, or simply gone – two things happen immediately. First, there is the obvious disruption: work slows, decisions stall, conversations that once ran smoothly start to fracture across the domains they used to bridge. Second, and more revealing, is what the leadership team discovers about itself: nobody else in the room can hold the technical-financial-strategic thread the way that person did.
The second realisation is the more important one. It is a sign that the organisation was designed for their presence rather than designed around a capability it needed to own. The translator was probably exceptional, but that's not the main point.
David Baskett, whose diagnosis of the translation problem prompted the first piece in this series does not pretend the problem has a tidy fix: retention strategies help, he acknowledges; creating genuine impact and autonomy helps; making translators visibly valued rather than depended upon without recognition helps. But the risk is real, and in his words, "the organisations that can least afford to lose a Translator are often the ones most dependent on having one."[1]
Baskett, here, is naming a design problem, not a personnel problem. If the most translator-dependent organisations are also the least resilient when that translator leaves, the dependency is what needs addressing, not just the likelihood of departure.
This is a specific, high-stakes instance of a broader pattern I covered in "Capability Debt": when expertise lives in a person rather than in an organisation's systems and structure, the organisation is exposed the moment that person is unavailable.[3] The translator is a particularly acute case because what they hold – the relational trust, the cross-domain fluency, the connective tissue between organisational layers – is both harder to document and harder to redistribute than most operational knowledge.
If your best translator left with four weeks' notice, who else in the business could sit in a room spanning finance, delivery, and strategy and be trusted by all three? If the honest answer is no one, that is the risk made visible. You did not choose this arrangement in any deliberate sense. It emerged because it was always faster to let one capable person handle the translation work than to build shared capability. That is still a design decision – just not a conscious one.
Distributed Translation Capability
Baskett's research across industrial transformation programmes found one consistent marker in organisations that succeeded: they had "someone – or a small team" who could translate.[1] Not a governance framework. Not a committee. A person, or a small group of people, trusted by the shop floor and the boardroom simultaneously.
The crucial phrase is "small team." It appears in his work without being fully developed, because his concern is identifying the capability rather than prescribing its structure.
A small team is not five generalists all doing the same thing. It is two or three people whose translation capability overlaps enough that the organisation does not collapse when one of them is unavailable. The second person does not need to be as fluent or as experienced as the first. Partial translation capability spread across two or three people is more resilient than concentrated excellence in one, even if the aggregate quality is lower.
The practical starting point is identifying who already has partial translation capability in the organisation. In my experience, this is rarely zero. There is usually someone in a delivery or operations role who has started to develop cross-domain fluency, but who defaults to their specialist lane because the primary translator is always available and always faster. They absorb the translation work because it is efficient. In doing so, they prevent anyone else from developing the capability.
This is the trap. The competence of a strong translator reinforces their own indispensability, not despite their skill but because of it. "It's faster if I just do it" is a rational decision in the moment and a compounding risk over time. Every time the primary translator handles a cross-domain conversation solo, the organisation's second-order capability atrophies a little further.
The design response is deliberate redundancy: identifying emerging translators, giving them cross-domain visibility, and tolerating the slower, less polished translation they will produce while they are developing. The slower conversation, the less precise framing, the occasional missed connection between what the engineering team needs and what the financial risk actually is - these are the development costs. An organisation that is not willing to pay them will always snap back to the single translator, because that is always the faster option.
Structural Scaffolding for Translation
What actually has to exist for distributed translation capability to become real?
Deliberate cross-functional rotation. Translation capability is developed through exposure, not instruction. Someone who has spent two years entirely within a delivery function has not had the opportunity to develop the commercial framing that makes their insight useful to a CFO. Rotation – structured, deliberate, designed rather than left to individual curiosity – is how you create the conditions for generalist capability to develop in more than one person. This echoes the development guidance in "The Case for Generalists,"[2] but the emphasis here is on structure: rotation will not happen just because people are curious; it happens because the organisation designs it in.
Shared cross-functional review rhythms. Translation done in one person's head, behind closed doors, is translation that cannot be observed, learned from, or redistributed. When cross-functional review happens collectively – when the conversation about what a technical constraint means commercially happens in a room with multiple people present – it becomes visible. The reasoning is on the table. Others can follow it, question it, and begin to internalise the logic. In Mantage's agile strategy delivery practice, these shared review points are built into the operating rhythm precisely because they serve both a decision-making and a capability-building function simultaneously.
Decision rights that do not default to one name. If every trade-off call that spans two domains lands on the same person, the organisation's translation capability has remained concentrated regardless of how many people are nominally "developing". Explicitly naming who else is authorised to make the calls a translator normally makes – even if they are slower and less certain – distributes both the practice and the accountability.
Documentation of reasoning, not just decisions. Capturing what was decided is less useful than capturing why. A decision log tells a future colleague what was chosen. A reasoning record tells them how the technical constraint, commercial risk, and strategic priority were weighed against each other – which is the translation work itself. This is what transfers capability beyond the person who first held it. Standard documentation captures output; reasoning documentation captures the thinking that produces it.
Each mechanism has to be built into the operating rhythm. Organisations that maintain distributed translation capability treat it the same way they treat their planning cadence or their financial review cycle: as a structural part of how the business runs, not as something they do when they are worried about a specific person leaving.
The Limits of Design
Some translation capability is genuinely relational and cannot be distributed. Deep trust with a specific board member built over years of honest, difficult conversations. The particular credibility a translator has earned with a technical team that has seen them get things consistently right. A client relationship where the value is partly the translator's ability to read unstated concerns and navigate them. These things are not transferable in the way that a decision framework or a review rhythm is. They are personal, contextual, and time-dependent.
Distributing translation capability also has a cost in the short term. Building the second and third translator takes longer than keeping one exceptional one, and the quality of translation they produce while developing will be lower. Leaders have to tolerate less polished output from less experienced people, and the organisation has to absorb the occasional gap in connective tissue while those people find their footing.
The goal is resilience, not immunity. A business with distributed translation capability still loses something tangible when a strong translator leaves. That loss matters. What it does not lose is its ability to function – to hold the cross-domain conversations that strategy execution requires, to make the trade-off calls that keep delivery connected to commercial reality, to maintain the connective tissue between organisational layers that "The Case for Generalists" identified as the critical and chronically undervalued capability.[2]
Design reduces the exposure and shortens the recovery time. It does not eliminate the risk.
Designing for Resilience, Not Heroics
"Have we designed this organisation so that it does not depend critically on whether one specific person stays?"
That question points to rotation policies, shared review rhythms, explicitly distributed decision rights, and documentation practices that capture reasoning rather than just outcomes. It points to identifying the emerging translators in your organisation and giving them room to develop at the cost of some short-term polish. It points to treating translation as a structural capability the organisation holds – not a personal one that you are hoping to retain.
The two pieces together make a single argument. "The Case for Generalists" names the capability, makes the case for developing it deliberately, and identifies the retention dilemma that follows.[2] This piece addresses the structural question that dilemma raises: not how to retain more effectively, but how to design so that the dependency is distributed, the connective tissue has more than one load-bearing thread, and the organisation is built to last beyond any one person's tenure.
Resilience is not heroics. It is design.
References
- David Baskett, "Industry Has a Translation Problem", Medium, March 2026.
- Ady Coles, "The Case for Generalists", Mantage, 2026.
- Ady Coles, "Capability Debt", Mantage, 2026.
Ady Coles works with leadership teams to help strategy survive contact with reality. His focus is on strategy management and agile strategy delivery - designing the translation between intent and execution so that direction remains coherent as organisations move, grow, and adapt. He works as a fractional and advisory partner where clarity, judgement, and sustained alignment matter more than plans on paper.