This is an interview transcript; if you want to listen to the full version that includes a Q&A session from the audience, watch this video.
Background
Companies and organizations of all sizes face a common challenge: communication and localization teams are not always heard by development teams. This occurs during various stages of product development, including design, deployment, maintenance, support, and marketing. Localization teams often face the pressure of producing products quickly and under strict timelines and requirements, making it a significant challenge for them.
So, how can we address this challenge? There is no simple solution, but learning from those who handle it on a large scale is a promising approach.
In this webinar, we are delighted to have Loy Searle, the Senior Director of Localization and Globalization at Workday, as our guest. Workday is a provider of cloud-based software specializing in financial management, enterprise resource planning (ERP), and human capital management (HCM). The company’s solutions help organizations manage employee data, including profiles, time off requests, and performance reviews, and offer a mobile app for employees to access HR data on the go.
Can you tell us about your team and its mission at Workday?
Loy: So what my team is really responsible for is localization and globalization at Workday. And what we do is we support the global company in their journey to grow their revenue, sell products, and support our global customers. So, I see us as very much a support engine for our global growth. That’s really what our focus is.
When I started about three years ago, we were very well established in the way that we worked at the time, with our existing platform being part of our core product and a little bit of marketing support. And what we’ve been doing since then is really building out a center of excellence. So we’ve been building out a center of excellence which means the volume of work that we’ve taken on, the number of stakeholders that we work with, the number of product teams we engage with—it’s all kind of been on steroids for the last few years because we’re on a mission to really grow globally. So, my team, I would say, is one of the strong supporters of our global growth and development.
What are some of the successes you have achieved with your team that you are really proud of? What contributed to the success?
Loy: I would say the first successes that I think we built early on were establishing tiering. We did not have language tiers when I started. And getting funding to catch up with our primary Tier-1 markets. So at this point in time, we are completely caught up with all of our Tier-1 products. So we’re actually waiting on some of them, which is a really lovely position to be in to not have that kind of a backlog behind you.
We still have a lot to do. We have Tier-2 and Tier-3 markets that we’re working on, and we also have a lot of content that we’re still working on, and just a handful of outlier products that are still getting themselves internationalized and getting their strings into resource bundles so that they can work with us. But we really worked through, I would say, a pretty huge backlog of product engagement, especially to get caught up, and that was an all-out team effort across the board. There’s maybe one other area that I’m particularly proud of; when we started, we did not have an internationalization practice. We didn’t have standards, we didn’t have the training, and we didn’t have any place you could go to find out what you should do to properly internationalize the product.
And we have a gentleman that runs this program for us who is deeply passionate about i18n, and he’s trained well over 1000 people at this point in time on the engineering side. We’re part of all new hire training for new engineers. So, when you come in, and you start, you get that internationalization training from him. We also are training designers and have trained writers on developing writing for a global audience and designing for a global audience. But I have to say that probably one of the coolest things we’ve done is really establish an internationalization practice. And then underneath that, we are big fans of Globalyzer, and we rolled out Globalyzer this last year, and we’re in the process of pretty much getting that into every one of our product teams’ way of working. So I would say internationalization from scratch and being where we are today feels pretty good.
How do you get dev teams to pay attention to internationalizing their code? How do you reach/encourage them?
Loy: This is the part of our job where we push a rope all day long, right? This is always effortful, and I would say to get engineering teams to be mindful and pay attention to what we know they should do. What we have done—there are a few things we’ve done that I think have worked really well for us. First of all, we’ve started with the teams—like we hooked up Globalyzer initially and started our internationalization training, and we have a Slack channel for questions and things like that. So it’s kind of we’re building a little bit of a community there.
But we started the work with the product teams that wanted to go global. The product teams that wanted to work with us needed their products translated. And we just basically put this right in front of them and said, “To do that, you have to do these things first.”
And so, every new product team came through the door with this expectation: These are the things you have to do. This is how far along the journey you must get in order to work with us so that we will translate your products and engage with your repositories and pick up your strings and drop them back when we’re done, and test the products and all of that goodness.
So starting with the teams that were hungry and really wanted to work with us was a great place to begin because we build kind of, I would say, energy and a shared passion and interest in doing the right thing with those groups. And we really built our communication mechanisms with them as well, so the Slack channels—they became kind of an extension of us and how they shared with other engineering teams what they were doing. So if someone was first and then they knew another team was coming, they’re like, “Yeah, this is the Slack channel. This is the team. Go talk to them.” So that helped us get going.
I have to say I think our hardest part is really to come because we’ve spent the last 2+ years bringing on all of the new product areas. That was a lot of repositories, a lot of different product areas, and bespoke standalone acquisition products. And now we’re starting to look at what I would consider to be our core product. The product that’s been mature and it’s been out there for years. And that is a little bit of a different journey because those are the teams that feel like their work was done years ago. But they don’t know. They don’t know what they haven’t done properly or what’s still missing.
So we’re starting to pull all of their repository information together and what we’ve done initially for this core work that’s years old and not just brand new. So these are the teams that think they’re already there. We’d started working super closely with the Q&A organization. So we’re working with them on their testing protocols and our testing approach, so they can help catch these things as they are testing and work through that with their development teams.
And then my job really begins working across the leadership, across the engineering teams when we hit walls, and we have barriers from there. But the products are not in bad shape. For a product that never had that i18n testing integrated within it. But we still have work to do, and it’s always harder with mature teams. Much easier with new teams. If those guys are lazy and let them impress everybody else and then use them to shame their peers, encourage them to join you as well.
Do you only use Globalyzer with new products?
Loy: No. We’re using Globalyzer now. We’ve pretty much done an analysis that I think we’ll be done within the next quarter or so that will include all of our repositories. And it’s taken a lot of time for us to get across all of the repositories. But we’re pretty close to that. And so we work with Globalyzer and the dashboards for both the engineering teams, especially for the engineering teams that are first engaging with us, and there’s a lot of work for money to kind of prioritize the issues that need to be solved first. And then we’re also using it for our engagement with our QA teams as well. So it’s both. The dashboards are out there for both teams, and we’re partnering heavily with QA for mature products. We’re partnering heavily with engineering for less mature newer products. So it has a lot to do, I’d say, with the life cycle of the product itself.
How do you know how to plan your global release dates? Methodology/Phases?
Loy: I would break this into a couple of parts;
- For our existing products and the mature deliverables that we have: They have established release cycles, and it’s our job to really support them. We pretty much have automated our drops and our pickups from the product team directly to their repos, and we adjust to their schedule. So that’s how we work in a normal manner with mature products, where we’re caught up, and we’re already translating what they do, and we’re already engaged with those teams. That’s the easy thing. And we have lots of different release cycles, from weekly to every couple of weeks to quarterly. So, the release cycles can really vary wildly across the different product areas.
- The new products: Every new product is a new story. So for us, the new products are usually the big ones. The ones that require the most effort are typically the acquisitions. These are products that we acquired, and they may have been in various stages of going-global-to-have-never-started-going-global. So we’ve kind of seen this spectrum. And if they’re starting from scratch—the new products—we’ll work with them on prioritizing the customer-facing UI. So customer-facing UI and externalizing the work that they do into resource bundles, and then working through the i18n list of things they need to fix as we go. And then, as they progress, then we’re typically testing along with them. And identifying the things that surprised us. And there’s always at least one or two things that’s like, “Oh, I never thought about that. None of us ever thought about that.” And then you see it in the product, and we realize, “Okay, we have to go fix something; refactor that we didn’t plan.” But that’s normal. That’s what you expect with the new product.
So I would say we typically break down the release process based upon the work and the internationalization, and the conversion into resource bundles is the first step. Those are the first things the product teams have to do, and we work closely with them because they do this work. We hold their hands. We give them the tools. We answer their questions. We support them in that process, but this is their work to do, typically. And so our schedules are collaborative with theirs, and then as they get further along, then we will start typically adding on the language deliverables. And once we get through all of the language deliverables in the product, then the next phase is typically content. So then we’ll be following how poor user documentation or whatever those deliverables are from a product standpoint.
Meanwhile, at the same time, we’re usually working with the marketing teams; we’re getting marketing collateral done and getting all of that information done as well. So, typically the work takes place across a few different work streams. And the biggest dependency is how quickly the engineering team that we work with can get everything internationalized, and then do resource bundles, and then be part of our standard process. Once they’re in that process, then we pick up and drop off on their schedule. So then they just kind of become one of our regular deliverables, and we’re off to the races.
The multiple work streams are very interesting, and of course, getting the resource bundles done so localization can start. And all these other work streams starting to make sense. After they’re done with the resource bundles, I assume there is still a lot more internationalization they need to do that is not related to the resource bundles. So I assume that becomes yet another work stream for them in parallel to all the other works?
Loy: And typically, they’re doing this work in parallel because they’re in their making, working on the resource bundles. So, we typically try to organize the work so they can fix most of the i18n issues while they’re in there. And, so far, that has worked really well. That we’ve not separated them out; you do these things, and then these things. Because I think that it’s easy once they get their translations—that’s the instant gratification part of the work, right?
Once they get back to liking it, they do not care as much about the remaining work. So we really hook them together like you need to be doing both of these things together, and then when we start testing, we will turn up the things that might have fallen between the lines, or we didn’t anticipate in unique ways that your product works or something like that. So, yeah, we intentionally kind of bundle those together. It’s sort of like they get their medicine while they get their dessert, they get all together, and they don’t, they don’t then procrastinate as much as I think it could.
How do you ensure that every developer has the necessary know-how?
Loy: I would say that the informal Slack channels that we have are super useful. Like we have channels for people that are just ramping up and just starting to internationalize. They are very specific about their products. But we also have Slack channels for certain types of developers working on certain types of common things that may be wrapped in the front end. And then we have Slack channels that are much more focused on strange and unusual and gnarly questions that they might get.
So I would definitely say that Slack has been a really lovely support and augmentation for the training and for Globalyzer and that it creates kind of a continuous community and messaging place to answer questions, and it provides a place where people can, you know, we give them all the information when they’re starting out. We point them to lots of information. We have engagement meetings. We ramp them up. But this is just something a little stream of consciousness that helps support them as they go. That has been actually super useful with all of the other tools that we have. And there is no—there is a perfect developer, and there is no perfect team. So, you think you’ve explained that, and still, you will see an issue bubble up. So every team has a bit of their own loaning cycle.
What do you do to bring the L10N Managers, Development teams, and even QA teams together?
Loy: In some cases, they will be on those channels as well. It kind of just depends upon the life cycle of the product where they’re at in their process. The main thing that we have—we have a program that was in place when I started, but I have to say it has been a great program for us—which is a process that the company has for, that basically encourages new product development, new large feature development to go through this process. And this process basically includes all kinds of teams, including ours and accessibility and other teams as well. That when a product team really changes, they’re offering, or they’re platforming, they have to reach out and engage and go through the process and make certain that they’ve done all the right things for their product.
So that has been a super useful thing for our group. We catch big products and big rework, and we vision that we might not have caught otherwise.
The other thing that we do within our team is we actually do engagement readings. So, when we have a new product area that is starting to work with us, we typically organize an engagement meeting with them; that includes all the right folks and my team, from PMO to language services, to the engineering team, and the globalization team that’s focused on features that might be within our product itself.
We pull all of our folks together in these meetings, but then we also pull all the right people together on the product side. So we get product management, the lead engineers, QA, and sometimes writers. So we will basically get the core group of folk that will be working with us involved early on. And we walk everyone through what the process is.
This is who you’re going to work with during these phases. These are the things we do first. This is how we engage. And so, that typically gets everybody on the right page and then makes certain that we share all the right things early on from there. And then the meetings tend to go into more one-on-one smaller group meetings, specific tasks with engineers, and the slack channel tends to really kick in with these occasional meetings from there until we get further along and start looking at launch dates and things like that.
We also have a completely separate process that is run through our M&A Organization for mergers and acquisitions.
That is how we onboard new acquisitions to all of our processes, and localizations are one of the key players and globalization—both sides of you are our key players in this process. So it’s worked out really well for us because we’re part of their milestones and the things they need to do to get fully integrated and as part of the acquisition.
When I started, we were not part of their process. And it’s really, really hard to get their attention when they’re so busy doing the right things. So, if you’re not in the M&A process and you have one, get in that process and try to get a front-row seat, if you can, so that the work that the acquisitions do prepares them to be globally enabled and globally sold quickly. And I think almost every acquisition we do now is the expectation that’s going to be a global product. So, once we got into the rhythm of that process, it’s been super easy for some of these acquisitions.
Do you conduct an internationalization assessment at the initial stages to establish how big of an effort there is?
Loy: We do. And this is really how we use Globalyzer for this purpose. So, typically what we will do early on with an acquisition is get our hands on their source code and do a good analysis and then get with them on our findings, with the recognition that what we see through Globalyzer as their i18n effort and then what is typical for them to convert their strings into resource bundles.
Many teams have an additional layer of work on top of that that goes outside-above-and-beyond that work in order to make their products work properly globally. So, if they’ve got AI capabilities within their product and they’re English-focused, they have to think about that for language-focused AI. How would that differ, what’s triggering the actions of that kind of thing.
So, typically, when they look at the list that we give them from Globalyzer, most of them breathe a sigh of relief like, “Oh, that’s not as bad as I thought it was going to be. Oh, that’s not going to be as hard as I thought.” And then they come back a few months late; “So, what we’re really working on narrowly is this thing over here.”
But it’s all part of the process, and we typically, as part of that engagement process, we ask them to demo their product, and show us your product. So we get a feel for how densely packed their screens are. How does the product itself work? What are the global opportunities within the product?
If you don’t look at the product a lot of times, you almost really miss obvious things for, and so that simple walkthrough of the product is a super useful thing for all the groups that are working with them. You say, “Hey, you know, while you’re doing this, you might want to refactor how much you got on that UI screen.” Because the minute that goes into Germany, it’ll be a hot mess, and no one can read things like that, or that that you wouldn’t know if you hadn’t seen the product itself.
What other types of software initiatives does your team get involved in?
Loy: So, we have a couple of other ones that have been kind of interesting. I would say one of the things that we work on is collaboration with our machine learning teams. In some cases, we will actually do sample utterances as well as what the machine learning might deliver to the end users. So we can get very involved in those kinds of projects, which Are different. It’s not a pure translation-type project. It’s almost more like SEO, where there’s one too-many or many-to-one.
The other thing that we’ve started doing, which is kind of interesting these days, is partnering more closely with accessibility. And, in fact, we actually—the accessibility team and our team have an okay artists quarter to get many of the accessibility validation checks into Globalyzer.
Because they have the same issues that we typically have in localization, and that they want engineering teams to do all the right stuff they’re supposed to do.
And everyone nods and smiles and says, “Yeah, sure, we’ll do that.” But the accountability about whether or not they’ve actually done it needs to be told; it needs to be checked. There needs to be some validation for that. So they’re going to be joining our platform for Globalyzer. That will be a fun accomplishment, I think, by the end of this quarter.
That’s awesome. In a way, wouldn’t you say that making your product accessible via languages to different parts of the world is a kind of accessibility? I mean, there’s a lot more to accessibility than that, but I think it makes sense that your team would be driving accessibility as well.
Loy: Well, we’re partners. We are not driving it; we’re partners. But what I do hear about is a lot more synergy in this space where globalization and accessibility are connecting a lot more. In fact, a lot of our processes are very similar. The ways that we work with our product teams have a lot of similarities. They, you know, our challenges are compatible. They have the fabulous wedge of compliance that we usually don’t have as much except for in some markets. But we usually, you know, typically the localization, globalization teams may have a lot more touring and place and or may have more resources To collaborate across the tunes. So, it’s a nice partnership.
Is your development Agile? How do you protect against creating additional i18n debt?
Loy: We kind of have a blend, I would say. Because we have our core platform deliverable as more on a quarterly release cycle. But all of our new acquisitions and bespoke products and much of our front-end UI are on a much more agile process. So, we truly are, I would say, a blend In terms of different beliefs, cadence’s and even some different beliefs and methodologies opening upon the products.
One thing I would say about the additional tech debt and this is just, I would say probably everyone has experiences that have ever had a partner to and they tried to get them to do all of the things they need to do, but it’s a struggle because it’s not yet on their plan. We do have some product areas that don’t move as fast. So like, we’re not moving as fast and right to left and by day as I would really like. We’re there in some cases, and we’re barely there in other cases, and we’re still trying to crack the nut in some cases.
And one of the things that we’ve done as a strategy that might be useful to others is when you have a product team and they don’t have your work on their radar, and it’s not only on their roadmap for the next year, your class and you know it’s not going to be there, and they know it’s not going to be there. Well, what we’ve tried to do with those teams as rather than kick it down the road even further, is I really work with them to try to get at a leadership level and alignment to at least not keep adding to the tech debt. So we typically will train their people. We typically will get them hooked into Globalyzer so they know what their issues are that need to be resolved. And we work with them to try to, as they go forward, fix as they work. So that they’re not they’re not incurring the big debt. They’re not incurring that big tech dept that they don’t really want to face right now. But what they are doing is, as they work, they take away a little bit of it.
And so the goal is to take the debt that’s this big—and by the time it’s on their road map two years from now, instead of it growing this big because they’re not doing anything, the goal is to kind of shrink it down so it’s a little bit more manageable. And then maybe by the time they start working on it starts to look like a manageable process and project that they could take on. And that really requires leadership alignment and also giving them the tools so that they can start where they are and just not make it worse and make it a little bit better. And I do think that’s a good strategy for the stubborn teams that just keep procrastinating the work. It’s better than not doing anything, and eventually, it will lead to the right outcomes.
