Translation triangle redefined: the unlikely solution for Continuous Localization

Max Morkovkin 00:06
Semir has been working in infra beep for the last five years. And his main focus in in for beep is improving the continuous localization process. As many of you may know, info BP is a global communications platform for businesses and developers. And I think you had kind of a challenge, right? So you decided to redefine the way how you collaborate with vendors, both LSPs and freelancers. And in your presentation, you will tell us more how you managed to improve it and build like real continuous localization process. Right.

Semir Mehadzic 00:46
Exactly, exactly. You explained it. Perfectly.

Max Morkovkin 00:49
Good. Good. So we will be having questions after the presentation, and there will be a book as a gift. So guys, ask your questions in chat, vote for questions. We will get back to them after some means presentation. You're welcome Smith.

Semir Mehadzic 01:05
Okay. Thank you, Max. Hi, everybody, again, hope you hear me. I was a bit sick the last few days now fine, but our apologize for the nasal quality of my voice. At least more than usual. Anyway, without any further ado, let me tell you about the story we had I spoke a year ago here as market conference lot from home. And we did quite a lot in the last year. So let me tell you how there were intended conclusively found, we actually had to change the setup, because to accommodate the needs of continuous localization. But the true and I'll tell you why and why it actually matters to listen, this presentation should be useful for the business, businesses, companies acquired companies like ours, but also DSPS and freelance translators. So let's dive in. So here are just a quick agenda, we'll talk about how LSPs slash transportation companies are a bottleneck actually, for software clients. I would say that, yes, they are the bottleneck. And more on that later. So we also mentioned how agile applies to localization too. For those of you not familiar with agile, I'm trying to break at 22. And it applies more than one would you would think, the chain, the transition chain should consequently be reshuffled. And we did a low risk actually high gain experiment, I'm going to tell you more details about it. And I'm going to share some lessons learned, which can be summed up to the human triangle, like three components, or human archy. For localization, the technology is there to facilitate so indispensable but only to facilitate in our experience. So this is the summary of the whole presentation. But I really do invite you to stay for the next 30 minutes, it should be some fresh food for thought. So for all of you who disagreed to the first sentence where I said the data speeds are a bottleneck to the software, translation software development process, here are a couple of possibilities that you get if you change how our speed is positioned within the within the continuous localization process. I'm not saying left out because it's not like out and most probably shouldn't be. But it should be repositioned. So if if we imagine a scenario where LFP reposition, I will tell you what that means, you could get these benefits. So for business businesses, product releases will never wait. So when they are ready from the code and marketing perspective, they can be released no need to wait for translation, which I'll say there's this setup would mean that they get paid better, quickly and in full. No no deduction from the banks and all and the accompanying fees for LSP is here. This will also mean a change and a positive change in in disrespect, no deadlines and no administrative work actually. So these delays doesn't end. Here we have another set of items again for businesses, language errors in true contents localization can actually be fixed instantly, if you set the process to be truly continuous. Later on exactly be to the source line, usually English or the translations they can be fixed with the proper setup within 10 minutes. For translators, this localization without an LSP in between could allow them to have the clear meaning to every segment. For those that they need, they can easily ask for their for this. And for instance, again, this Resharper model will actually mean a steady monthly income for them, guaranteed. Think about it as a retainer, but if there's more work, of course the income rate right so this what I just said is not just a vision It's actually a real project that has these outcomes. You remember the experiment we did, it lasted for three months, it's been concluded right about these days. So these are the outcomes. I'll tell you more about the actual numbers at the end. But before we begin a few disclaimers, this is not about medical, automotive, legal translation. I've been in this industry really myself for a long time. And I know the consequences of some someone's life or legal responsibility, or some non standard processes. So this does not really apply. There are some components maybe, but not probably the whole picture. But some wins could also be taken from what what we observe. What I'm going to talk about is focused on software product UI, mostly. So for the SAS companies software as a service. It can also be applicable for marketing too, with some adjustments, I believe, eager fans market will talk about this kind of things later on. So make sure you listen to that, because I have a sense what he's going to talk about. Anyway, the condition may apply to marketing to over the difference should be more copywriting process not proficient. So if I said, software, product, us suffering service, you might think it sounds too narrow, or it's a niche market. But actually, that refers to the largest companies of today. Most of them, if not all of them are in the software side, of course, our software as a service. That's market size of approximately $150 billion. Plus, there's one thing about the future Software is eating the world, it's actually a famous quote by the investor, Marc Andreessen, than 10 years ago, and who here who is interested in these kinds of topics, topics, I really recommend that you read this, this article is not at all, it's available on YouTube. So in the future, what's going to be different well already is different between the new software that's created today versus the old ways, actually, this graph, I will not bother you with some technicalities, or graphs or diagrams, just like the last time I didn't. But I'm gonna tell you about the basics. And software today is done in an agile way. The most successful companies are agile, it's not the fluff is difficult to implement. But it shows tremendous benefits. This means that teams developments teams, and the company really thinks about what to deliver the next three weeks, based on the feedback they just received. So it's kind of very quick iterations and quick reactions to the market to the users to the problems. You know, that's how companies adapted to COVID. Quickly, because of this kind of a process. And this means that releases or new stuff is released by these kind of companies every two weeks, for example, or even longer, some new stuff every day. This radically different from what we knew to be before, for example, in Microsoft Office, the updates once every two years. So, office 37, you had 2010 that then was all done in a waterfall process or your requirements, then you design implement. And somewhere here you have the localization, there was time to do the translation and review and all sorts of quality checks, which are of course necessary, because once it's out, it cannot, it will not be updated content to the next two years. This is not the same with agile, agile can fix it in 10 days, if something is wrong in two days, or in one case, in 10 minutes. I'm talking about the UI here, of course, the transaction. So that's the huge difference. So please bear in mind, this difference between agile and this waterfall where one step cannot start before the previous one is done and then are like a little training. This is a nice image I used the last time I'm going to use it right now. This is how it looks to be on the software company side these days. During lawsuits, all good old fancy, but actually you're you're growing up, you're constantly the wings are on fire, just to be fast enough for the market to meet the needs of your users. And for those of us who have investors to meet their their targets. So it's not just the whole company, every little thing within the company faces the same problem. And this means that this matters for organization because each of these teams is contributing creating software on their own. So these teams release something every every day. So anytime somebody is releasing something. So we have new conduct literally every day. And this day, this is where we already get to the bottleneck. So we have for example, I think we have our products currently have 95,000 words. That's just the UI. I'm not talking about the marketing, I'm talking about product mutation, just the UI. So for example, today, if we have 120 words, we need it into 11 languages that we currently support. And we typically need is 48 hours. Of course, this refers to the smaller word count. If the word count is larger, of course it changes when we need it. Something like this. And any company that needs something like this today, most likely will will face three problems, minimum fees, ISPs, deadline will be difficult to meet, and the quality will often be compromised. That's how it on the client perspective. Really, it turns out even if you have continuous localization, with traditional setup velocities, you will end up with semi continuous localization. That's what happened to us. So it still continues, but it's semi continuous towards what it could really be. Because quality speed and communication is really severely throttled sorry, now bothering me now, so I am aware of the other side of the thing. So let's not, I can now focus on the other perspective, why the client got those impressions that I showed on the previous slide, there is a good reason for it. And I'm actually aware of it. So if we send 120 words today to any LSP, especially our memories, they will have to do all this, take a look and take good care of this of this, let's clarify requirements, contact up to date 11 different vendors, if they have some mutual for some languages, fine, but up to 11 different vendors, confirm availability with them, or directly for 22 translators, and find replacements for those who are not available or not responsive, in such a quick time, then they have to oversee the progress, they have to answer the questions or solve issues, then verify the completion in the newer translations if they have to do it manually. And then at the end, they have to invoice the client and pay vendors. So no wonder there are minimum fees that I mentioned. Because you have to put them in your feet at this point, for such a small number of what so I'm being aware of it, communication is delayed, of course, you see that the chain, and the quality improvements also get lost or difficult to put through all of this chain. So that's just how it is. But that's how it is with the current process. That's my opinion, the process on the MSP side like that. And I think all what I just said is basically inevitable. As long as the process is like this, why I'm coming back again to this image. This is the difference. We are running the Agile stuff, we deploy things every day or create new code. The agencies by default have to operate in waterfall way they have to they're forced, of course it will it used to be like that, or what is that now they it's not possible to change it because of their constraints. So we have this kind of situation. It's nobody's the villain here. So I really want to make it clear, I'm really aware of cost effective. I worked at telescreens. Myself, and also the freelance translator for my career. So I understand the issues here. But this is what we get this here is what we get clients pushing one way agencies have to push the other way. And localization is somewhere in the middle stretch between the two. So this is an example of today, what about tomorrow? We had 120 words. Today, tomorrow, we'll have 2000 words, Wednesday, zero 1000. Zero words are the 390. Just random numbers, and 10. Basically, forever until we exist or we have UI, we're going to need this. So we'll be dependent on a fresh supply of translations, and everything into 11 plus languages. And this growth really, you know, at least a few languages a year. So take a look at the situation. Now we have no other option but to remain agile because of business and how software development works. Well, MSPs here are limited, basically by the vendors and technology, and summonings LSPs have a internal structure that prevents them to be just to adjust to this principle, but they're mostly limited by the vendors. So the end results are that LSPs do become the bottleneck as a consequence, because they have a whole change that has to be crammed into the small windows of HR, tech giants integrated femora, several MLB as we all know, into their processes, like direct integration, very tight control the processes and very, very strict conditions for the commission. But the question is what about the other 99% of companies including us with less than 20 locales I just put around a random number but I will say this is 99% of software companies. What about us the the there's not yet a million dollar contract that would make any MLB change everything to fit in. But actually it's a huge opportunity because we have today we are unicorn we are tomorrow. Who knows? So that's the kind of there are a lot of lots of rising stars let's go put it that way. And they cannot be tackled and they become ring if we needed any big. So the what the answer is well, if you know that the guy in the in the background image he's he allowed to use the saying He Who Dares Wins. I would say he who avoids the waterfall wins. So don't ask me again if you are want to avoid LSPs No, because they possess past experience. Do it yourself like oh version requires even more automation. But process must be faster. And our customers need that it's not just about us, it's actually the market, we need to do it because of our customers to be fast. So where to start. And I'm going to tell you about the brainstorming that we did during this year, since our last presentation, for example, and I will give you an unnecessary because no brainstorming is nice and polished and clean to follow. I'm going to give you the polished version just to to be efficient here. So we sit down to think about where the where the problem does actually originate. And, of course, it originated in the Agile development process, because that's, that's what changed. And that's not going away soon, because it's proving to be valuable, and just going to be more and more used, maybe replaced with something better soon, or in the future. But it's certainly the best we have right now. So it's not going away any soon. So then the question is, if this is where the problem starts, should the localization project process become more agile, too? Many people have asked themselves this, and many of them have concluded Yes, for agile copying, especially those that are not really small, then they should become agile too. So the question is how to break down the waterfall? Is it possible? The Agile Manifesto did that in 2001, that's the document these guys actually, I think this is the real image from 2001. This is a group of software developers that actually contradicted the waterfall development, they used to be dominating. And they propose the Agile Manifesto in 2001, to be to do software differently, and to break the waterfall because waterfall is slow and doesn't serve the users but also the companies in the long run. So they suggested the Agile Manifesto in 2001. And right now, in 2021, I think it we can say that has been caught on. So it was in software development 20 years ago, and it's still valid more than ever. So it could also give us ideas, too. So we read it and read it carefully. We reread it basically we all knew about it. And we stopped right there. Because we found great inspiration, but I'm bringing it meaning I mean this great inspiration in the 12 agile manifesto principles, even for localization. Literally, with just few adjustments, it gave us a full guide on how to make the localization Agile to we just added a few localization welds into the original principles. And actually audit made sense, we didn't have to reinvent the wheel at all just added a few words. In some cases, not even one word, the text will be sent to you, I will not go through all 12 of them and just go through the conclusions that Kate will send it to you. That's at least the plan. So you'll be able to see exactly where we started from our show just one example. So the summary, what follows is the continuous flow division guidelines based on the adjusted manifesto principles. So let me show the example of one of one month agile manifesto principle. Everything that's in white is actually part of the original manifesto. So business people, developer and developers must work together, they need projects. That's what the Agile Manifesto proclaims, we just had to add localization team, because this is for our purposes. Any training makes sense? When we thought about it, this is what really makes sense. Because you need to be close to the business and developers to know where how to just your localization, where to go next, how to prepare for the next languages and all that. So we just said that these orange words, and we got one guideline. So it said, establish collaboration across the whole company work with people don't operate only within the law department. I've seen this quite often, as you probably know, so let's go to the 12 guidelines. And eight we'll send you the other ones. So unoriginal. theatres are translations early, improve later. That's what we that's the mantra. This means that we should not wait in the old ways for reviewed perfect transactions. Now release the money and then improve later. Be ready for constant content updates. Be aware of it, be prepared, expect them do not require any development freezes. Because you're you're freezing the bill to market, you're freezing the fun aspect of your company. Release rotations as frequently as possible. don't prefer larger batches is installed side by side give you the waterfall type of time. Now the secret is a moving train. You have to release people to translations. This is what we saw establish cooperation across the whole company. The fifth one is very interesting. For agile. It's actually I think very unused in the organization community. Rely on people trust and teamwork. Don't apply the command and control through your localization department or program to actually think of a teamwork and empowering people and not just fluff word It will mean something, I refer to it as later. Prefer direct communication methods do not communicate indirectly through LSP. This is one of the biggest problems I see with LSPs in the in the middle because we cannot communicate with translators, if they need something quickly collect feedback directly or primarily from end users that should be the measure of quality. Do not ask for feedback only from other lenses. So, the linguistic stuff that you need the feedback about how usable your translations are to the end user might not care about stylistic perfection, but it needs to be understandable for them use or enjoy your product. So as from the organization's I'd have different preset perspective on of what quality is compared to actual users. Set up a continuous scale of a process. Don't stop the process either organization team is not there. continuously improve your organization tools and system, then use only third party software as an asset. And then do excels in between automated minimize manual work. So basically don't rely on human project management, or human involvement. Wherever not needed. Empower localization team to choose how they work and of course, be accountable for the results. Don't in system to strictly defined procedures and then just follow them blindly. And also reassess the process and plans regularly do not do it every few years and then just stick to the plan in between. So now what when we don't when we've gone through these 12 principles with Agile brings a mindset change really default. This is an end users feedback team wide automation. And I would say this is pretty much everything should be distinguished, shuffled and sorry, because isn't our location to efficient chain or not containing focus on end users feedback, teamwork and automation. So specifically, we've had to change a lot. That manifesto really has a good track record, even for infamy put software development, we saw it working. My other product that I'm handling, you is developed in an agile way. And the benefits are huge. We trusted it. And we wanted to go with this but we wanted one language. So the experiment, what do we have, we have the vision of the idea, or the process, sorry. So we identified steps needed in the localization process, 14 of them, believe it or not, at least from our perspective, we removed the steps, we do not want three of them. And we then analyzed who can do each remaining step most effectively, the resources we had disposal were LP, of course, SP is a freelancer, faders look, realization Product Manager meaning me, our client base, it's all based on that we already purchased, and other third party technology as necessary. Plus, in house developers very crucial thing for any continuous localization initiative. The guiding principles are simple, calculated risk risks are acceptable. If in doubt, test small first. And if testing is not possible, then simply rely on on manifesto and see what happens because we have to try for one or two things. And always keep an open mind. So this is the localization process slides that I can send you maybe later the screenshot, you will have the presentation session saved because there's a lot of here and I'll have to go relatively quickly through them. So we ensure each item belongs to the category where we put that so LSPs are the best at knowing the realistic price range for any freelance translator, they can find them better than anybody else. Technology. If we find translators, we got found technology that can actually solve the contractual part. We don't have to work on it nor the LSP. And it's faster, we need to define the TMS grid. For example, That was a mistake in our previous experience, we need to now solve this the lesson from this experiment. But it is a task we need to interview the translators to get with the LSB we need to demo our info products to get translated. So they know what they're doing because generic will tech but very specific and enterprise tech by doing so then we test the input with knowledge. We paid for them those done by translators, they trusted the glossary. We validated the glossary. We assigned a pilot file through the system, the trophy, this pilot file, again paid, we validated, all simple confirm the prices and rates with them. We collect them details through technology. So basically FinTech part of the technology, we update the source files, of course through the technology, but we initiated we create the tool that creates the project analyzes project selects the correct TM and TB dispatches the project translators translate, ask questions very important thing. We clarified the contents that meaning which we really do. Then LPs are there for tech questions because they are good with with these kind of tools. Translators also report issues with source happens a lot more than we hope the LSB could organize around random quality checks. We also do reviews rotations in house we incorporate they incorporate feedback and then the tool can check for critical care And then this is all simple later than we were sociation. calculators, ation costs create pavement jobs for the stone technology you don't have to do. We pay translators to technology pay the bank fees for the translators through technology paid the the actual TMS and the LSPs are there to repay through faders if needed, or if another syllable, correct feedback and invoices, and at the end, we pay the 40 steps, we will not do perform free translations, we will not push for lower prices, just the long term that does not come with records, we want to invest in our long term team. We do not perform full reviews in the same tool as we do the transaction. So this would make sense for info because we are more involved. And we will call on it to say to get better paid steady source of work. And part of your team is not isolated somewhere and nobody knows that they're working with a company and technology does what is best. What about the LSPs they handled most of the steps now they're focusing more to financial tools. But they are available consultant. And here they're incentivized they would mean incentivized to work in our benefit, not again, currently, if you think about it, and they could serve many clients with this model could serve larger clients and compete with bigger LSPs because their scope is smaller. And they could provide other services to us because they're already contracted. So copywriting voiceover that kind of stuff is outside the scope. But this is an assumption that must be proven. So I would suggest that many of you would say, Come on, Sammy, no LSP would bother with that. And I would say yes, but we only needed only one to be willing to experiment. And the opportunity came even before we ready to move, we'll kind of finalizing it, there was a chat between it took a different turn with an LSP CEO, I mentioned this and they wanted in the experiment. But should we start part two with beluga feet, must know the CEO young Hendricks so high and if you've seen everybody that will go, we sit down and analyze the task in more detail, like between what they do what we do and where we overlap some somewhere because they are nitty gritty details. And we set up the pricing and possible business model separate from what they do now. So current budget is a reference, we just did that to the average Freelancer fees and whatever was left, we converted it actually to a stable monthly fee, based on the word count, but if there's really sorry, small word count, we have a certain limit that we do not pay below, like a retainer stuff. Or if there's no work, they still get destroyed. And we started with Sweden, the Swedish because we had this position but was not in good shape. So we got our redefined triangle, client LSP interpreters not in a waterfall, but talking to each other in certain because we really did talk about like this. Everything was underpinned by technology. That's why the fourth arm, but it's actually a triangle. So the numbers instead of a summary, I'm close to finishing it, maybe I'll be I'll be almost on time. So instead of summary, I prefer numbers easier to digest for the LSP. This is our observation and confirmed by them. So for Swedish, we had the number of hyper cannons sourced two out of 20 shortlisted that's what they did, it's takes time number of employees overseeing the process once it kicked off less than 5% of the time, because they're always seeing the problems, not the the process that the project the delivery, the quality, nothing, just if there are glitches with the Freelancers, and they need assistance with that their margin was approximately 20% of their project fee. So for approximately 10 times less work, there's that maybe, I don't know, 50%, less fee, two times less feet, something like that. So but the thing is 10 times less work, I will not go into numbers, I do not know about their business model in the background. But anyway, you can do the math approximately yourself. We package them massively. So the number of times they were involved in quality rated discussions and blamed for something zero, that's autocentres number of files in quotes that they dispatched around zero number of invoices that they created once a month to us now to faders number of questions that they asked about source five a day just for one language. That's an excellent metric for us. We used to receive that amount of questions in a month with 10 languages. So you see the difference? number of questions that were answered all of them within 24 hours. The number of days they waited for payment before from the day they started working on a file it's around 20 days the amount of money lost in Metro euros or USD you feel should we cover it because it's like I said it's teamwork and they have to see the price if that's what they will get paid. And then integrate for the businesses among us. The total time rate is waiting for translation zero minutes. Time is fixed language errors. translations are source automatically by midnight or immediately if it's critical development resources needed wonderful time engineer in the last year 30% of my workweek 30 40% that I have another product. Localization budget was the same as the For an ISP which to sell the standard, minimum fees paid zero. So in our conclusion is experiment was predominantly successful. So the lessons learned on the last slide is for software businesses, they are speaking translators can take anything from this, it could be useful to them, but there's not a business should really think about the retaining the ownership of your organization profit if your content, it's not your profession, your content, just like English, if English is your major language, remember that proficient human collaboration, not a faceless chain and reap the benefits from that. Set expectations early and trust people to do what they know to do and they to demonstrate their expertise, give them room and financial incentives through the rate to learn about yourself and ask questions really unleash their potential and run small checks. Of course, you have to do it, and experiments often true for all of us to improve. So that's it. I hope I'm on time, sorry, Max, if I went over it. If we reach out if you have any questions here, my contact details or just send me a patient or

Max Morkovkin 31:07
thanking me, it's a great timing. Thank you very much. We actually thought that, because the presentation is so insightful and informative. You won't have time to answer the questions, but we have at least eight minutes. And I think your speaking speed helped a lot.

Semir Mehadzic 31:23
I think you're able to understand what

Max Morkovkin 31:26
I was listening. I was supposed to do something at the background, but I can't stop listening. And we're looking at your slides. So for sure. One thing I would like to Yeah, I would like to rewatch it. Thankfully, we have the recording, and other people can also see it. Hot Topic. We have nine questions. Let's start with those who have some votes. Let me help you to read them. aroa, creamy Chaura. I'm sorry, if I pronounced that wrongly asking you what are some methods to ask for feedback from users?

Semir Mehadzic 32:02
Great question. Really great question. It's probably it's a technical problem. You can of course, interviews are started that clunky. And that's not it. We have been right now investigating the ways to collect feedback more systematically. Right now we get it from our global users across the world, because in fact, we have 3000 employees in 70 countries. So we have our internal users across the world who give us feedback, that's not doing users as we would say a bit when they talk to them, because they're in sales pre sales process, we are now improving, trying to add them suggest improvements we have formed on for the translations to just to make it easier for them and be available there to easily report any suggestion because people do report suggestion for improvements of transition that's really curious and lovely. So we want to take full advantage of it because we trust in also in their personal perspective of quality, you want to what's blocking them.

Max Morkovkin 32:59
Okay, good. Just to remind you try to rate those questions, because we will need to choose the winner. I hope we will be able to we keep we keep having new questions, I think, Okay, the second one from Adam in data. From my understanding, the idea is to bring LSP closer into the client organization and up in the process for a gel to work, but still due to the fact that LSP translator is external party, they will always be a gap between the LSP translator and the other internal teams in the company. Any suggestions on how to solve this issue?

Semir Mehadzic 33:33
In this sense, now, look, we're a we're accompany. And then everybody else is external, of course, that we wanted to bring both translators from a separate side, and LSPs from a separate site to be as close as possible, like on the edge of of our company to be like an external team, of course, as much as we can. This means that translators are completely basically are related to the LSP because we pay them we signed the contracts with them. We answer their questions. LSPs are there to oversee the quality find and source any review, interview them together with us? So basically, the LSP is there and independent party that's knowledgeable authorization organization that can give us or maybe instruct us to maybe pay attention to some improvements or some problems, but they are really separate entities there. If I put it like two items, and we add a third. They're not part of the same equation anymore.

Max Morkovkin 34:25
Okay, good. Let's move next. Nestor Solana is asking. From the project manager perspective, how can we include localization in the company's Agile processes?

Semir Mehadzic 34:37
Very difficult to this this is a top down decision for us team for the change was possible because we put translation within product development. So I'm a product manager and my vertical CTO I went to CPR with all of this end product, not in English, but in other languages team the product team affects our finances. and everything. So it's a matter of business strategy. So when you put it as a strategic thing, then then actually it can blend in with engineering and product within the Agile outside of it as a separate localization team, it's very difficult to change everything, because you will need to be closely closely intertwined with the actual development process. That's why I will suggest the first step to continuous localization to any company allocate at least half of the time of product manager, and at least one developer. Without it, you cannot really go for it, because it's impossible. They will tell you how to do it, and also have some, you know, voting power already to push these issues on the company's agenda.

Max Morkovkin 35:40
New Thank you another question from nada, this one got four votes. You mentioned translators identifying source text issues, how do you fix those as part of the continuous localization process? Is there a source QA step built into the workflow before translation?

Semir Mehadzic 35:56
We do, of course, I mean, there's a q wave on the testing side. And of course, the QA in software usually focused on functional problems on a serious issues, a typo here or there may slip. automated tests for quality because we have a huge product enterprise. So really, occasional typos can slip, we call developer English, some error message, nobody sees them, you cannot even reproduce it. So that kind of stuff we saw source, we see source errors. And that's what we see through the TMS to say to see, and then they say, Hey, we have April here in the source. And with us with continuous localization, we managed to create a language for the source to so we updated it as if it was translation. So we were able to avoid developers changing it, we iterated through the TMS and sent it to them later. But we show it on the production immediately. There's the thing of continuous rotation, we show things from the TMS directly to the users, it doesn't go to the developers. That's what a lot this the decomposed profession, for those of you who are technical here that will allows it to be really continuous. You cannot have true continuous localization, you have to wait to developer to change one typo in English source for seven days, or God forbid, neutralization and wait for seven days. We have to be very quick. We do it in 10 minutes if you want both source and

Max Morkovkin 37:16
translations. Wonderful question from Maria Chavez, USA. Samir, how do you get buy in from upper management for continuous agile as presented there? Sorry, let me probably let this person to ask it directly. Because it's this. I think the third time someone's wants to ask you directly. So let's give a chance to Mario. I'm Kate, can you help with this? Yes, just a second. Okay, good. Yeah. Really hot topic. While we wait for Mario to join a similar What do you think if we will continue these in maybe SmartCAT. LinkedIn, so we'll make a post. And then attendees can keep asking questions. And you can communicate with them. Because we still have I think five or six questions, and they keep coming. So and all of them are interesting. I think it makes sense to continue this and then choose the winner. Okay, sure.

Semir Mehadzic 38:17
Sure. Count on me. No problem.

Max Morkovkin 38:18
I'd be Hello, Mario.

Mario Chavez 38:20
I'm really privileged to be part of this. Thank you. I've been enjoying your presentation similar because it touches on many things that I'm living through with my software company. While it's not mine, it's my employer. And that you kind of have answered, you know, partly answered my question like how to get buy in when you're invisible? You answer that? Well, you need to talk to the product product manager and at least one of the developers involved in the process otherwise is impossible. It's because the decisions have to be top down. Did I get that correctly?

Semir Mehadzic 39:04
Yeah. To ask really helps. Like I said, I was already in the product manager. So we did what a lot of companies are starting to do now our create localization to product managers to lead the technical part, of course, you need localization people. To do this together. I just happen to have both sides. So I did it myself. Anyway, I was in product already. And the natural partner for me was the product management, because they decide what gets built, what gets localized. And even with the business where to expand next. So if you are not part of product, actually, that helps you because I had to have, let's say a sponsor, in this case, a CPA and a few directors from my vertical that were touching this initiative. So without sponsorship and top management, like support, it's difficult to push this through because it's tough to do it. It takes a while. If you have that kind of support. It's doable, but just from your from your side. Now, you know, you have to have allies And like I said, product manager and developer also likes to condition people to speak all the languages that business and top management speaks, I'm not talking about the real locale for languages, actually, the number, the numbers, the technical language, and the business language that often lacks. We, in the localization side often like this, the technical and business, like, I will say language, but you understand what I mean.

Mario Chavez 40:25
The challenges that I'm that I'm facing that my, my manager is very supportive, but she is she's the technical writing manager, manager. And the thing is that our main boss is the product manager in engineering. So and he basically, he's kind of the bottleneck in terms of okay, this is the information I can give you, I choose to give you and it's not enough. It's basically, in order to vary.

Semir Mehadzic 40:58
asked for some product management time, not the full one, but 30 40% and let someone from the localization team in this case you closely work with him and things can change within a few months, not within a day or two or a week. Okay, any more questions, Max.

Max Morkovkin 41:12
I'm very sorry for interrupting your discount. I think we have to move forward and summarize discussed. So we will move these questions into LinkedIn. And we'll ask you to answer them and then choose the winner and we will announce it there and LinkedIn. Thank you very much for a wonderful, amazing presentation and join us again, talk to you later.