On the about page of Tech to Human, tech translation is defined as:

Making technical topics more accessible and inviting by being deliberate about the language used to talk about them.

I first understood how direly we were in need of more tech translators when I heard the below story from a contact in the UK government (we’ll call him Barney). Barney was responsible for overseeing and commissioning digital products within the UK government.

---

What happens when we don’t create inviting spaces to talk about tech

At the end of a long day, Barney is approaching the office lift on the way home. As the doors part Barney steps in, relaxing slightly, happy to have found a moment’s peace. The doors begin to close.

Photo credits: Dragan (Flickr). CC-BY.

A moment later, Barney’s moment of calm is interrupted by one of his team (we’ll call him Ernie) forcing his way through the closing doors, dishevelling his tie and suit in the process. Ernie splutters:

Barney, you gotta help me. I insisted to people that the new service had to have an API, but that was because I hear everyone talking about APIs all of the time… I… err… don’t actually know what one is… and now they are asking me for details…

---

Ernie’s situation is a surprisingly common one: that of a decision maker unable or unwilling to reveal gaps in their knowledge. There are many reasons why Ernie may have ended up in this position. Maybe it was the culture or structure of the organisation that did not make it seem ok to show this vulnerability.

The implications of this problem are widespread. Organisations waste huge amounts of money every year and the wrong things can be built, see my dashboard rant. Sometimes, there are also lethal consequences.

My path to tech translation

In the first few years of my career I worked almost exclusively with people who fitted into one of two categories:

1. Self-taught developers who had been programming in one form or another since the age of 12
2. People in managerial roles who had come to tech later in life and did not code.

I fell into the latter group. That meant that there was a massive knowledge gap — from in-jokes to technical knowledge — that I needed to fill. There was some culture shock at first (see my very first post on the topic) and I was paranoid that my inability to code would hold me back from being able to perform as a fully functioning team member (see myths of fluency).

I eventually worked out that I had one trump card: I was not afraid of telling people that I did not understand something.

It turned out that this also benefited the team. Forcing them to break down topics to ensure that I understood them meant that team members had to speak in plain terms, reducing the number of misunderstandings with everyone else. Perhaps, at times, this was frustrating for the team, but I decided to be intentional about turning my ‘weakness’ into what I thought could be an asset. Once I was comfortable enough that I understood a topic, I could pay this forward to ensure that the stakeholders understood the topic, meaning the team was not bombarded with clarification requests.

From there, I moved into training and capacity building roles where I observed that those who had recently learned something were often best placed to teach it. Finally, I landed in a product management role, which was what I was advised to do whenever I told someone that I enjoyed ‘tech translation’ and told them how I defined it.

As Zara Rahman points out in her post, there are many roles which have an aspect of tech translation in them:

The role exists under many names, and it’s often present in an ad hoc way. Some product managers do it. Some UX designers do it. Some community managers do it. Some people think of it as tech translation, or playing a bridge or a broker role, or even being a catalyst or champion among a community.

Everyone will have a slightly different journey to becoming a tech translator, there is no specific training to do it. It is a soft skill which needs to be recognised as something that is worth spending time on.

Summary

So what are the fundamental aspects of tech translation? If your job contains large chunks of the following, congratulations: you are probably a tech translator! :)

• Communication — translators prioritise communication. That may mean explaining something again and again in different ways until the stakeholder gets it, but it is worth it.
• Context — the translator invests time to understand the context in which the project is operating so that they can relate their solution to real-world things.
• Compromise — all tech projects have to make tradeoffs. A good tech translator can explain the implications of all of the options and work with stakeholders to guide them to the best outcome of a project.
• Combatting hype — speaking in plain terms (NO JARGON) about the problems to be fixed helps to avoid hype around the next big thing (no, your project is not a big data project).
• Culture — are there specifics of the culture or language which need to be taken into account when designing a tech project? I consider it no coincidence that some of the best tech translators are multi-lingual or have backgrounds in ethnography / sociology / anthropology.

Overall, tech translation is about creating a sense of Comfort, that you are approachable enough to ask questions and giving them a sense of Control over the project, particularly if you are an outside contractor or a technical partner.