Every localization team has a process. The question is whether it exists anywhere outside the heads of the two or three people who run it. In most companies I've worked with, the answer is no - things work because specific individuals know who to email, which folder to check, and what the unwritten rules are. That's fine until someone goes on vacation, changes roles, or leaves entirely. Then the process leaves with them.
This isn't a documentation problem in the sense of just writing things down. It starts earlier than that. Before you can document a process, you need to make sure the process itself actually makes sense - that it reflects how the team works today, accounts for the content types and release cadences you're actually dealing with, and doesn't have unnecessary steps that exist because "we've always done it this way." Design comes first, documentation follows.
A process nobody follows is worse than no process at all. It creates the illusion that things are under control.
I design localization workflows that map to your organization's reality. That means understanding not just the localization team's side, but how product, engineering, content, and marketing interact with localization - where the handoff points are, who needs to be involved at which stage, and what the escalation paths look like when things don't go as planned. The result is a process that people actually use, because it was designed around how they work rather than imposed on top of it.
The documentation itself is practical, not aspirational. Step-by-step workflows, decision trees for common scenarios, onboarding guides for new team members, and clear definitions of who owns what. Everything written so that someone joining the team next month can get up to speed without having to shadow a colleague for two weeks. I've seen too many process documents that read like strategy decks - impressive but useless when you need to know how to actually get something translated on a Friday afternoon.
Having built localization departments in-house, I know that the real test of a process is whether it survives the person who created it. That's the standard I work toward - a setup that's robust enough to handle team changes, product growth, and shifting priorities without falling apart. If the process depends on a single person's knowledge to function, it's not a process yet.