Choosing a TMS Is Not an IT vs Localization Decision

Sometimes, when I see things in the Localization industry that don’t make much sense to me, I try to bring them into more everyday situations. And when I do that, they suddenly feel even stranger.

Imagine, for example, a restaurant about to open, setting up its kitchen. The person managing the budget is the one choosing everything: the ovens, the fridges, the knives, the pans, the preparation tables, the dishwashers… the whole setup. Everything seems good on paper. The price is right, the suppliers are approved, and maintenance is under control. All good. Then the chef arrives, looks around the kitchen, and says: “Right… but this is not really what I need to cook.”

It would sound like a pretty strange way of setting up a restaurant. Right? Not asking the people who would use the equipment ….

Now replace the kitchen with a TMS...

Replace the kitchen with a TMS, the chef with the Localization team, and the person choosing the equipment with IT or a Tech team. And suddenly, the example doesn’t sound that strange anymore. In fact, it sounds surprisingly familiar. During my career, whether in companies I have worked for, consulting projects I have been involved in, or simply conversations over a few beers at Localization lunches and events, I have found myself more than once hearing Localization professionals say things like:

“Well, all this TMS, API, and integration stuff... that is something IT or the Tech teams handle. We don’t really have much say in those conversations. Nobody asked us, or maybe we gave some feedback, but at the end of the day, it was a corporate decision, and they chose the tool that fit better with the company’s requirements.”

I have also come across the opposite situation, although, to be fair, much less often. Localization teams with a lot more voice and decision-making power that have basically led the TMS selection themselves, only to discover later that the chosen platform struggled to fit into the wider technology ecosystem of the company.

Neither scenario is particularly good.

The first one is definitely more common: IT choosing a TMS more or less on Localization's behalf. But I have also seen the second one, where Localization drives the decision almost alone. And this is why this post is, once again, my argument for something I strongly believe in:

Together is better.

Silos don’t help. Waterfall approaches don’t help. And treating Localization as an afterthought certainly doesn’t help either.

So perhaps the real question is not who should choose the TMS, but rather who should do what when making that choice?

Own the problem, not the whole decisión

I believe the team that owns the business problem should lead the tool selection. But leading the process and making the decision alone are two very different things. A TMS is obviously technology, but it also defines a big part of how a Localization team works: how content comes in, how translation and review are managed, how vendors work with us, what we can automate, what data we can get, and how much manual work the team ends up doing.

That is why I find it difficult to imagine Localization not having a leading role. We know where the pain is because we live with it every day. We know which workflows are too complicated, where people are doing manual work, where content gets stuck, and where we lack visibility. So, in my view, Localization should be the business owner of the TMS selection.

But being the business owner doesn’t mean being the technical owner. This is where IT or Engineering becomes critical. There are plenty of questions I would definitely want them to answer in the room. How secure is the platform? How will SSO work? Are the APIs really as good as they look in the demo? How well will it integrate with the rest of the company ecosystem? What about data residency, compliance, maintenance, or scalability? You can choose an amazing TMS from a Localization perspective and still create a big headache if it doesn’t fit with the technology around it.

So I see IT as the technical owner or advisor.

So the way i see it, we have these 2 key questions. Localization asks: Does this solve our Localization problem? IT asks: Can this work properly inside our company? You need both answers to be yes. And that is why, in practice, I would involve more than just Localization and IT in the process. The key is to make sure each team is clear on what they are there to contribute.

I would probably split the responsibilities something like this:

View fullsize

Every company will organize this differently, of course, but the principle is the important part. There is a big difference between who buys the technology and who owns the problem the technology is supposed to solve. If IT chooses mainly through a technical lens, you can end up with something secure and scalable, but painful for the Localization operation. If Localization chooses alone, you can end up with a tool the team loves, but that is difficult to integrate or maintain. Neither is ideal.

Once the roles are clear, agree on the process

View fullsize

Click HERE to download the infographic

Right, so by now we have looked at ownership, who should bring what to the table, and why I believe the together is better mindset is the right one. Hopefully, I have been persuasive enough and, at this point, you are at least half-convinced! The next question is: how do you actually run the selection process? There are obviously different ways to do it, but there is one best practice I would definitely include: agree on a scorecard before you get too excited about vendor demos. Because demos are dangerous. Everything works in a demo. 🙂 The workflow looks perfect, the AI feature is impressive, the dashboard shows exactly what you wanted, and every integration seems to be one click away. Then reality arrives.

So rather than asking which tool people “liked”, I would agree up front on the criteria that really matter and how much weight each area should carry. Personally, I would probably give around 60–70% of the weight to Localization, workflow, and business capabilities, and the remaining 30–40% to technology, security, integrations, cost, and other enterprise requirements. The exact percentage is not really the point. The important thing is agreeing on what good looks like before somebody falls in love with a particular platform.

Then the discussion becomes much more useful. Not:

“I prefer TMS A.”

“IT prefers TMS B.”

“Procurement prefers TMS C because it is cheaper.”

But:

Which platform performs best against the requirements we agreed are important? That is a much better conversation.

Final thoughts

So, who should choose the TMS? For me, Localization should lead because it owns the business problem. IT should play a strong role because it can assess whether the solution will work properly within the broader technology ecosystem. And the decision should be made together.

My model would be: Localization defines the problem and the criteria → IT validates the technical solution → the decision is made together, with Localization accountable for the business outcome.

Which brings me back to the restaurant. I definitely want the chef involved in designing the kitchen. Actually, I want the chef leading a big part of that conversation. But I’m also quite happy for somebody else to check that the oven can actually be connected before we buy it.

Together is better.

@yolocalizo