Skip to main content

Globalization Engineering

One of the key decisions a company entering new localities has to make, is figuring out roles and responsibility for the new body of work that has to be performed to enter these new markets. Obviously the answer is very dependent on the product and the company, but we can try to identify typical engineering areas dedicated to globalization and common scenarios of how companies approach it.

But before we start, let's start with the right foot. It is fundamental that everybody understands globalization is everyone's responsibility. It can't be an afterthought that someone else takes care of. And it goes beyond engineering. An engineer can't fix bad requirements or bad designs that are not world-friendly.

Globalization Architecture​

Champions. Evangelization of best practices and shared libraries. Training. Auditing tools. International code reviews of new features and even designs. Overlap with international PM (requirements), design, and LPM (preventing l10n issues downstream).

Internationalization Engineering​

While globalization is everyone's responsibility, we don't want to repeat ourselves and reinvent the wheel having different teams solving the same problems multiple times and possibly in different inconsistent ways. The Internationalization Engineering role is usually tasked to

HT content production deployment and retrieval MT Regional formats (input/output/validation) and other local customs (measurements, temperature) -- usually not rocket science but want to have consistency (e.g. same patterns, separators, symbols, number of digits) IQA automation and IQM enabler (screenshots, internal tools, insights)

Localization Engineering​

traditionally acting like a magic black box processing any unstandardized input to feed to the vendor -- it no longer means that (now it's about establishing automated processing pipelines) traditionally MT experts (training, evaluation) translation pipeline (from source ingestion to translation distribution) TMS management CMS integration L10n tools

Content Engineering​

While this is strictly not a globalization concern, failure to proper design content authoring and management upstream can lead to very difficult or poor quality localization downstream. For example, the inability to adapt source content to different regional needs (because if product differences or legal reasons) may induce the use of transcreation processes which can be very limited, time-consuming and expensive.

International Features and Regional Development​

For products

Organization Scenario 1​

If a company is lean and their product requirements are mostly global, they may try to have a minimalistic or even non-existent globalization engineering team. For example:

  • Internationalization Engineering: this can be tackled by selecting the preferred solutions (e.g. open source libraries) and enforcing it through best practice documents and code reviews. Some organizations with "core platform" teams may absorb this role as well.
  • Localization Engineering: some localization vendors offer this as a service and it can be outsourced. Or it can be taken over by an infrastructure team responsible for similar functionality.
  • Internationalization Architecture: a few senior/lead engineers can be trained and they can perform their function along their current ones.
  • International Features and Regional Development: this can be performed by the core product teams as necessary.

Organization Scenario 2​

Company of a certain size and varied international requirements may want to beef up a specialized globalization team to the appropriate scale. For example:

  • Internationalization Engineering: this team can be tackled by selecting the preferred solutions (e.g. open source libraries) and enforcing it through best practice documents and code reviews.
  • Localization Engineering: some localization vendors offer this as a service and it can be outsourced.
  • Internationalization Architecture: a few senior/lead engineers can be trained and they can perform their function along their current ones.
  • International Features and Regional Development: this can be performed by the core product teams as necessary.

While these roles and teams could potentially live in different part of the organization based on some functional affinity, a strong argument can be made for keeping them under the same umbrella. There are a lot of synergies and interdependencies across the functions above to justify a single globalization team. Also having a single sponsor may facilitate ROI tracking. On the other hand, a separate globalization team may disenfranchise product developers and may end up operating like a cost center rather than international revenue generator (or enabler at a minimum).