Why Structure Matters More Than Tooling
Localization programs rarely fail because the technology was inadequate. They fail because nobody owned the terminology, reviewers were unavailable when needed, or the work was distributed across teams with no shared standard.
The symptoms are recognizable: terminology that varies between assets, review that happens when someone has time rather than on schedule, quality that depends on who handled a particular project, and a backlog that grows because the bottleneck was never identified.
These are organizational problems with organizational solutions, and they become more acute as volume rises. A program handling five assets a month can absorb structural weakness through individual effort. One handling a hundred cannot.
The Roles That Matter
Not every program needs every role as a separate person, but every program needs every function covered explicitly.
Program owner. Accountable for the whole pipeline — intake, prioritization, quality, and delivery. This role sets standards, resolves contested decisions, and owns the outcome. Distributing this across teams produces inconsistency and no clear accountability when something goes wrong. It is the single most important role to fill.
Terminology owner, per language. Decides contested term questions rather than leaving each reviewer to decide independently. This is a small time commitment and a large quality lever. Without it, terminology drifts as different reviewers apply different preferences.
Language reviewers. Native speakers who verify translation quality. These should be named individuals with agreed availability, not a pool to be found when needed. The most common cause of stalled programs is scrambling to find a reviewer, and that scramble repeats every cycle unless the arrangement is standing.
Subject matter reviewers. For technical, regulated, medical, legal, or specialized content, someone who knows the domain in the target language. This is distinct from linguistic review and cannot be substituted by it.
Coordinator. Handles submission, tracking, record keeping, and publication. At low volume this is absorbed into another role; above roughly fifty assets per cycle it becomes a distinct workload, and treating it as spare capacity is how cycle time inflates.
Production support. On-screen text, graphics, and any re-recording. This is design and video production work rather than language work, and programs consistently underestimate it.
Technical owner. Pipeline configuration, integrations, automated checks, and troubleshooting. Part-time in most programs, essential in all of them.
Reviewer Networks
Reviewers are the binding constraint in almost every program, and how they are sourced determines what is achievable.
Internal employees who are native speakers are the most common source. They know the product and the domain, which is valuable. The difficulties are that review is not their job, their managers have not agreed to the time, and their availability fluctuates with their actual responsibilities.
Making this work requires explicit agreement with their manager that review time is part of their workload, a realistic estimate of hours per cycle, and recognition that this is real work rather than a favour.
Contracted freelance reviewers are more reliable in availability and can be selected for domain knowledge. They cost money and need onboarding into your terminology and context, which is an investment worth protecting by retaining the same people rather than rotating.
Vendor-supplied review bundles review into the translation service. This is convenient and removes the sourcing problem, at the cost of less control over who reviews and less accumulated context about your content.
Community reviewers work in some contexts — open source projects, community-driven content, nonprofit work — and bring genuine knowledge. They are less predictable and raise fairness questions where the organization is commercial.
Whatever the source, the practices that improve output are the same: structured briefs rather than open-ended requests, a shared glossary so reviewers are not re-deciding settled questions, severity ratings so feedback can be triaged, and continuity so that context accumulates.
In-House Versus Vendor
The build-or-buy decision is usually not all-or-nothing, and the useful framing is which stages to run internally.
Keep internal: terminology ownership, prioritization, quality standards, and final approval. These encode judgment about your content and audience that a vendor cannot supply and should not own.
Consider vendor: processing capacity, review sourcing for languages where you lack internal speakers, specialized capabilities such as certified translation, and surge capacity for volume spikes.
Depends on scale: coordination, production work, and technical pipeline management. At low volume these are cheaper to buy; at high volume they are cheaper to build and benefit from institutional knowledge.
Signals that favour building internally: high ongoing volume, specialized domain requiring accumulated context, sensitive content with handling restrictions, and tight coupling to a product that changes frequently.
Signals that favour vendors: irregular volume, many languages with no internal coverage, requirements for certification or credentials, and limited internal appetite for the coordination overhead.
Most mature programs run a hybrid: internal ownership and standards, internal review where speakers exist, vendor capacity for processing and for languages without internal coverage.
How Staffing Changes With Volume
The shape of the team changes at recognizable thresholds.
Low volume — a handful of assets per month, one or two languages. One person can own the whole pipeline part-time, with reviewers recruited from within the organization. Tooling is used directly rather than integrated. The main risk is that the program depends entirely on one person's availability and knowledge.
Moderate volume — dozens of assets per month, several languages. Coordination becomes a real workload. Terminology needs formal ownership rather than being held in one person's head. Reviewers need standing arrangements. Automated checks start paying for themselves. This is the threshold where informal process breaks and explicit process is needed.
High volume — hundreds of assets, many languages. Coordination should be automated rather than staffed. Review moves to sampling with automated gates. Terminology and memory become maintained systems rather than documents. Production work needs dedicated capacity. Language-specific ownership becomes necessary because one person cannot hold context across many languages.
The transitions are where programs struggle. A process that worked at low volume degrades at moderate volume, and the degradation is usually attributed to quality problems rather than to structural inadequacy.
Common Structural Failures
No terminology owner. The most common and most damaging. Terminology decisions get made repeatedly and inconsistently, and the inconsistency is permanent unless content is reprocessed.
Review as a favour. Reviewers whose managers have not agreed to the time will deprioritize it under pressure, and the program stalls at exactly the moments when it matters.
Coordination unassigned. File handling and tracking absorbed into someone's spare capacity, which means it happens late and inconsistently.
Production work unbudgeted. On-screen text and graphics discovered as a requirement after translation is complete, with no capacity allocated.
Distributed ownership. Multiple teams each localizing their own content with their own terminology and standards, producing a library that is internally inconsistent.
No escalation path. Contested decisions — a terminology question, a register disagreement, whether an asset meets standard — with no one authorized to resolve them, leaving assets stuck.
Reviewer rotation. New reviewers each cycle, each of whom disagrees with established decisions, producing churn rather than improvement.
Making It Sustainable
Document the decisions, not just the process. Why a term was chosen matters more than that it was, because it lets a future reviewer evaluate rather than re-litigate.
Keep reviewers continuous. Accumulated context is the main asset a reviewer builds, and rotating them discards it.
Automate the mechanical work before it becomes a staffing question. Coordination, checks, and record keeping absorb effort that scales linearly with volume and should not.
Measure the bottleneck, not the throughput. Cycle time reveals where work waits, which is almost always review. Adding processing capacity when review is the constraint changes nothing.
Give the program owner authority to hold an asset. A quality standard without the authority to enforce it is a suggestion, and it will be waived under deadline pressure.
Plan for absence. A program dependent on one reviewer per language stops when that person is unavailable. A named backup, even a less experienced one, prevents this.
Starting Small
A first program does not need a full structure, and building one prematurely wastes effort.
Start with one owner who covers most functions, one or two languages, and named reviewers with agreed availability. Establish the terminology base and the review brief. Run a batch, measure where time actually goes, and add structure at the points that hurt.
The functions to formalize first, in order: terminology ownership, standing reviewer arrangements, and automated mechanical checks. These three address the failures that most reliably stall programs.
Expand the structure when volume forces it rather than in anticipation. Most programs that fail do so from under-structuring at moderate volume rather than from over-structuring early, but building a large structure before there is work for it is its own failure mode.
The programs that sustain themselves over years are not distinguished by headcount. They are distinguished by having named someone accountable for terminology, secured reviewer time as a commitment rather than a favour, and automated the coordination work before it consumed a person.
Working Across Time Zones
Distributed reviewer networks introduce coordination costs that co-located teams do not face, and planning for them prevents most of the friction.
Review turnaround extends when the reviewer is many hours offset from the coordinator. A question raised at the end of one working day is answered at the end of the next, and a two-round clarification takes three days rather than three hours.
The practical mitigations: give reviewers complete briefs so that clarification rounds are rarely needed, batch questions rather than sending them individually, and set expectations on turnaround that account for the offset rather than assuming same-day response.
Where a language has reviewers in several time zones, staggering assignments can shorten overall cycle time, though it complicates continuity.
Documentation matters more in distributed teams than in co-located ones. Decisions that would be transmitted by conversation in an office have to be written down, and the terminology base and decision log become the primary coordination mechanism rather than a supplement to it.
Handoff points deserve explicit definition. Ambiguity about who does what next is absorbed easily in a room and stalls work across time zones.
Onboarding and Continuity
Reviewer and coordinator turnover is inevitable, and how a program handles it determines whether knowledge accumulates or resets.
New reviewers should receive the terminology base, the register decisions, the review brief with severity definitions, and a set of previously approved assets as reference. Without these, they apply their own standard, and the resulting churn looks like a quality problem.
Explaining why contested decisions were made matters as much as stating them. A reviewer who understands the reasoning can apply it to new cases; one who has only the conclusion will relitigate it.
A calibration exercise — reviewing an asset that has already been reviewed, then comparing findings — surfaces standard divergence immediately and is worth the hour it takes.
For coordinators, the pipeline configuration, the record-keeping conventions, and the escalation path are the critical handover items. Programs where this knowledge lives in one person's head lose weeks when that person leaves.
Keep a written decision log. It is the artifact that makes a program survivable across staff changes, and it costs almost nothing to maintain while the decisions are being made.
Budgeting for People
A localization budget that covers only processing understates the real cost by a wide margin, and the gap is almost entirely people.
Review is the largest human cost in most programs. A planning figure of two to three hours per thirty minutes of content per language works for general material, rising for technical or regulated content. Multiply by languages and by volume, and cost it at the loaded rate of whoever performs it — whether or not it appears as a budget line.
Coordination scales with asset count rather than with duration, which means a program handling many short assets carries more coordination burden than one handling fewer long ones at the same total minutes.
Production work — graphics, on-screen text, screen re-recording — is design and video labour, and for visually dense content it frequently exceeds the language work.
Terminology ownership is a small ongoing commitment per language, easy to omit from a budget and consequential to omit from a plan.
Maintenance is recurring rather than one-off, and it compounds as the library grows. A program in its third year spends materially more on keeping existing content current than one in its first.
Presenting the full figure at the outset is better than discovering it incrementally. Programs that budget only for processing tend to stall when the review and production costs surface, and stalling partway through a catalog is the most expensive outcome available.
