| Jamie |
Hello, listeners. My name is Jamie Gillette and I am your host for today’s episode. I’ve been in the localization industry for more than 14 years and I’m currently a program manager at RWS Moravia working with large enterprise customers to grow their business globally through localization. Today, I’m excited to speak with Mike Harris at Slack about his recent efforts in TMS migration. Welcome to Globally Speaking, Mike. |
| Mike |
Thanks, Jamie. It’s great to be here. |
| Jamie |
Can you tell our listeners a little bit about yourself, your role and how you entered the localization industry? |
| Mike |
Sure. So, I’d been in the localization industry for 10 years now. I started as a Project Manager and I from there started getting into engineering and the more technical aspects of localization. I spent a little time in consulting and over 10 years I tried to build up all my programming and automation skills. And, eventually, I got the opportunity to join the team at Slack and start working on their business process management tools. And it’s been great. It felt like it was the culmination of 10 years of really hard work and I’m super excited about all the work that we’ve been doing. |
| Jamie |
Well, we’re very excited to be working with you. We were talking about how Slack completed their migration to a new TMS. So, let’s set the context for our audience and begin with a very simple definition. What is a TMS and what is it used for? |
| Mike |
Yeah, so the TMS is the system that we use to manage all of the content that we’re translating. So, it houses the content in a multilingual format. So, we have everything paired, English and target language, and it hosts the tools like the translation memory, which is a database that allows us to leverage content that we’ve translated before. And a lot of times that also includes features like job management and terminology management, or working with your glossaries, and just lots of different features that help you run your projects and ensure good quality. We actually sort of decided to narrow the focus of our TMS a little bit when we did our migration. So, for me, I’ve said that within the system we have built our TMS as a parking lot. Our TMS is where our stakeholders can give us the content that needs to be translated. And then from there, we can pipe it out into other systems through integrations. So, I do think that in our system at Slack we’ve taken a little bit of a different approach to a TMS. |
| Jamie |
So let’s talk a little bit about that stakeholder piece that you just spoke about. Obviously, you work with a lot of stakeholders on your side and that was likely an important part of the decision-making process on your end when it came to selecting a TMS and working on the migration. How did you go about working with your stakeholders to find their requirements and make sure that you were providing a model that met their needs? |
| Mike |
We did it in Slack. So, when I joined, we didn’t have, like, a dedicated internationalization team at that moment. So, our stakeholders, they’re sending us work; they’re not really actively managing the work that they send us. So, all of the systems have kind of already been built. Everything is coming into our platform, but nobody is really directly managing it. So, when I joined, the first few months, all of my time was just spent mining information in Slack, going to the channels that these teams had used when the system was built and reading all of the history there, finding documents that had been shared and, you know, links to the different GitHub pages and everything like that. And with all that information, we were able to kind of reconstruct this very detailed picture of what the original intent of the system was and what the people who had built it, how they intended it to work. And then with that, we could extrapolate what the best situation was for all of the developers who are sending us work. And because all of that was in Slack, we didn’t have to have a lot of direct conversations with the stakeholders, particularly in development because, you know, we had their words all recorded. |
| Jamie |
That’s very interesting and also speaks to why Slack is such a great tool. You’re able to find the history and go back and look through past conversations. So, since you didn’t have to work with as many stakeholders directly because you were able to locate the information, you know, within Slack channels, who did need to be involved in making the decision and how did you manage working with those different people? |
| Mike |
So, we needed to convince our engineering organization to give us the resources to actually perform the migration. So, for that, we needed to obviously show that there was going to be some financial benefit—and also some time saved with the TMS. But for the most part, the decision was entirely ours. The rule we kind of tried to speak to was that we wanted to maintain the existing architecture as much as possible so that when we brought the new system on, the changes to the internationalization architecture would not be very significant. So, we evaluated tools to try and find one that would solve the issues that we were having with efficiency in the existing system without changing the underlying i18n architecture. And, because we did that, it was actually pretty easy to bring engineering on board. You know, we explained that really the only thing we need you to do is take this tool that has existed for all this time and, instead of pointing it at the old system, point it at the new system and we’ll take care of everything else. So, there was a lot of time spent in GitHub and a lot of time spent kind of going through code and looking at all of the little pieces of internationalization and just making sure that we could basically port it over one-to-one in the new system. But once we did that, everyone was on board. Everyone was happy with the choices that we made. |
| Jamie |
And what key features did you find that you were targeting as part of that process? |
| Mike |
So, we have, like, repository-based tools where the TMS is like a database of specific strings and, within the API and everything, you’re working at the string level and every string is a resource that you can access and manipulate through the API. You have this other class of tool—which is probably the older and more common one—which is where you have a TMS that is really heavily focused on document processing. So, rather than every string being its own piece of information, you ingest an entire document. And then that document is parsed. And when you’re working with the API and everything, you’re working largely at the document level and, like, if you want to get a string out of the system, you might need to export the entire document in its final format. So, we focused really heavily on the repository-based system, because that allowed us to ingest the files in a very straightforward way. We didn’t have to worry about things like, you know, if a file is updated mid-process, like, then what happens in the translation management system to get everything out? Like, we get the file, it creates the strings. If any strings already existed and are updated, then they get updated. We don’t have this concept of a project or a job or anything that we have to group everything into. We just have this one big database of strings that we work with. |
| Jamie |
What else was involved in the process of making your decision on the TMS? |
| Mike |
So, the other important things were really around cost. We had gotten into a difficult situation with previous tools because they had this volume-based pricing and we were getting into traps where, like, certain decisions required us to, you know, increase the amount of money that we were spending on the TMS itself. So, we really had to make sure that we found a tool that had very transparent pricing and that we weren’t going to have this issue where if we decided to add another language or something like that, we would then have to negotiate on the price of the tool itself. That was really, really important. The other one was just how easy is it for our own project managers to just come in, find something and make a change. You know, a lot of the time we’re not working in the tool as translators, you know, we’re checking things, we’re looking at the strings’ history and we are making small changes based on things that are being reported to us from within the company. And we need to be able to do this very, very quickly. So just ease of use and the responsiveness of the UI and things like that were the next really big consideration. |
| Jamie |
You’ve talked about, you know, the ease for the teams and the project managers, and earlier you also talked about one of the main focuses being the amount of time that could be saved. How much time have you found that you have saved or estimate saving based on the migration to the new TMS? |
| Mike |
So, across different teams, you know, it’s different project by project. I’d say that right now, for management of the main project, we’ve probably saved about eight hours a week, minimally. For management of our quality processes, we’ve, I believe they said that we’ve saved about four hours a week, for a single person. And, internally, we’ve been able to increase our turnaround times on translation from three to five days to 24 hours. And that’s really the biggest thing—is that now the amount of attention that is required from our developers to track the status of their translations is considerably less. And I think that amount of time is very difficult to quantify, but that’s definitely the biggest value it’s given to us, is just letting us say to our developers and our internal stakeholders, “You don’t even need to think about this. It’s going to be done in 24 hours.” Our vendor helped us out on that too. I should definitely give them credit. |
| Jamie |
That’s an impressive amount of time savings, even at a per-person level, and especially with the turnaround time. So, it definitely sounds like for Slack that there was a big value-add in changing your TMS. I’m sure that the process took quite some time. I believe at one point you mentioned to me that it was 14 months. Could you walk us through how much time you spent on each aspect of preparing for and then actually executing the migration over the course of those 14 months? |
| Mike |
Yeah, so the initial investigation and the migration plan and all that I would say took about three months. So, you know, digging through Slack, coming up with the documents, writing the technical specifications—all of that was done within three months. And it then just took us a really long time to be able to allocate resources to the project. So, if we had started as soon as the technical specification was done, you know, we would have been done with this probably in five solid months. That would be as long as it took us to get it done, but because, you know, we are part of the larger development organization, you know, this steals priority from DevOps efforts and, you know, there’s always other things that developers can be working on. We had to wait in line until it was our turn for the migration to get done. But that was actually really valuable to us because, in the interim, in that long period where we were waiting to get resources to actually do the migration, we did a huge amount of experimenting with the old system and started just kind of trying out new ways that we could work and that we could then bake into the new system. So, one example of this is that when we did linguistic queries back in the old days, we would simply forward those queries to developers. And that was a lot of time for the developers. In this period where we were waiting to get development resources, we decided to start trying to answer more of the queries ourselves by finding pull-request information and pulling screenshots out of pull requests so that we didn’t have to put queries back to developers and back to product owners within the product development organization. So, this actually worked really well. And we were able to decide then that we were going to make this a permanent feature of the new system. And we could do that with one very small change. And now we actually have strings linked directly to pull requests within the system. So, you can just click on the string, see the pull request and go straight to GitHub and pull out any screenshots or anything you need to answer a query. So, we were only able to figure that out and to do that because we had to wait so long. And I think that that period where we were just waiting for our resources to come in, so we can make the switch, was actually extremely valuable. And then kind of really grateful that we got slowed down that much because we really figured out a lot of things.
So, the architecture was the most important consideration. So, we kind of built the system from the outside, in a way, looking at what our people wanted to do and then finding the best ways to handle it, rather than trying to get everything into one system or be too prescriptive on how people work. So, because of that, when we finally launched the translation management system, we had so many peripheral pieces that had already been built up that we were just plugging the translation management system into. And this all comes back to, you know, like I was saying about experimentation and just kind of iterating things and trying them until you get to your ideal state. We did that over and over again on so many different things that, yeah, like when we got to the actual translation management system, it was almost just plug and play. So I guess I’d say that the most important thing would probably be to not overdesign your system—to let the needs of your team and your stakeholders really determine how each piece is going to look and then work with that to make the system fit into it. That’s why it went so smoothly is because we had just been iterating on so many pieces of the system for so long that once we turned on the TMS, we just knew what it was going to do and what all the risks were. |
| Jamie |
So, you mentioned plug and play. But I am curious to know if there was an out-of-the-box solution or, again, did you have to do some modifications to that TMS to make it fit your needs? |
| Mike |
We didn’t really have to modify the TMS. But what we did have to do is come up with a flexible integration strategy and we got really lucky there because at Slack, we had access to some tools that gave us really, really flexible integration options that we could deploy without direct development support. So, we are using workflow automation tools that allow us to build all of our workflows in visual editors and then run that code in the cloud, run it as APIs, consume events from our different systems and things like that. So, we had that system and what we did was we built custom connectors to integrate that system with each of the l10n pieces that were available. So, this system has a huge number of built-in integrations, but obviously localization not natively supported by the tool. The tool gave us the ability to write connectors off other APIs. So, we wrote a connector for the translation management system. We wrote a connector for our vendors’ system. We wrote connectors for the quality management systems that we were using and then, using that, these tools allowed us to just create these workflows that pulled and pushed information from all of those different systems. So, one really great example is just we have a notifications channel where all of the information from our vendor’s portal—all the notifications that we would usually be getting pushed in email—they’re coming into a Slack channel and mentioning the appropriate project owners. And the way that works is that within this integration layer, we just get a hook from the vendor system and that pushes that, then retrieves all the information from the system that’s needed and puts it in the channel. And everything that we’re doing is kind of working off that model. We have an event that comes from one system. We have this workflow that’s created in the visual editor that has been executed. And then that does things in other systems. The reason this was so powerful also was it was very, very easy to change. So, one thing isn’t working, we want to change the way the behavior is happening. All you have to do is go in here, drag a few boxes around—like move a couple of arrows—and then you’ve changed the behavior of the entire system. And you don’t have to go through developers and you don’t have to go through the whole code-planning process in order to make that change. So, that made iterating really easy. And it also made it easy for us to just say, “All right, this is how it’s going to work: These are the events that we’re getting from the system, and if we don’t like the way that that’s behaving, then we just have to change it in the integration.” And it’s not a question of really customizing the TMS itself. |
| Jamie |
Did the creation of those connectors and spending time writing the connectors allow you to have that ability to easily change the workflow? |
| Mike |
Yeah. So, what those connectors do is, within any of the systems we’re working on, they have an API and the API might access a certain resource, right? So, you have an API call that would get information about a specific project, or you have an API call that would get information about a specific file. What the connectors allowed us to do was formalize the way that that integration uses those API calls to talk to the other systems. And once we did that, then the little boxes I’m talking about just represent API calls that we have put into the connector. So, we might have a workflow where it says, “Okay, the job is done in the portal. Now get the information on the job, find out who the project manager is, and then direct message the project manager and tell them that their job is done.” The connector work allows us to pull all of the information from the vendor’s portal or from the TMS. So, yeah, it was pretty straightforward to write the connectors. It did take some time but, you know, it’s basically just a matter of writing steps, right? So, I create a step that says, “Get information from a job,” or I create a step that says, “Create a project,” and then we can use that step an infinite number of times, an infinite number of workloads. |
| Jamie |
You talked a little bit about the benefit for the engineers. You talked a little bit about the benefit for the project managers. You’ve also mentioned that you had a connector for the quality aspect and that it is saving time on the quality side. Can you speak to a little bit about what benefits the migration and change in the TMS has on the quality aspect of your localization model? |
| Mike |
Yeah. So, I already said a little bit about how we, you know, mine pull requests in GitHub for context when there are queries, so that’s the first really big one. The next one is around how we’re reviewing the projects. So, we wanted to implement a quality sampling with, like, an MQM, DQF-style review where errors are classified and everything and we found a really good tool for doing that, but it was another standalone tool. And, because of that, when we first started using it, there was a lot of time that was going into getting the files, uploading them to the tool, creating the jobs and everything like that. We actually were able to increase the amount that we were sampling by about 60 percent once we brought the new system online, and once we had all those integrations running. So, we can now work with content that’s living in several different places and just kind of play it where it lies. We didn’t want to create a situation where we were forcing our language service provider into a certain tool or into a system that they didn’t want to work with if we didn’t have to. And, I knew from, like, my experience working in LSP that when a client comes along and is like, “I have the system you’re going to put all your linguists into,” it’s not always great for the LSP side. So, we allow our LSP to work within their own translation management system, just with the agreement that they make all of the bilingual content available to us. And then we can pull that bilingual content through the integrations and use it to update both our TMS and the quality system at the same time. So, we have kind of eliminated a situation where we have to have people manually downloading and uploading files to create quality jobs. We’ve also eliminated the need to have overly complex workflows that can block feature deployment because things are still being reviewed in quality. All of these different steps can happen in the system that is most comfortable for the people that need to manage them. And they can happen asynchronously. They don’t need to affect each other. Quality review can move forward without blocking feature deployment. |
| Jamie |
With your solution of allowing an LSP to work in their own tooling, I think is a very beneficial and collaborative aspect for both the customer and the supplier. From my perspective, I definitely think it reduces, you know, a lot of risks, a lot of manual effort and a lot of problematic issues that may arise. |
| Mike |
Yeah. Yeah. |
| Jamie |
Now that you’ve been through a TMS migration, what recommendations would you give to other companies about how and when to implement a TMS? |
| Mike |
I think the first recommendation that I would give is to always make sure that you are including your language service providers’ capabilities in your evaluation. When we evaluated language service providers, the API capabilities were extremely important and that’s been really valuable to us as we’ve done this integration.
I think the next thing I’d say is to try and get away from the feature matrix. In my experience, if you put one of these spreadsheets together where you have every feature you want, you know, in the rows and you have a column for each system you evaluated, almost every system is probably going to be able to check all of the boxes that you’re going to want. So, I think it’s really important to, as I said before, think architecturally—think less about how to get everything out of one system and think about what it is you really, really want to accomplish. And then think about how that system is going to grow as you grow. And if you take those things into account and you come up with something where you’re making individual groups happy and you have flexibility for change in the future. I think that that’s the best situation that you can have. Changing out your TMS can be daunting. It is a lot of work and everybody’s situation is different. So, I wouldn’t imagine for a second that everything that I’ve done at Slack would apply to every single company. But I would say that there are sometimes TMSs—there can be a bit of a sunk cost fallacy. If you feel like you’re working for your system and your system isn’t working for you, then it’s always worth it to put in the work to try and build something better, I feel. |
| Jamie |
It sounds as if Slack’s migration to the new TMS was very successful from everything that you’ve said. Do you have any lessons learned that you wish you could have done something differently? |
| Mike |
Yeah, so far, so good. So, I think that one thing I really did not do a good job on in some ways was change management, because when we did the initial planning, I felt like we really had our stuff together. And we had a lot of documentation and we knew exactly where we were going, but as the migration drew closer, because we kind of became dependent on engineers and other things like that, it became a lot more difficult to figure out, like, what our timelines were. And I think that that change management is really valuable and I do wish that we could have done more of that. So if you’re able to, you know, create these documents that say, “What is the old system, what is the new system and what is changing?” and really socialize that with all your stakeholders and just take a little bit of time to make sure everyone’s on the same page—that’s really good. And that’s what I really would have liked to have done better, even though it was successful. |
| Jamie |
So, now that the migration is over, what is next for Slack? |
| Mike |
So, for our localization team, our next big efforts are going to be around more QA automation. So, we are going to be working on the way that we do screenshot reviews and the way that we integrate localization into automated testing within NQE. We are also going to be putting a lot of work into the business data aspect of localization by iterating on the way that we are collecting and aggregating our financial data and reporting on that. And I think we will probably also be spending a lot of time on internal reviews. Even in the new system, this is still extremely painful when we have to have a lot of different people reviewing something. We’ll be spending a lot of time on that in the next year. |
| Jamie |
Great. Thank you, Mike, for your time with us today, talking about your TMS migration. Really appreciate you joining us. |
| Mike |
Thank you. |
