Org Design : Where Should Localization Live Within A Company

Most of the companies I worked with didn’t really know who should own localization. Sometimes we would roll up to marketing, sometimes to product, sometimes to engineering, and sometimes to customer support. When I was at Lyft it seemed like there was a re-org every few months. This lack of stability and long term ownership caused uncertainty about everything from budgeting to QA. Localization and global expansion is a multi-year effort, so it is important that it has executive sponsorship and a long-term planning horizon. In this article we discuss where localization should live in an organization, and what arrangement yields this sort of long term focus and alignment.

Rebranding Localization To International or Language Experience

My top recommendation is to rebrand localization as international or language experience. People outside of the localization industry don’t know what the term means, and it is also conflated with physical localization (which applies to autonomous vehicles). I use the term internationalization when talking to people outside the industry, since they understand what that means. Technically internationalization refers to things like date formatting, but for the purposes of communicating with prospects this works.

By rebranding the team, there will be less confusion about what you do. More importantly, this positions you as a strategic resource for the company whereas translation and localization is often viewed as an afterthought and as a cost center. When I was at Notion, almost 70% of our users were outside the United States, so management understood the importance of making the product work for users in other languages.

Product Or Engineering Is Often The Best Fit

My experience has been that we got better resourcing, especially engineering support, if we were part of the product or engineering teams, especially growth engineering. The most valuable part of this is getting engineering support to address functional issues that translators can’t fix (database sort order, filters, layout problems, etc). These teams also have a growth mindset and are less likely to view you as a cost center.

This is particularly important in the early stages of building for international and language accessibility because companies will usually need to build out process automation, TMS integrations and often refactor their code to support multilingual operation. How long this will take will depend on how much tech debt the company has accrued. (At Lyft, it took nearly two years because they had a complex product that had assumptions about the US and English baked into so many different parts).

That doesn’t mean you can’t work on other customer touch points. It’s just better if you are part of these teams.

Marketing

Marketing, although it usually needs operational support for localization, should not be the owner of localization. The reason for this is a basic misalignment. Product and engineering build and maintain the product, while marketing sells the product. Localization is never “done” because there are always new features to launch and bugs to resolve. Selling is also downstream of building, so if localization is owned by marketing it is usually treated as a downstream checklist item, and not part of building the product.

One of the big problems that arises when localization teams roll up to marketing is they are often treated as service centers, and are not involved in cultural adaption as a first step before translation. This problem is especially acute in US based startups which make a lot of assumptions about culture and user habits that simply don’t work in other regions.

I remember one campaign at Notion. They had a excellent marketing team, but even great teams don’t always know what they don’t know. The campaign slogan was “Your life and your work, All in one place.”

This slogan was easy to translate into other languages. The problem was that outside of San Francisco startup land, nobody wanted their life and their work all in one place. The campaign underperformed in non-US markets, probably because of that failure to adapt it or use something else entirely. This would have been avoided if they had worked with in region agencies and experts who understood these issues.

These days I advise regional marketing teams to own creating and adapting campaigns. The centralized internationalization team can help them by providing and managing translation infrastructure. Most TMS platforms support a wide range of assets, including offline documents, PDFs, etc.

Generally what marketing teams should do is to engage with agencies that know how to create campaigns for the target market. The internationalization team can onboard them to the translation management platforms, so the work can be managed centrally, but otherwise the marketing team will manage those vendors and their deliverables. The team can certainly provide advice and help in reviewing agency proposals.

This also ensures that the teams are aligned. This is important because it keeps you out of the position of being blamed for a campaign that did poorly because it wasn’t culturally adapted (which needs to be addressed before any translation work is done).

Other Customer Touch Points

One of the main goals for the team is usually to ensure that most customer touch points are accessible in other languages. This involves implementing integrations with other systems including content management systems, help center, life cycle communications, videos, and so on. This is another reason why it is important to have engineering support because sometimes you will need to build custom integrations if your TMS doesn’t provide one. Ideally, you want to be involved in the discussions around choosing these systems, to ensure that multilingual support and TMS compatibility is taken into consideration. Unfortunately, these decisions are often made long before internationalization is kicked off.

When I go into a company, I like to automate as much as possible, with the goal of making translation happen by default. That doesn’t mean using machine translation for everything. For example, if someone adds or updates a help center article, it gets picked up for translation and review without the author needing to make a request (which they will often forget to do if they need to make a manual request). This is a scalable approach and frees up the team’s time to focus on prioritization versus shipping files and spreadsheets back and forth.

What About Legal?

Legal teams will generally want to use a translation agency that focuses on legal translation, contracts, etc. You definitely don’t want to send this material to generalist translators. They usually have preferred vendors, or will have their law firm handle this for them (which is usually expensive, but then again, most lawyers are expensive).

Legal translation is specialized, and is riddled with liability concerns. For example, who is on the hook if a legal contract or terms of service is mistranslated? Does translating terms of service create additional liability or legal exposure in foreign markets? Most localization experts are not lawyers and are reluctant to touch this.

What you can do is give the legal team access to translation tools (TMS, etc). They will probably use their own vendors and processes, which is fine.

Where It Should NOT Live

There are several places the internationalization team should not be. The two big ones are customer support and IT (especially not IT). The customer support team, while it will often want its assets to be translated, is often under-resourced, and under constant pressure to automate everything to reduce costs. This leads to a cost cutting mentality instead of a growth mindset. Quality will suffer, and then the team will be blamed for being underfunded. IT simply doesn’t know what to do with it.

Pro tip for job seekers : if you see a localization role, the job listing will often indicate which team the role reports to. If reports to product or growth engineering, A++. If it reports to marketing, dig into that more to find out if there is support from product or engineering. If it reports to IT, run away!

Thoughts On Team Size

We discuss this at length in the article Building Out A Localization Team, but here is a TL;DR in terms of what to expect in terms of staffing.

Early stage companies (low localization maturity) typically start with product localization, and initial tooling around that. At this point they don’t need a full-time, in-house team, but they do need expertise on vendors, platforms (TMS, CMS, etc), something with we can help with via fractional staffing. The focus here tends to be more technical, with an emphasis on training EPD staff and technical program management, especially building out automation and infrastructure.

Mid size companies (medium localization maturity) are expanding beyond product localization to most customer touch points. They have usually settled on core platforms and vendors, and are focused on things like rolling out more language and expanding translation coverage to more touch points. This customer is typically series B to pre-IPO and can often be served well by a fractional leadership approach.

Large companies (high localization maturity) are mainly focused on scaling into more languages and regions, and by now have good automation and tooling to support this. The focus often shifts to operational efficiency. At this point it usually makes sense to bring the program in house, although even at large companies, localization is often a lean team that orchestrates work done by vendors and contractors (at Notion, the in-house localization team consisted of three people and is still pretty lean today).

Conclusions

Localization, which is probably best thought of as international experience, will be best position in the EPD organization, ideally with growth engineering if that organization exists. That said, it is an inherently cross functional team that supports almost every team within a company. It is a core part of building and maintaining the product, and should live in a team that shares that mandate.

Where Should Localization Live In An Organization