Engineering decisions and business decisions are frequently the same decision described in two vocabularies. A choice about how a platform is structured is also a choice about how quickly the business can respond to a competitor. A choice about security controls is a choice about which categories of incident the organisation is prepared to absorb.
The technical judgement does not change when the audience does. What changes is that it has to be expressed in terms the audience can act on.
What translation is not
It is not simplification to the point of losing the constraint. If a proposed timeline is impossible because of a dependency, the correct translation names the dependency and its cost — not a softened version that leaves everyone believing the timeline is merely ambitious.
It is also not the removal of uncertainty. Presenting an estimate as a commitment because commitments are easier to hear is how technology functions lose credibility, one missed date at a time.
Governance as a shared language
Security frameworks are useful here for a reason that has little to do with compliance. A recognised control set gives a technical position a shape that non-technical stakeholders can evaluate. "We do not currently have this control, here is what implementing it costs, here is what it covers" is a decision a board can make. "We should improve our security" is not.
Architecture, engineering and security decisions should support measurable organizational goals.
Keep the technical detail somewhere
The risk in getting good at translation is that the translated version becomes the only version. A leader who can no longer follow the detail is dependent on summaries, and summaries are where inconvenient facts go to be rounded off.
Staying close enough to the work to read a design document, follow an incident review or understand why a query is slow is not nostalgia for a previous role. It is what makes the translation trustworthy.
Related topics
- Technology Leadership
- Strategy
- Governance