Companies that do business in the native language of their customer build better customer relationships. Although this may seem fairly obvious, it's easier said than done.
After all, when your customer base is spread around the world, how do you scale your customer service?
Unbabel has built their business around the idea that customer service can be delivered in any language quickly and efficiently with the right blend of AI and human intelligence, creating a platform they call "Language Operations" or LangOps.
Jonathan Sowler, VP of Engineering at Unbabel, joins Dev Interrupted to talk about machine learning, what it takes to build a product that seamlessly integrates AI and human-powered translations, and why the future of language involves emojis.
Dan and Jonathan also rundown LinearB metrics and why Jonathan believes implementing LinearB has improved the health of Unbabel's engineering team.
Episode Highlights Include:
- What is LangOps?
- How ML can be applied to different brands
- Unbabel's use of WorkerB
- Why Unbabel chose to implement LinearB metrics
- Building a platform that integrates AI & human intelligence
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Transcription:
Dan Lines: Host
Jonathan Sowler: VP of Engineering at Unbabel
---
Producer: [0:00] Hey everyone. This is Connor Bronsdon, executive producer of the Dev Interrupted podcast and occasional guest host. With the holidays fast approaching, the team here at Linear B will be going on a short break to unwind and spend some time with our families. Coinciding with that break will be the end of season one of the podcast and the beginning of season two. You'll hear from us one more time before the year is over on Wednesday, December 29th. That episode will mark the end of season one of the pod and we'll return to our normal schedule on January 8th, 2022. With the start of season two, we have some incredible guests lined up for season two, and I can't wait to introduce you to them all. From our family here at LinearB to yours Happy Holidays. And now let's get on with the episode. This episode is sponsored by LinearB. Accelerate your development pipeline with data-driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo at linearb.io and mention the Dev Interrupted podcast discount for one month free when you sign up for an annual pro membership.
Dan: [1:02] Welcome to Dev Interrupted. I'm your host Dan Lines and today I'm joined by Jonathan Sowler, the VP of Engineering at Unbabel. A quick reminder for our listeners, if you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcast, please do so. Reviews are a crucial way that our show gets discovered. Jonathan let's start with giving our audience the opportunity to get to know you a little bit better before we jump into your role at Unbabel. I understand you have a degree from Oxford in philosophy, psychology, neurophysiology with that type of interesting background. How did you get into your path of engineering leadership?
Jonathan: [1:47] I went to university in the days before machine learning degrees. Or any-there was no machine learning. So, I actually went to university to study mathematics and was kind of interested in the brain and connectionist theory and there was nowhere to go and study. I didn't know at the time there was some places in California and Canada, obviously in Toronto, but there wasn't much on offer. And I changed courses half-way through and came out with a degree in neurophysiology, philosophy, which was absorbing, and psychology.
Dan: [2:19] That's really interesting. What effect has that had on you?
Jonathan: [2:24] Good question. I think, when machine learning starts to be a big thing. It certainly made it attractive. It was like yes, that's-that's what I was trying to study ten-twenty years ago. And now it's here. now finally. I can remember when I was studying, I was very interested in what even then was called artificial intelligence, and I remember a quote from a French philosopher, that it was neither intelligence and lacked artifice, and I just thought, Well, okay, maybe now's not the time. So, after a twenty years pause, some of the skills that I developed became marketable, and companies started working the area.
Dan: [3:00] Oh, for sure. I mean, if you're in machine learning, AI, anything like that, those are the sexiest buzzwords in the engineering community for a little bit now, right?
Jonathan: [3:09] Yes. Only took us ten-fifteen years.
[Laughing]
Dan: [3:13] Now, also in your background, I see, you know, you've been a CTO, obviously you're the VP of Engineering at Unbabel, an incredible company, we're going to get into that. Was there any like inflection point in your engineering career that kind of launched you into being a leader?
Jonathan: [3:31] It was little more than I was working as a-I started as an engineer, worked as a developer. And then back in the 90s, I don't know how many people remember back in the 90s, the internet came along. And I started a business-started a business with some acquaintances that really started the business plan that was as simple as the internet will be big. People will use the internet to do real business, so they need security. So, from that was born a little company that made some good decisions around working with Java, and we started with cryptographic protocols. And I looked at the cryptographic algorithms, and then built protocols and then started to work with non-repudiation and some of the different identity and some of the building blocks that you need to build meaningful, secure systems. And it was through that, that I-I was part of the leadership team at that business and started to enjoy working with engineers, understanding how you build product, and it was the early days of product management to the existence of thinking quite the way it is today. And that just-and then that business was sold to Sun Microsystems in 2000. Then that really launched me into a career in technology and technology leadership and working in the space.
Dan: [4:48] That's incredible. Was that kind of security business, was it-I guess maybe not considered a startup but was it like a small company that you got to grow with or was it already big when you got there?
Jonathan: [5:00] It was a couple of people sitting behind a motorway service station in a place called South Mims off of the M25, just north of London. So [crosstalk] [5:10] behind the service station, you can see white house, it was there when I joined.
Dan: [5:10] That’s amazing.
Jonathan: [5:14] And I think the first day we spent cleaning the walls, and not really talking about products. And we grew from there to be about seventy-eighty people, which started in London, we ended up with quite a presence in the US. And because we'd pick Java as the language to grow with, we built very close relationships with the great team at Sun. And the Java solve team, and it was a fabulous experience. So, it was sort of in my mid-20s. At the time, it was yeah, great to be great. It was an exciting time.
Dan: [5:45] A lot of people probably in our audience would love to be in your position, like a VP of engineering of an incredible company. A lot of them are kind of like one point in their career, will take a risk or say, “Hey, I don’t know maybe if security was the thing back then, but hey, I'm gonna go join this little company, or I'm gonna try something.” Did you feel like you were taking a risk? Or was it just like, “Hey, this is something interesting. I'm going to try it.”
Jonathan: [6:11] It was the latter, so there was no risk, there was no sense-in your in your 20s. even now you don't feel, I'm not losing anything. It's exciting. I have no idea how this will turn out. In fact, I don't really know how the product develops. I don't know we had some competition. I don't know where the competition will come from. Let's just-it's a good idea. I can see the value. I know people will pay money for this.
Dan: [6:33] Yeah.
Jonathan: [6:34] And we're filling. You know, if you think about how the electronic commerce at the time, it was called electronic commerce, how electronic commerce is going to develop. Well, fundamentally, it needs this thing. So, this thing has value we really went from there.
Dan: [6:48] Thanks for sharing that story, a little bit of a transition now to Unbabel and your role there and the team that you've built. Can you tell our listeners a little bit about Unbabel, what it does, and kind of your role in your team there?
Jonathan: [7:03] Unbabel is a translation company, dominant use case is customer service. So, if you think about a big multinational, let's say Acme Corporation, and they need customer service agents, and the customer service agents work in global markets, so they need to speak different languages. Well, Unbabel is a translation company, plugs into those customer service agents. And so, you can use English agents to deal seamlessly with Japanese or German or French customers, without the agent needing to speak any other language than English dealing with the tone of voice dealing with the style of the company that that Acme is, and the end customer, the Japanese customer or German customer, the French customer, will have no idea that they’re talking to an English agent. And so you imagine for a business that is running customer service globally, it means that you don't have to scale all of your language support to handle peak load, you don't need enough Japanese agents to handle Christmas day all year round, you can employ enough people and then when you hit a certain limit, you can get English agents to pick up the Japanese language and deal with-with Japanese tickets and chats or inquiries. And similarly, just it gives you, in the customer service space, some insulation from the inefficiency that language support through humans will dry. We work in partnership with some of the biggest multinational companies in the space, we work with many BPOs in the space providing real time for chat, very high-quality translations. In the customer service world integrating the agent systems.
Dan: [8:40] Is most of the technology built around like a chat base like I'm-you know, I go to I don't know, somebody's website, I'm a customer, I need support. And I'm talking to them through a Drift chat or whatever chat, how does it actually work in real life experience?
Jonathan: [8:58] So if you think we have sort of two base products at the moment, one is synchronous, it's an ongoing chat conversation, and so, it needs to be quick. And the other is asynchronous when you submit a ticket, and you've got some time to wait. And if you think about what we have to do translation, we have machines to do the translation. Machines are quick and they’re cheap, or relatively cheap, but we know they make mistakes and machine translation isn't perfect. And we have humans. Humans are a bit slower. They're a bit more expensive, but they generally do a human quality job. And so, Unbabels’ world is about bringing the two together. And the thing you need to bring machines and humans together is something that understands whether that machine has done a good job. And that we call bit QE and-Unbabel is one of the world's innovators and has recently released something called Comet which is open-source which allows a machine to mark on other machines’ homework. And so effectively the machine does the translation and then another-another machine works out whether it's likely to be a good English or a good human-human like translation, and at that point, you can take a decision, well, I'll trust that I'll go with the machine translation, I’ll go with the artificial intelligence, or I'll pass that on to a human. So obviously, if you're dealing with a synchronous translation, you want to focus on the machine translation, and you send that back because you haven't got time to go to human.
Dan: [10:27] Yeah,
Jonathan: [10:28] Like, what you can do is understand where you weren't that sure about the translation, and then get a human afterwards to have a look and annotate and then feed that back into the machine translation engines to allow them to learn and do a better job going forward. And then when you've got some time, the machine does the translation, you can then take a decision, do I use them, reduce the cost, or do I go with the human translation, and I get the quality up but it's going to take even more time, and being able to sort of decide between cost, quality and performance gives you the ability to look at different translation use cases and come up with innovative solutions that are very disruptive and that’s Unbabels’ business sense, where Unbabel different traditional translation houses and LSPs of organizations that play in the space.
Dan: [11:16] It's amazing. I mean, the kind of like the pain point, or the use case makes so much sense. I mean, if you're in a-you're a customer, or you're in a situation that you're trying to-usually if you're talking to like support, or you're, you know-you're kind of like I want to get something solved here, and you can tell instantly, if you're talking to someone typically, probably if they're not using Unbabel, that is not in your native language, it can be very, very frustrating.
Jonathan: [11:44] For the business. And there's lots of research that says, if you do business in the language of your customer, you will build a better customer relationship.
Dan: [11:52] So sure.
Jonathan: [11:53] Try to do business in that language.
Dan: [11:55] I don't even need any data to prove that to me, I just know that basic human instincts to-totally makes sense. And we can see it, you know, some of the valuations I've seen coming from Unbabel. I don't know if it's official, but you're on your way, billion-dollar, you know, value. And so totally makes sense to me. What I wanted to dive in just a little bit, you know, from a technical perspective, what are the challenges and building a product that you know, needs to translate these languages on the fly?
Jonathan: [12:26] You've got a number of different challenges, you've got performance.
Dan: [12:29] Yeah.
Jonathan: [12:30] You’ve got, in fact that to get a request for translation into a canonical form, the machine translation will recognize and do a good job with, you've got a lot of processing steps to understand what's been submitted and how you-you get that standard form. You have the QE engine; we have sort of talented engineers that work in that space. And then you've got the ability to schedule work for the large community of human translators. And you want to use that communities effectively as you can, and you want to keep the work coming for them. And make sure the right person picks up the right tasks. And also keep it performant. Keep it reliable. You're part of big brands conversation with its customers and the service can’t disappear. It needs to be reliable. And so, you have all of those challenges of providing, and it needs to be 24/7. We have global customers around the world, it needs to be there all the times.
Dan: [13:22] Yeah, there's really no room for lag, or we're not having a good performance day in prod or something-something like that. How-how do you, I guess, set up your team from a reliability standpoint to ensure that it's always working and working appropriately?
Jonathan: [13:43] We have a good SRE team, which is a good place to start. We have good practices in monitoring metrics, and we-like many organizations, we have small, empowered teams, those teams are not only responsible for building the software, they're responsible for their operation. And so, if it's service, fails, or is slow, it is that team that gets out of bed at two o'clock in the morning, to deal with it. And as a result, that team tends to be very focused on testing and reliability. And I think that approach of small, empowered teams responsible for development and operation seems to be in the industry delivering the best results in terms of reliability and performance. It makes the team accountable, and teams know accountable, not just for building great software, but for building it to operate and operating it and seeing it work, perform the thing.
Dan: [14:35] You mentioned, it's not necessarily unique to Unbabel, and of course, Unbabel is a LinearB customer, and we've worked together. What I have seen is, and I talked with a lot of engineering teams, one of the characteristics of more I would consider elite engineering teams or high functioning engineering teams’ kind of is that end to end responsibility taking into account “Yeah, you're gonna own what you ship into production.” Is that a philosophy that you had to put in from the beginning? Do you hire with that? Like, how does that permeate for you?
Jonathan: [15:11] That was here, the company that was here when I arrived. So, the company as a startup business, the founders had spent a lot of time looking at best PAC practice, they'd read Accelerate, and they'd read all of the books about how you develop that sort of high performance. And as a start up, they had developed some fabulous services that worked and could work that way and then some things that we had to work on to get the services robust and resilient and work on the deployment pipeline, so that, you know, the testing was there. Your deployment pipeline is the way you manage risk. And so, we spent some time, a lot of time, just making sure that those pipelines did their job. And engineers love working that way. It seems to be much more natural. Remember, the days when you build software, you threw it over a fence to a QA team, they sometimes throw it back, and eventually that software would find its way to production. I mean that was inherent-as an engineer who worked that way, that was just an inherently frustrating way of working. And then finding there was an issue in production that you weren't told about and would come to you when it had escalated; that was a hugely frustrating way of working as an engineer. And this is a much more natural way, the idea that you could-you have control, you know, even over the infrastructure and the resources that an application has, and you can push that out. And there's tests, all of the tests of the pipeline to ensure something is production ready to go. I mean, it is a-for an engineer, it's just a very natural way to work.
Dan: [16:43] We've seen you know, even just like the happiness of engineers, if you have low cycle time, and you know, fast cycle time, and I can get my code out to production, and I do have the ownership, that just feels better. So, I had one job in my career as a developer, where what-my first job I the school, I was building actually like voice recognition software, that was for Nuance NaturallySpeaking, also for like the support agents and that kind of thing. But yeah, I worked on a project for like six months, which felt like it was a long time. And then it got passed over to QA. And I never even know what happened to it, I actually quit within a year and join the startup. So, I don't even know if my code made it to production, I just felt like that was the oddest experience ever! And then after that, I joined a startup and we were more so on the agile but yeah, I really, you know, because I can see your metrics, and I can appreciate all the work that you've done there, I can see it's a very, very important, I guess, tenant of your culture.
Jonathan: [17:49] Yes. And you spoke, we've adopted LinearB. LinearB has been great, but what we didn't do was to give LinearB to the senior management team and say, you know, now manage the engineering team, we gave it to the engineers, and said, “This is healthy.” So now, you know, we can see whether you're healthy or not just make everything green, show as the world is healthy. And if it's red, explain why it's red. Explain why the code reviews weren't done. Maybe it's a small team, and people were out for a reason. And actually giving them the tools and saying “Look, it's your job to show that you've got healthy practices.” has helped in the culture.
Dan: [18:28] Let’s dive in there a little bit. You know, there are different tools out there that can give you metrics about your engineering people or wherever you want. What made you choose to work with our team and choose LinearB?
Jonathan: [18:42] I think the easy things is you did a lot of the heavy lifting. So, for us, we've talked for ages about what we should be measuring cycle times, we should have more information about the developer workflows, and we work in, and we have JIRA to manage-to do work management and a bunch of other tools that the engineers use. And it was just easy to find a tool that seamlessly integrated, I think we're up and running within a week or two, I spent some time with the CTO João Graça who’s a real expert in the machine translation space, looking at the result, and thinking about the teams and then just gave it to the engineering leads, who got their teams using it and started using the product-stand up, and sort of understanding how they were doing. And the Linear B team did work with the teams to understand the tool helped us configure the environments help with Slack integrations, and it was adopted seamlessly within a very short period of time.
Dan: [19:36] If we’re just, you know, looking at some of the higher-level numbers, you've actually had a 60% decrease in cycle time, which is pretty cool to see.
Jonathan: [19:45] And I imagine that's-as much as it's about Linear B, I imagine a large part of that is people just realizing they’re being mentioned and thinking about it and remembering that cycle time is something that's quite important and just changing behavior a little bit. But it hasn't happened through any whip-cracking or-it's-it happened very naturally.
Dan: [20:06] That's completely right. One thing that we see around our customer base is the concept of conversations. We're having conversations now we're talking about these things that matter where there's bottlenecks, you know, within our organization now that we can have visibility into the numbers, have you seen that at Unbabel? That conversation starting to happen?
Jonathan: [20:29] But not only the conversation, but I'm going to use a buzzword psychologically safe conversations.
Dan: [20:36] Yeah.
Jonathan: [20:37] You know, we-we try and have an environment where people can raise issues and talk about issues, not everything goes well, sometimes we do the wrong thing. Sometimes teams make mistakes, they don’t get the planning right. And you just have a culture where someone can put their hand up and say “Actually, I've got this wrong. Well, things aren't working, I need to find out why.” And so, you can have conversations, why is the cycle time long? Oh, yeah. Okay. And there's no downside, obviously, you know, if-if mistakes or issues are being made repeatedly, then you need to take some action. But most engineering teams are self-correcting. If you show them how they've measured and you work with them in a psychologically safe way, they want to do a good job. And most engineering teams want to deliver something of value and do a good job and want to be seen to be doing the job. So, they will change the way they work. And they will be very mindful of what they understand good is.
Dan: [21:31] Absolutely the-you call it psychological safety. It seems that that's kind of just built into the culture at Unbabel. But you're right, if you have that safety, and everyone gets onto the same page of what is happening within engineering, we can all see it. There's the visibility, we're talking, I guess, in the same language actually going back to your, you know, original, one of the original purposes of Unbabel, if we're on the same page, we're speaking the same language, now we can have a conversation maybe where are the bottlenecks? Or where could I use some help in my delivery pipeline? It actually seems like you're you have that built into the culture, yeah?
Jonathan: [22:08] Yep. So, it's how do we do a better job, and we all want to do a better job, we want to be world class, I don't think there's anyone who's in the industry who's just-doesn't want to do a good job, I think if you can inspire people to do better, then teams naturally think about how are we working. “Huh, look our code review depth isn't as deep as it could be and maybe that's contributing to some of the issues when we push to production.” So if you have those conversations, and you work with teams on the problems, teams just getting better, and you-you build much stronger culture, we've always been, you know, toxic environments, where-
Dan: [22:43] Yeah.
Jonathan: [22:44] That's not the case, where you can't have those conversations, where you're expected to be perfect with every release, which as an engineer, I-my days as an engineer, it manifestly wasn't and-and you made mistakes, or you misunderstood the brief, or you didn't understand quite what the requirement was. I say user requirement, in my day, as an engineer, quite often, you were given a very large specification, which by the time you'd worked your way through, the world had changed and the user [crosstalk] [23:11] wasn’t really interested in what you built.
[Laughing]
Dan: [23:11] Yeah.
Jonathan: [23:13] I mean, they were the-they were the days that I learned my trade, but things are very different now. And also, Unbabel is much more of the company that, as an ambitious twenty-five-year-old, I would have wanted to work at. I mean, it has that you turn it up, you do your best, we have a culture of learning, you can make mistakes, we think about measurements, we think about great practice. And we engage the staff, we don't just tell them how you work. This is how you work. You know, many of the good ideas come from the engineers, most of them-pretty much all of the good ideas come from the engineers. And then there's a bottom-up grounds what to the-to the culture.
Dan: [23:48] That's the perfect way, I think to see improvement and you're totally embracing it. You mentioned for example, review depth and for our listeners review depth relates to how much feedback is a developer getting on their pull requests in terms of comments in terms of the-the metrics that you care about at un-Unbabel; How are you approaching it? So, you know, what metrics do you look at? And is it more of guidance from you as the VP of engineering? Or is it kind of like, here's the guidance and team leader is kind of each one of you are responsible? Like how do you approach the metrics?
Jonathan: [24:29] The metrics get pushed down, so it's up to the engineering leads to know that they're running a healthy team.
Dan: [24:34] Yep.
Jonathan: [24:35] Feel accountable for the way that their teams work and what are we-the metrics that we're interested in, obviously, the cycle times, which just are great, we just-how big is the MR? How big is the change that you're making? Because if you're making huge changes, we have problems, you are doing too much work without checking it and we know small changes often results in a better product. We look at the amount of rework against new work.
Dan: [25:02] Okay, yeah.
Jonathan: [25:03] There are times when you are reworking code. There are times when that happens, but just making sure that we expect what we're seeing. And the teams have a healthy amount of new work, we're making some progress, we're doing some new things, rather than just going over old code and dealing with issues in the old code. There are there are lots of things we look at the coder, a few cycles, how quickly a change is picked up for that peer review, because we know that's important. And are those peer reviews happening? And is everybody doing peer reviews? And just making sure that those things are happening means that I get a bit more sleep at night, the product, when it gets pushed to production is in the right state.
Dan: [25:46] Yeah, the peer reviews, the pull request process. It's such a collaborative process, it's a social process, we have a lot of engineers that are now working remote, or you might have people all over the world. And one of the investment areas that we've done within Linear B is what we call our WorkerB feature. So well, you know, essentially, what WorkerB is, is this kind of intelligent bot that each engineer either can turn on themselves, or you can turn it on at a team level, and it provides awareness on pull requests, “Hey, Someone's waiting for you. Or here's how long it's gonna take to review this code. Maybe you should start it after your meeting. So, you can finish it end to end.” How have those WorkerB team policies been used at Unbabel?
Jonathan: [26:31] They've been used. I mean, we couple them with good rituals. So, for engineering, it's still a very social, process [crosstalk] [26:38] to have it done well.
Dan: [26:38] Yeah.
Jonathan: [26:40] The team needs to talk together; they need to understand what they're waiting on. We have lots of dependencies by team, so we have a lot of small teams but they have-if you imagine what we have is a great big pipeline and the change that one team makes is going to impact people that are in the pipeline. And so, the dependencies between teams are quite significant. And we also work in a way where we have teams that are very much focused on the translation process. And then we have another set of teams that translate that trans-translation process for each of the use cases that we're targeting and provide reports and information for our customers. So, we have two very different styles working with fundamental dependencies, which we try and contractualize through API's and in a fairly established way, but there needs to be a lot of social communication within the team, and good strong rituals, and also in the planning process in the understanding of dependencies between the teams. So, the work can be stuff, absolutely supports that and contributes to it. But in-and as great as LinearB is, without those rituals, and without being played into those conversations, then, you know, it's-it's not going to work. So together with the rituals, together with the conversations, and socialization of change, the people know what's happening in the business, really works very well.
Dan: [28:03] It always has to be that combination, may appreciate you, you know, taking a little time to talk about LinearB, and we're really just a catalyst of what you've already been doing and helping with those conversations and the culture. Flipping us back to Unbabel. There's actually something that I was really wondering, while we were talking earlier, when you're doing a language translation, there's so much, like, nuances to the way that people might chat or type or different, like, slang, I guess, is what we would say in the U.S. And that's kind of evolving, I think, all the time throughout human history. How do you account for that?
Jonathan: [28:43] Well, it emerges we-we also have to deal with cultural differences in tone, when to be polite, when to be formal, when to be informal.
Dan: [28:52] Yeah!
Jonathan: [28:53] We also have corporate choices about how they communicate. So, one company may decide to be very formal, another company may decide, “Hey, we sell a different style of product, we're going to be very informal.” So, we spend a lot of time on vocabulary. So, on termbases, so the vocab-the translations of particular terms that are used, but also, in the style. If you look at our machine translation engines, they have different styles. And we adapt machine translations to the way that a particular brand talks. So, if you have a gaming company that's very informal, with its customers, its machine translation service will work very differently in the same language to maybe that of a financial institution that talks to its customers in a very different, a much more formal way. And that's a fundamental adaptation in the way that we work and then over time, because we're passing traffic through the engine, we're retraining constantly to understand the way that a company should be working. We're using edits and communities to validate and annotate and understand whether the machine translation is doing a great job. So, it's quite [crosstalk] [30:00] an intensive process, to find a communication style that fits a brand or fits a particular company.
Dan: [30:00] That’s amazing. Yeah.
Dan: [30:08] That's really cool. Are you doing anything-I don't know if this is possible, but let's say that a translation has happened, and that's been sent to the customer. Okay, here's like an answer to something. Are you able to also kind of read how the customer is responding to that and then learn, “Oh, this” you know, I'm making it up here, but, “Hey, this was a little too formal.” or do you learn from the responses? [Laughing]
Jonathan: [30:35] We-well, we can, we absolutely can and one of the things that we allow the customers to do is feedback on the translation. So, an important part of the process is to get that customer feedback. “Oh there’s mistake here, this term wasn't right.” or the tone wasn't right, or the customer complained about. And so, we're very open with our customers about the quality of the translations that we're providing to them. Because we know most of the translations will hit the mark. But there may be a small number of bad translations, we want to get them to optimize the service. So, we want to understand well, did we, for instance, rely on machine translation, and we shouldn't of, we should have sent it to a human? Or did the human not do a good translation? Didn't they understand the domain? Do we need to give them more context to make an accurate translation? So that-that focusing, and that's where you get to your continuous improvement. We know we're doing a good job, because we spend a lot of time thinking about how we make incremental improvements to the translation quality in different language pairs that we work with. And a lot of the work that we do is around that.
Dan: [31:44] That's really cool. Yeah, I guess that's the name of the game; continuous improvement, right?
Jonathan: [31:48] Absolutely!
Dan: [31:50] Now, I see that Unbabel has this global, multilingual, CX report that has come out. Was there anything from the report that you think would be interesting to tell our audience about?
Jonathan: [32:03] Yes! There was fabulous stuff in the report that kind of backs up lots of the key messaging of the business, the importance of speaking the language of your customer, and the contribution to CSAT. Those sorts of metrics, when you talk with, and can work with the language of your customer, the ability to effectively service your business through digital channels, I think sometimes you read the customer service is cheap or free. And then you look at what big organizations do to service their customers, they have call center agents around the world, they have contracts and BPOS to handle the volume. They're obsessed with having people available to deal with issues and to deal with them quickly and successfully to get a positive out to the short period of time. And the role of language and the ability to manage language, we call it internally Lang Ops, your language operations is absolutely fundamental to your organizational ability to do that. And actually increasingly if you think about what Unbabel is doing as a business, from the point of view, if you imagine you're a senior exec in any business, then you have language issues, right the way through your business lifecycle, from the marketing you do and the sales context that you make, to the packaging and instructions in the products that you sell, to the way that you service your customers, you follow up and you deliver support. The way through that lifecycle, you need to be able to work effectively in different languages, if you want to be a global business, and increasingly, I think one of the things we see is in it that absolutely used to be the domain of the large multinational, increasingly, it's the fast growing organizations who are rolling their product out into different markets quickly, can't afford to maybe necessarily go out and recruit all of the native speakers that they need to manage the business at risk. And this sort of language operations will understand all the bits of the way you use language as an organization and to-to manage the efficiency and the resources that you have to deliver the best business outcome is a large part of the conversations that we have this business. And I think language or Lang Ops, language operations, is becoming an increasingly part of lots of people's worlds.
Dan: [34:21] Well, Jonathan, I want to thank you so much for coming on the pod today, talking to us about your career and how Unbabel engineering is operating and some of the ways that you're utilizing LinearB. I know that you have a lot of hiring that's going on at Unbabel. Probably a lot of engineering roles open. If I was interested in joining Unbabels’ team, how could I do that?
Jonathan: [34:49] Just contact us per unbabel.com. We are hiring. We are hiring good engineers. We're hiring product designers, product management, product managers. We're hiring lots of people in the sales and market world in most of our teams, and what can you expect is a friendly, challenging, rewarding place to work and working for a business that is changing the way people do things, and building more effective communications. So, it is a great place to be working.
Dan: [35:19] And I'll just, you know, add on to that I have worked closely with the Unbabel team. This is an elite engineering team. As we talked about, they have the right culture, the right processes. So, if you are looking for your next opportunity, please check out Unbabel hiring opportunities. We’ll include all of those links for you in the description below. Also, be sure to join the Dev Interrupted Discord community where we keep that type of conversation going all week long. I also want to say thank you to the more than two-thousand of you who are now subscribed to our weekly newsletter. We bring you articles from the community, inside information on weekly pods, and the first look at Interact 2.0 on April 7th, 2022. Again, Jonathan, thank you so much for coming on the pod today.
Jonathan: [36:07] Thank you, Dan. It's been great to talk to you again.