Challenges with the delivery narrative

From our own knowledge, and our recent interview series, here are some of the challenges with the delivery narrative.

1. Negative perceptions of localization

I. A necessary evil 

Some localization professionals are concerned that delivery-only departments are perceived as a “necessary evil.” Those were the words of a Localization Director Global App Testing (GAT) spoke to on background. 

“I want to advocate for deeper localization,” he told us, “but engineers perceive us as a kind of necessary evil. I want to make the argument that there’s an ROI on deeper localization.” 

It also cropped up in our recent interviews:

‘It’s very easy to get pulled into being this in-house translation agency,’ Iggy, Localization Manager @ Deliveroo had told me. ‘Or a necessary evil at the end of a process.”

One of the consequences of regarding l10n as a barrier-to-release, rather than an investment, is that it comes to be perceived as a cost center, which can cap the value you can deliver. 

II. A commodity 

A related idea would be that localization is a “commodity”.  

“I feel that localization in general is perceived as a commodity”, said Natalia, the Terminology Manager at Google, in her interview with GAT, although she added “not at Google”.

To spell out what this means, a commodity is a good which is fungible or largely fungible – for example, that translations are all equivalent, in the same way that gallons of crude oil would be equivalent.

Selling a “commodity” is not necessarily a negative thing, but does transform how we might look at our understanding of success. As a commodity, localization success would be about delivering localization quickly and cheaply.

2. Wildly different workflow expectations

If localization is about delivering high quality quickly, it raises a question. How fast should you be delivering things?

In his interview with GAT, Robert Bauch, a Product Program Manager at HubSpot described the challenges of product and marketing working through i8n challenges together.  

Marketing copy needed to be “polished to the max” said Robert; his world of product needed to be more consistent to specialized language libraries – and much faster.

“In product, we needed to keep moving. We were pushing code to production hundreds of times a day. 3-400 times a day. We needed [a translation process] to keep up with that.”

Natalia, a Terminology Manager at Google, used to work for a language service provider. In her interview, she said that they sometimes had to educate marketing teams.

“It could be difficult to have conversations”, she said, with teams who “understand tone of voice – but not products, development and release cycles, or anything else from a best practices standpoint.”

How do you thread that line?

We explain below. 👇

3. A lack of awareness of non-American user needs

Steve Jobs articulated one of the most famous ideas in product. 

“You have to start with the customer experience” he said, “and work backwards to the technology.” 

Does that happen in localization teams? Consider the following categories of product localization:

With the exception of Slack, every business we spoke to varied the extent to which they localized depending on things like market size. But teams focused on “B” don’t introduce users from local markets at their planning stage, so the content or product is likely to be further from local user needs. 

Natalia, Terminology Manager @ Google said: “Let’s be frank. It’s very difficult for someone to think of terminology for global audiences. When content creators, or the content owner thinks about what they’re going to produce, they usually do it in their language… so that means they might focus all their efforts into that.” 

4. A trade-off between speed and quality 

A trade-off between speed and quality is well-known to anybody who works in software. In fact, many engineering ideas seem to be creeping into a space formerly run by translators. “We work in CI/CD” said Diana, Content Localization Manager @ Pleo, who was not from a technical background.

”Continuous Integration & Continuous Delivery” is a framework which describes how you can deliver software effectively in a software team. It makes recommendations about automation in your release cycle, for example; but we’ll talk more about that later. 

It’s also a challenge to get good translations from third-parties at pace. 

Natalia (Google) described the “Holy Trinity” of using third parties to deliver your translations – speed, quality, price. “You can’t have all three”.

   Key takeaways from chapter 1