Why does localization seem like a black box? How can we open it up and make it less elusive? These are questions many companies wrestle with. When you work at a company that’s going global, it’s important to be able to communicate quickly and efficiently about localization, but that isn’t always easy! In this post, I’ll attempt to break down localization project management to help demystify it.
Note: This post refers to localization project management in the context of large tech companies. This post does not cover supply-side localization project management at language service providers (LSPs), which is a related but separate topic.
What Is Localization Project Management?
Localization project management is basically the art and science of making localization happen. The problem? Project management is a bit limiting as a term, because it can mistakenly lead people to think of localization as merely managing individual projects, making it sound deceptively simple. “Operations” is much more fitting in my opinion. Business people want to believe localization is a simple process, but “operations” implies greater complexity and helps change the baseline conception from where the conversation unfolds.
If you work for a company that is fast-growing, relies on continuous deployment to any degree, and has revenue operations as a central part of its growth engine, people will likely tend to understand the notion of operations a bit more readily than localization itself. I often refer to project management as the “operations” side of localization or “LocOps,” as these terms ring more accurate for folks on the business side.
Key Considerations: Business + Technical
The considerations that go into localization project management are numerous. When stakeholders come to a localization team seeking support, they often seem surprised by how involved a project can be. The list of items a project manager needs to go through in order to create the right workflows and assign the best-suited vendors, can overwhelm those who are requesting localization help. Those without direct experience in localization will often assume, “It can’t be that complicated” and try to go it alone, or go off looking for an easier or simpler path than the one proposed.
In reality, localization usually is that complex. Why so? Let’s break it down.
A professional localization team will be thinking about two basic categories when figuring out how best to localize something. The considerations fall into either the Business side or the Technical side of things. The infographic below shows 12 of the most important factors that localization project managers usually consider. There are more items to factor in than just these. I’ve only included these 12 because these are typically the factors that cut across most projects. Let’s dive into each of these considerations one by one.
Business Considerations: Understanding Localization Stakeholder Needs
Working well with stakeholders is the most important ingredient for localization project management to succeed. Strong relationships and excellent communication are key to achieving great partnerships between localization and the parts of a business that require localization support. In the most mature localization systems, and in companies with a high degree of global experience, the localization team partners effectively with teams in many other parts of the company, viewing each others as team mates who are all rowing in the same direction.
To build on the rowing analogy, it takes time to learn what pace different team mates are able to row at, and to strike the right speed together. It requires practice and strengthening new muscles, or building them from scratch in some cases. It can be hard for teams to learn each other’s distinct business areas quickly. Often, Product is a natural partner for localization teams. Both teams tend to row at similar paces from the get-go. They both tend to think and plan in terms of systems and scale. Product teams are very tech-savvy, which is great news for people working in localization. So, this tends to be a partnership that is fairly low-friction, or friction-free, at most companies.
To Achieve best results, View localization Teams As Strategic Partners, Not Service Providers
The ideal scenario is when a stakeholder group at a company views the localization team as a strategic partner. This mindset solves for the best interests of the company at large, and is the framing that every localization team needs to work toward. Internal teams at companies should look at their Localization teams much in the same way they look at their internal Legal and HR teams. These are all teams with deep expertise and specialized knowledge. They are prepared to support and advise other teams on the best steps to take to accomplish a given goal.
A toxic scenario occurs when internal partners look at their localization team members like “order-takers.” With that framing, a team might as well just work with any external translation agency instead of with an internal center of excellence that is well-versed in the company’s localization technical needs, resources, and vendors. Sometimes though, it’s actually necessary for localization stakeholders to do precisely that, until they gain some experience with localization, after which they can develop a greater appreciation for this domain. Otherwise, the collaboration can prove unhealthy.
Business Considerations: Impact, Audience, Speed, Budget, Quality, Domain Expertise
Now, let’s look into the 6 key areas that fall under Business considerations that localization project managers have to think about when looking into how to best deliver a localized experience.
1. What impact will this have for our customers / company / stakeholders?
One of the very first questions a Localization team will want to answer before doing a localization project is whether you actually need to localize in the first place. You’d be surprised by the number of times a business doesn’t actually need to localize something. A very common (but misguided) assumption at companies expanding internationally is that they should do the same things they do for every other market, exactly the way they did things for their home market. The problem is that you didn’t enter those other markets at the same point in your company’s growth. So, chances are that you don’t need to do things the same way. It’s likely that there are easier ways to go about the same goal, that might yield even greater impact, than the dreaded “copy-paste” motion so many companies go through as they move into other countries, learning the hard way that it isn’t the fastest or most effective approach.
For that reason, it’s important for a Localization team to understand the Impact the company is hoping to have. It’s incredibly important to ask, “What goal is our company trying to accomplish?” at the very beginning of every initiative. A localization project that lacks a stated goal or clear metrics behind it is one that is usually doomed for failure. Before every project request, the question should be, “Why does it matter?” If you can answer this question, all teams can row in the same direction. The Localization team can come up with solutions that help solve for the bigger picture goal, versus flying in the dark toward some unknown target. In many cases, the Localization team will be the first to admit that Localization is not the ideal way to solve the problem.
The goal is never just to localize. The goal is to influence a specific business metric.
For example, perhaps a marketing manager comes to the Localization team with a batch of social media posts that they want localized into German. Stakeholders might say “we just want to localize them.” That’s rather simple and is just a question of budget. But if the real goal is to increase social reach, localization alone might not be the solution. In that case, the Localization team might flag that only about 30% of the posts will actually make sense in the German market even when localized, because they reference trends, people, and brands that are not popular in Germany. Rather than the marketing team wasting their budget on content that won’t help them achieve their goal, they can pay to localize just 30% of the posts, and use the 70% of the budget they would have spent on Localization on some other tactic, such as native content in language, or advertising instead.
If you’re a stakeholder working with a localization team, make your goals extremely explicit, so that your localization team can partner with you to achieve them.
Consider Whether You’re Trying to Obtain a Positive Impact or Avoid a Negative Impact
The social media example above is an example of positive impact for a brand. But another way to think about Impact is the potential negative impact of something, or the risk it could entail for the company if localization goes sideways.
Here are some examples of negative impact that could shape how a localization project manager decides to carry out your project:
- Your company has launched a new web-based tool to generate new leads and wants it to be localized, but the associated email workflows cannot be localized yet as they are being audited and won’t be ready to localize for 3 more months. Potential negative impact: leads that won’t be nurtured in time to make any impact on revenue.
- Your company wants to localize a press release into a language and is in a rush and wants to use Google Translate for it to get it out quickly. Potential negative impact: possible mistranslations resulting in damage to the local brand.
- Your company’s security policy needs to be localized but no one is sure whether it needs to be compliant with US law or the laws of countries of the target languages are spoken. Potential negative impact: risk of litigation.
2. Who is the audience / end user for this content / experience?
Who is the ultimate stakeholder of this content or experience in other languages? Is it designed for your website visitors, leads, prospects, customers, users, decision-makers, influencers, partners, employees, or someone else? Localization project managers need to understand the profile of the person on the other side of the experience, as well as an estimate of the size and scope of the audience, in order to make the best decisions for your project. The audience / end user for your original content / experience might not be the same as it is when you localize into other languages. For example, users in some languages might be more or less familiar with certain topics than your source language users.
Also, some estimate of the scope of impact here is helpful too. Will this content or experience by accessed by hundreds, thousands, millions? Do you estimate 1,000 views per month or 10,000? Having a sense of this enables your Localization team to understand what types of workflows and vendors to use. This also might depend on the language in question. For example, let’s say you need to localize some content that won’t be used very regularly by large groups of people, and the risk level associated with it is low, but for one market, English proficiency is rather high, and for another target market, English proficiency is low. In that case, your Localization team might decide to use machine translation for the high-proficiency market that can probably look at the English version if needed, while they might recommend using human translation for the low-proficiency market, who will depend on this content far more.
3. How soon does this content / experience need to be localized?
Usually, the answer to this is “yesterday” for pretty much everything, especially at fast-paced businesses. People want localization to happen quickly, but we live in an instant gratification society. Unfortunately, our desire for speed is often in conflict with other considerations. If you want translation quickly, machine translation is nearly always the fastest choice. But not all content lends itself to this path. In fact, most content in business settings doesn’t lend itself to pure (unedited) machine translation as the sole path. Often, machine translation is either a starting point in the process, whereafter humans clean it up (not always the best choice either), or used for only certain portions of the content that are lower risk.
Knowing what the actual timeframe is, and what the impact of not meeting that timeframe, is really important information for localization project managers to have available. Sometimes stakeholders think that by withholding this information or pushing for an earlier deadline, they’ll get a faster result. In reality, project managers are trying to balance many considerations. Often, flexibility where speed is concerned is critical. As an example, if your best localization agencies are fully booked, and there is no time to onboard new ones for a given content type, waiting a few days could mean that you’ll get high quality. If you rush but give the work to the wrong agency, your internal team members might not be happy with the quality and will have to waste a lot of their time cleaning it up later. As with many things, rushing too quickly can be costly later on. It’s better to “measure twice, cut once.”
4. How much of an investment do we want to make?
This is a question that people unfamiliar with localization often shrug their shoulders at, because stakeholders have no idea what to expect in terms of localization costs. Usually, people requesting localization don’t think about the true costs of creating the content in the original source language, so they don’t have any idea what a project should cost to deliver in 3, 5, or 10 languages. Very rarely do content creators stop to consider how many manual steps they have in their process that must be carried out by humans. More manual steps = higher localization costs!
Localization as the Early Warning Detection System for Scalability
For this reason, localization is actually a great place to test your company’s scalability. Usually, if the process isn’t scalable or automation-friendly, it won’t be localization-friendly either. That’s OK for areas of your business that are still maturing. But if there’s an area that your business actually needs to scale globally, localization tends to shine a lot of sunlight on the situation. This often leaves localization teams as the bearers of bad news. Teams don’t typically want to change without a strong business motive or mandate that ties directly to their own goals.
What happens when scalability is lacking is that you see this manifest in terms of inflated costs and delivery timelines that seem completely out of line with expectations. So, no matter how gently a localization team tries to point out a scalability blocker to a process or a way of working, if a team does not want to change, they will usually go down one of two paths: they will either argue that localization isn’t actually important enough for them to spend time on (and they might be right, especially if they haven’t clarified what the goal of localizing actually is), or they will point the finger at localization as the actual problem. Either of these is easier for teams than undertaking the much harder work of self-reflection and change.
Budgetary Discussions Often Reveal Opportunities to Improve Scalability
The reason I raise this phenomenon in the context of budget is that budgetary conversations are often what bring about this type of friction and consternation regarding localization to begin with. Stakeholders are often shocked by the costs of localization, because they lack experience with detailed budgetary management of the complexity and granularity that localization teams usually manage. It’s hard to fathom what it will cost to bring content into multiple languages if you are not aware of what it truly cost to create it in the first place. Also, the cost depends heavily on many technical aspects, as well as the complexity of the project. Generally, if you’re going to include multiple types of file formats, and you have your content in many systems, it’s likely to require some heavy human lift.
Bottom line: Don’t be surprised if the cost to bring your content into 10 languages is 10x the cost of creating it in the first place, especially if processes on the source content side are not yet mature. The reason it costs so much is often due to the way content is being created originally, in ways that are not yet scalable or flexible enough to meet the demands of a global business. Often, there are other, more creative solutions available to stakeholders than merely translating everything. But to achieve those solutions requires humility, willingness to embrace new approaches, and a high level of awareness that every market does not actually need (or want) the same thing.
5. What quality level is expected?
This is another important aspect of most projects, but one that I advise localization teams not to talk about too much unless they want to evoke yawns from their stakeholders. Stakeholders usually have a hard time understanding the concept of quality, but for monolinguals this is particularly difficult to understand. So, when forced to raise the issue, I try to use an accessible analogy to help stakeholders get a sense of why this topic matters.
Just because a person knows how to write doesn’t make them a professional writer. Similarly, speaking two languages does not make you a professional translator. There are degrees of “good writing” and there are degrees of “good translation.” We know good writing when we see it. We also know poorly written text when we see it. How “good” writing really is depends on the goal of the text, the audience, style preferences, and much more. Usually, this explanation is sufficient for most stakeholders to understand why you can’t just randomly select any person who calls themself a translator.
Quality is a hot topic in the localization field, and it’s one that people have varying opinions on. Some companies like to develop extremely detailed localization quality assurance (LQA) processes in order to try to track, measure, and “enforce” quality. There are a plethora of translation and localization ISO processes, standards, and a lot of other initiatives that I’m sure had their purpose at one time, and still do in some contexts such as highly regulated industries. But for many contexts today, and especially in digital companies that embrace things like agile development and continuous deployment, I find most of these “traditional” localization quality measurement efforts a bit outdated and not keeping up with the reality of how business happens in a fast-paced, digital environment.
I’m on the other side of the spectrum: increase your chances of quality by fixing it at the source. I don’t believe in leaning heavily into processes that, on a blanket basis, try to “correct” quality downstream. In a high-growth business setting, there simply isn’t time for that. Sure, QA and bug-fixing are important. But by and large, I believe in solving for quality at the earliest possible stage, which is when you’re selecting the humans who work on your projects to begin with. Like good writing, good translation comes down to the people who actually do the work. The closer you can align them to your brand voice and cultural values, the more likely they will be to produce fantastic translations that resonate with your target audience, right out of the gate.
Hire the right people to do translation work with a strong vetting process up-front, train them well on how to make good decisions for your brand, and trust them to do a good job, addressing issues only if they occur. This is a mindset change, but an important one. If you set up a quality process that looks for errors after the fact, by default you are saying you expect to find errors, and you don’t trust the people to do a good job to begin with. If you take the opposite approach, and only fix errors when they are raised, you’re sending a message that you have built a process that optimizes for quality much earlier on, so that errors are the exception, not the rule.
Focusing on hiring the right translators for your brand at the earliest possible stage saves a huge amount of time, versus implementing convoluted processes for quality control later that I believe are ultimately time-wasters, hard to roll out consistently, and worse yet, demotivating to the translators who actually do the work. I believe that approaching this topic from a position of trust and autonomy toward translators leads to self-accountability. That is what I want from a localization partner ultimately, not a vendor that your employees need to micro-manage and bean count translation as if it’s a commodity that is sold by the pound.
6. How much domain knowledge is required?
Back to the writing vs. translating analogy, would you hire merely “a person who can write in English” to write marketing copy for your company? Would you hire that person to draft your legal contracts? Or write your product documentation? Vendor selection is a huge part of localization project management. Picking the right translators means choosing ones that understand the topic at hand. Ideally, the translators know your industry, but also know the type of content in question too (marketing, legal, technical support, and so on).
In addition, it’s important to ask translators about the domain knowledge when it comes to your specific company and products too. If the translator happens to already be a user of your products or services, they are much more likely to do a good job with the content because they have a deeper level of understanding to begin with.
Technical Considerations: format, systems, connectivity, automation, Updating, Feedback Loop
The next six items that localization project managers need to consider when planning any localization project are what I would call the “nuts and bolts” of localization project management. That is to say, without answering these questions, a localization project manager cannot easily make the project happen. These questions are mostly straight-forward and much easier to answer than the business considerations usually are.
Even so, very often, stakeholders are surprised by the degree of detail that a project manager has to gather in order to properly scope a localization project. Sometimes, these details are not obvious, and not something people tend to think about as they go about their daily work. So, they can be startled when a localization project manager starts getting into the nitty-gritty details of work that even their own team doesn’t normally need to think about. Some teams might even find it intrusive or excessive if they aren’t familiar with localization.
7. What format(s) is the content in?
This matters because the process of creating the localized assets will often need to mirror the original creation process in the source language. As an example, if you just hand a project manager a bunch of PDF files and expect to get them back in 10 languages, you might be disappointed to learn that you’ll need to provide the files that were used to generate those PDF files, because the translation process typically requires access to those in order to extract the content.
8. In which systems is the content created, stored, and published?
A localization project manager needs to know the answer to each of these separate questions, because often these are three completely separate systems. In an ideal world, the content will live in a content management system (CMS) with existing APIs or connectors to a company’s translation management system (TMS). However, it really depends on what type of content it is, where it’s coming from, who is authoring it, and how it get published.
It’s fairly common for companies to have multiple systems for managing content, sometimes dozens or even hundreds at large organizations. Often, the translation management system (TMS) is one of the only places that is truly “central” companywide where all of this content gets stored, in multiple languages, along with the English equivalent.
9. Are the systems connected to each other?
As mentioned above, it’s ideal for the various systems to be integrated or at least connected in some form. This helps to maximize automation while minimizing human work. This scalability issue is a major focus for localization teams, because a human process that isn’t burdensome in just one language quickly becomes a major time investment or a blocker to speed, not to mention human costs, when you try to scale it into multiple languages.
Localization teams are notorious builders of internal tools and middleware to connect systems, because out-of-the-box integrations do not always exist for a company’s specific use case. It’s not uncommon for companies to develop their own translation management components internally, especially as their localization efforts grow in size and scope.
10. What pieces of the process can we automate?
You might be surprised to learn that automation is the best friend of most localization teams. Localization teams always think in terms of how scalable a process will be when multiplied across languages, so they routinely look for ways to automate. Examples of this might include:
- Automating the transfer of files between systems
- Automating the conversion of files from one format to another
- Automating the removal of untranslatable elements
- Automating the naming of files to a consistent naming convention to ensure further automation is possible
- Automating version control so file updates can be quickly detected
- Automating the publishing process
- Automating the link replacement process
- Automating the image replacement process
- Automating reporting
In general, localization teams will seek to automate as much as possible to minimize human work and make processes truly optimal at global scale.
11. How often is the content updated?
This too is extremely important, because it will determine not just how something gets localized initially, but how it gets localized in the long term. If content is updated often (as is, let’s be honest, most digital and web-based content that serves any important purpose), there needs to be a discussion of the frequency of updates.
The updating cadence matters hugely, because if content is worth investing in, it’s typically worth keeping updated too. This is where systems and connectivity can play a major role, and where localization teams seek to leverage the best in translation technology and tools, to make continuous updating possible.
12. What is the feedback loop with the source authors?
The earlier you can connect the localization team to your source content creators, the faster and better localization will happen. Often, teams don’t want localization to “slow them down” by giving them suggestions on how to create global-ready content. They view such advice as a blocker instead of an enabler. But the sooner in the process a source authoring team expresses openness to having a true feedback loop with the localization team, the faster progress will happen.
Generally, if there is no mechanism for the localization team to help improve the way content is created for global scale, that content will never be optimal in terms of structure to enable true scale through automation. Also, localization teams need access to source content creators in order to connect their systems and even have a full understanding of the source content to enable the best output possible. Often, source content owning teams can feel uncomfortable or territorial when localization team starts asking questions about their source content processes. They might question why the localization team doesn’t just act like an order-taker instead.
This goes back to the importance of viewing the localization team as a strategic partner instead of a vendor. True alignment — across systems, processes, and goals — takes time, energy and commitment from both teams. That isn’t always a priority for every team that needs support from localization. So, building these muscles can take a lot of time.
Think of your localization team not as the team that gets translations done. Think of them as strategic partners who support your company’s global scale. Translation is merely one piece of localization, but that usually isn’t the most difficult element of the equation to solve.
Localization Project Management plays a critical role as Companies Scale
In summary, the best localization project managers don’t just aim to get projects done. They want to do that, of course, but they want to ensure that the company’s time, energy, and budget are applied to the work that will have the biggest impacty. For that reason, they have a number of important factors to consider, both on the Business and Technical side, to solve for scale and company priorities. They aren’t order-takers, but rather, true partners who build relationships with stakeholders and other teams over time. Creating this kind of dynamic at any company isn’t easy. It takes time and patience. But it’s an important part of any strategic localization initiative.
