Subscribe
Share
Share
Embed
A podcast from the ETEN Innovation Lab exploring acceleration in Bible translation. Tune in for experimentation, updates, and conversations about new methods and technologies advancing Scripture accessibility.
Isabella Scarinzi 0:00
Hey, welcome back to the Bible translation innovation podcast, a show brought to you by the E 10 Innovation Lab. My name is Isabella, and I am joined here by my friends clappy and Joel. How are you two doing today?
Joel Matthews 0:19
Doing good. Excited to be back. Yeah.
Klappy 0:22
Doing well, good to have Joe back. Yeah.
Isabella Scarinzi 0:26
We were just chit chatting. If Die Hard is a Christmas movie or not, but I promise that's not going to be the topic of our podcast. Today, we are going to talk about what it actually takes to see change within Bible translation. So since 2021 the lab has been commissioned by e 10 to take risks, and part of that does include testing new methods in Bible translation. I do want to make sure we're framing this conversation. So from the start, we've always worked within the context of the All Access goals, and we want to support the E 10 community as we all work together toward 2033 if you're listening to this podcast, chances are that you're a lab partner, and we've probably worked together before. So something that we have observed across e 10 is that there is a real tension between the need to accelerate where goals are at risk, while also maintaining standards. So today's conversation is about navigating that tension. Jill and claffey will help us think through what innovation genuinely serves the mission and our goals and how to approach change. So I'm going to start with my first question for you guys, what are some of the most common barriers that keep people from adopting new tools or approaches?
Joel Matthews 1:49
Thank you. Isabella, that's that's a great introduction. And really, this is innovation is is the space that we've been commissioned to be thinking through more deliberately, and we are grateful for that opportunity at the lab, and more specifically, for the address languages. This is all the more relevant regarding barriers. I think just thinking about it from the the more broader sense, in the in the in the tech world, you know, any new tech, there's always new technology coming up, and there's, there's this regular tension about, okay, what does this mean for my current work that I'm doing? Does this is this relevant? Is this something I should pay attention to or or keep going? This is not what it really says it can do. I think there is generally the suspicion factor that I would I would say is a is a barrier, because if there is a healthy suspicion to have. I think that is a space for that. But if your suspicion is so strong that that it actually turns you away completely and doesn't let you look into it a little more invest a required time to learn what we're talking about, why is somebody claiming something is good and what it can do, it can leave you, yeah, at a loss of opportunity from gaining something good by just not having paid attention. So I'll stop there. I think that's one barrier I can think of. Yeah, it's great.
Klappy 3:46
Joel, you know, I think one of the biggest barriers is just sometimes people don't see the need for change, right? If things are going well in their minds and everybody's on track, we've been making progress. Things are steadily moving, and nothing's changed in a while. So why should we change now? That type of thinking or barrier is one of good stewardship. You know? It's just the heart of like doing things well doing a making we sure we finished strong, and if that is going to produce a good result on time, then you know, maybe in some cases, there's not a need for innovation. And so the barrier really is just the cost of them changing wouldn't outweigh the benefits of change. And so, if they were to change, what would they gain, if they're almost finished, right? Like, you know, change could introduce, like, all kinds of new processes, new training, new there's these things that they are legitimately weighing in the balance. Sometimes we think, oh, people are resistant to change because. A fear many times it's just good stewardship of well, this is the impact it has for my team, for my project, and they believe we're on track. So why would we introduce change if everything is good?
Joel Matthews 5:18
Yeah, I agree completely with that. It's important to note that we don't expect everybody to just keep changing tools or moving on to the new new thing, new, exciting, shining thing every so often. In fact, that would be detrimental to any consistent goals that you want to achieve, because it'll be distracting, and the training cost is like you clapping mentioned is a very significant portion of a lot of what happens on the field. So anytime anything new is introduced, there's usually accompanying training cost that needs to be accounted for, and that is that is something to grapple with. So it's really applying the benefits that you see from something new into your own context, even as a mental or as a planning exercise to see, is it worth the investment? But it does. It does behoove the the person in charge of making the decision to actually think it through and even maybe experiment with it in a smaller context. So it it'll be a lost opportunity. To not do that. It would, it would definitely not be helpful in the long run, if that is a consistent pattern, to disregard newer things that are coming down the pipeline completely.
Klappy 6:59
Yeah, yeah. And, you know, related to that, there's other concerns, or sometimes they really are fears that if we introduce this new tool to speed things up, will it reduce quality, right? That fear that acceleration always means we can't check the same amount of things, right? In our human capacity, if we were doing everything manually, that may be true, but, you know, not, not getting into the head of ourselves in the conversation. But you know, if we were limited in our technology to what we do, what we've known, what we've seen in the past, it may be a legitimate fear that we need to properly assess, right like, if people have these concerns, are we addressing those concerns as we help them navigate? You know, those barriers, and you know, if there is some sort of failure, who's responsible, if the responsibility of that failure lies on their shoulders, and they're not going to be as eager to jump in and try something new that may fail. And, you know, we've got to help them navigate. How do we minimize those you know, minimize the amount of risk that's impacted? You know, Joe, we've had previous conversations. We talked about minimizing the blast scope, right? So if that failure, if that something does explode, you know, how do we turn that into a learning pivot and increase our how do we actually turn that into a positive experience instead of a fear? So I think that's a good part of the lab stewardship is helping people turn those barriers, especially ones of of fear or concerns, into how we improve the just the overall processes that help govern exploration that we Do at the lab. Yeah.
Joel Matthews 9:00
Yeah. I'll also add one more point, I think, is generally, whenever a tool or a process change is proposed, you want to see some sort of proof or some metrics that show how much and how that change was estimated or calculated. And I think, I think the onus is on the on the person who's proposing the change to actually show those numbers or those metrics or those experiments, rather than expect the person who's who's ideally going to adopt this on for a larger scale, at a larger scale, to to find that number for them. Now this can be more collaborative, of course, but it's important to to note that the. Any good tool developer should do their homework of at least proving to whatever extent they are capable of, even if it is in a smaller scale experiment that there is an improvement that they have measured and are able to state accordingly, and so not having that can be a barrier.
Klappy 10:27
Yeah, and, you know, I know this isn't an episode about AI or how to use AI for coding or whatever, but it's the same type of barrier I have from trusting my AI sometimes, like if I have an AI coding for me, and it just creates something says, Trust me. I know it works. It's like, I know you may be good, you might be getting better, but I can't trust you until you show me the evidence, and so I can see the same type of heart of, you know, yeah, before I invest in this or make the transition myself. I'd like to see that you tested it first, like, where did you test it? What were the results? Where are the outcomes? And if you can validate your validate your assumptions, then, then, let's talk.
Joel Matthews 11:16
Yeah, it's a great example.
Isabella Scarinzi 11:20
So innovation does introduce risk, and there are wise hesitations sometimes, is what I'm hearing from you guys. As part of the lab, we have been given permission, directly from eten, to take risks, but that's not always the case for the teams out there. We actually have a really cool chart that we call the stages of exploration, and that's how we measure whether something is ready to move from just an idea into growth. So the six stages, since you don't have the chart in front of you and you're listening to us talk, they are ideating, incubating, experimenting, developing, utilizing and scaling, and we know that any approach can fail or pause at any stage prior to utilization. So my question is, how do we decide when it's time to actually move something from experimentation into writer adoption, utilization and scaling? Or how do we know when not to do that?
Joel Matthews 12:19
Go ahead, clappy. I'll let you start.
Klappy 12:22
I mean, I, I think there's multiple indicators, but the one that I keep pointing to, and we've we discussed, you know, when we were preparing for this, was really just seeing, have we tested this tool or this new innovation in multiple contexts, right? We did a pilot, right? We did field testing. And usually, by the time we've gotten to that stage that you're discussing Isabella, like it's been field tested, people have looked at it, but it's usually a limited scope of how many people have looked at it, how many teams have tested it, but once we see that it's replicable and it's portable, not just across multiple teams in the same organizations. But does this transcend multiple organizations when they use it, are they seeing similar results? And also, is it portable and usable in other regional contexts? So we want to make sure that the tool, the process of innovation, is ultimately reusable, before we start making the recommendation that we think everybody should be utilizing it. And then we worry about scale. So I think that that is my key indicator of reusability.
Joel Matthews 13:40
Yeah, yeah, I think that's a big one. And learning from a lot of what the startup world has been developing over the past decades, it's really to iterate quickly. And so the process of figuring out if this works beyond just one team or one geography geographical area is basically the act of iterating rapidly over multiple different parameters for the problem. So you can try varying the team size or the location of the teams or the language, of course, and some factors are even beyond the tool itself. There are security concerns or accessibility concerns that actually affect trying certain things out in different regions. So you want to start with where you think this is going to be more successful to actually prove that. But if it is the case, and you do see positive results from there to iterate from that. To a little more broader context, and really that follows along the stages of exploration. What that Isabella just mentioned that the lab follows internally, and we, what I think is it's important that we do this organically, that it's not a forced Of course, there is a drive to make things move forward, but it's not trying to make it happen artificially, because if a thing really works, it should ideally be adopted more organically than trying to have it forced on people's processes or their workflows. And I think that's usually a big indicator to me, that something is helping. It's contributing. It's adding value. You know, in the startup world, they say make things that people want to use, and if that's a, that's a, it sounds trivial. It sounds like an obvious thing, but it's actually valuable to understand that not everything people use is something they want to use. It's probably because they're using it, because they have to, or they've been forced to, or there are other reasons. There is no other way. But if there is a desire for people to use something that's actually very good indicator or signal that there is value being contributed through this thing that people are seeing, and that usually is a good indicator to keep it, keep increasing adoption, and some of it that would happen organically anyway.
Klappy 16:38
Yeah, that's good, because it transitions it from being a push model, where we're trying to push everything out and encouraging and almost, you know, not forcing, but like, if we're begging people to use it, you know, that should be a sign that it's not quite ready. But if you have people pulling and really begging to use it, yeah, Joel, I think that that probably is, like a, not just a success of the tool, but of you know, I would make it a marketing success too, like, makes the marketing, marketing easier.
Joel Matthews 17:10
Yeah, yeah. And I think there is one other dimension to think about that is it's, you might have a great tool, but it not, might not be a market fit at the time. So it may be that the problem you're trying to solve is not everybody's problem at the moment, for whatever reason, but maybe three months down the line, this was going to become big, and everybody's going to ask for it. So there is a market fit aspect also, which is where I think this indicator of, you know, people want to use it does help drive that a little more easily for us to measure, okay, this is, this is what we should be focusing on. And if it's the other way around, if people don't want to use it, then we should try to, like, really ask the hard question, why not? And if that means going back to the drawing board or pivoting, we should do that. We shouldn't be afraid of doing that, because that is how innovation ideally works, is you go back to the drawing board until it is something that actually helps the people and they want to use it.
Klappy 18:18
Yeah, that's really good. You teased out the difference between when we would pause or pivot right if it's basically a timing issue, like people aren't feeling the pain yet. You know how many times we just pause either a new feature, a new tool, and kind of put it on the shelf because it was early in its exploration, it was meeting a need that we could sense people are about to feel. But sometimes you have to wait. Sometimes it's six months, sometimes it's a year, and then when people start feeling that pain, we actually is better time for us to explore that next stage with them, and really, with so many partners across the world, everybody working on yearly funding cycles. There's so many times we got to pause things just because people aren't on the same page. They're not feeling the same pain at the same time they, you know, they have to feel the pain to put it on their schedule, so that, you know, on q2 Oh, we're going to explore this with the lab. So sometimes we just got to pause and wait for that partner to be ready have it on their schedule. Then we start exploring with them. And you know, sometimes it's a it's a waiting game on that, but in the meantime, maybe we can be testing with other partners and and looking for other indicators. In fact, as you were talking, Joel thought of another. Another thing that struck me as almost humorous is a the more mature a product is, and the closer it is to be ready to be used by more partners, the less it does. And it's counterintuitive, like if you ask a founder of a new product before it's built, it does everything, but then by the time it actually is mature and. Have to go in the field. It does one thing well, and a couple other things right, like it knew how to focus and and I think it the maturity of a product really goes from that ideation of I think it should solve everybody's needs, or it's going to do this. And that so many of our projects started with this grand vision, but the successful ones have matured to a point where this is a pain point I'm going to meet in this context, in this constraint, but it's not, more importantly, it knows what constraints it's not going to be good for. Like, do we know is going to be an online only tool, so it's not going to meet the offline context, you know, making that choice and not saying it's going to work on every situation, or this is purposefully going to be an on, sorry, offline, mobile tool, but that may not meet somebody who needs a laptop and constant connectivity. That's going to be a different process for the tools with the different constraints like you, the process actually is shaped by the tools. I mean, it's something you taught me and something you talk about regularly.
Joel Matthews 21:07
Yeah, that's really good. Yeah. As as being involved in products, both you and I, we know that the hard work really is to say no, because there's, there's this constant pull and temptation to keep doing that one more thing that seems easy enough to implement and will help certain set of users, but that, yeah, that, that feeling. I mean, not saying that's a bad thing, but you have to wrestle with that to know, is it? Is it the right decision for the product in the long run. Does it mesh well with the with the vision you have? Yeah, I think clappy one, one of the examples that come to mind when, when we recently tried so we're working currently on fluent actively to develop it to the point that it's useful for the teams in the field. We did some field experiments and field trials late last year, and some some of the feedback we got was unexpected. So the web version that we are currently working on, and we have started work on the mobile, offline mobile version also, but the web version is what we feel trialed, and it one of the major issues or roadblocks that people faced was entering their username and password. So because the people on the field, probably some of them probably didn't have any email addresses that weren't familiar with emails. And so this whole concept of entering, you know, some some random looking string as email, and then entering some random looking string as password was foreign, and they were confused which goes where and how, and even typing, seeing them type was painful with one finger, and so that's kind of made us think, Okay, what do we how do we go forward with this? Does that mean that we just train them to learn about emails and passwords and how to enter that? Probably there is some aspect of that, but it's also forced us to think about, Okay, is there a better way to help authenticate a user on the field, rather than just making them enter random strings, random looking strings, I should say, and make that process a little smoother for them? I know there are apps today like even slack, which is popular, gives you these magic links that let you log in with just a click of a button, without having to enter anything. And now they expect you to have an email inbox to be able to do that. But this kind of pushes us in an innovation area where, how can we think of new things, new ways to authenticate the user on the field, while keeping them safe, without having to be tedious for them.
Klappy 24:11
Yeah, it's just, it's interesting on how something simple like that at the beginning of the use of a tool could make or break the usefulness of it, people are hesitant because they can't even figure out how to get into it. Like, oh yeah, we taught them how to get into it's really difficult, and it's challenging for them. It takes them 20 minutes just to log into your app, right? Like, I mean, it seems like that could be a big impact on the usefulness of the tool, and just how mitigating that that's actually the bottleneck, maybe not some of the later processes, but that can be a huge impact on the adoptability of the tool, making it ready for for utilization. You know, like you had asked Isabella, yeah. Yeah.
Isabella Scarinzi 25:00
So back to the stages of exploration. When we think about utilizing and scaling, we said that a big part of it is dependent on the teams that are actually getting on board and using these methods and approaches. So when teams do decide that they want to innovate in a certain area, what are some practical steps that can help limit risk while still allowing them to try new things. And I'm thinking about this specifically within the context of the All Access goal languages at risk. That's what we've been working towards.
Joel Matthews 25:36
Yeah, this is a great question. It makes me think of different things. Now, wanting to limit risk is something that we all should be actively trying to do in this space of innovation. However, there is an aspect of having a healthy appetite for risk also, so we cannot ever do away risk, then it wouldn't be innovation, or it wouldn't be faith, taking steps to put it more in a Christian term, in terms, I think what we need to do is start small. That's one very practical way to adopt and try new things without failing in a costly way. So if you if you think a tool or a process is promising, why not just start attempting to implement that in one team or with a few individuals, even within a team, and that is still an investment that is still going to cost you some time and effort. However, the amount is much less now zoom that experiment goes Orient, everything was a bad experience. Out of it, what you would have lost is still not very significant. That's the whole point. To keep it very small as an experiment within your context. However, on the flip side, if it goes very well and you've gained something really insightful from that experiment, then suddenly it has the potential to change your your whole portfolio of projects in your organization. So I think limiting risk usually means starting small. And yeah, I think that's one major aspect of how to do that, yeah.
Klappy 27:46
And that's good, because if you do that, then you're able to test it. And it's almost like, you know, if you use the scientific method, right? And usually people with hesitancy or like, have you proven it? One way you can prove it is run your own scientific experiment, right? Like, what's your hypothesis? And I think that's foundational, like, is your hypothesis that this will make your process worse? Because some people, when they approach innovation, their hypothesis is, this is bad, and we're going to prove it's bad. So if that's your hypothesis, you know, it's kind of an indicator of where you're starting from. But if your hypothesis is, is this going to help us increase our speed, increase our quality, you know, and decrease our costs? Like, those are three things that people say. You can only pick two, you know. But as we've talked about in past, past episodes. When we have new technology, like what we've been seeing and witnessing, it is possible to have all three. So having that experiment, you know, a good experiment is run with a control. So you need to have a parallel path, so at the same time where you're running this small scope experiment, where you're testing with a positive hypothesis, right? If you have a negative hypothesis, you're probably just reinforcing things. But you know, have good intentions of collaboration in exploring. Is this good with a parallel path, with a controlled experiment where you're running a B test side by side, and then report your learnings. A good scientific experiment only fails if you don't learn from it like your learnings might be. Well, it didn't work for these reasons, and one of the best things you can do as a partner of the lab, or anybody who's innovating and building tools for you, is to give that feedback. Because what we may not know is there was a new bottleneck in your context that might be the barrier that we could help reduce or remove or work through and pivot slightly or maybe a major pivot. So then that learnings from even a failed experiment, I think are invaluable to. Those who are motivated in innovation?
Joel Matthews 30:05
Yeah, I think that's a great point. The scientific experiment has the methodology. There has a lot for us to follow and learn from. It's a very practical thing we can do on the field.
Isabella Scarinzi 30:22
So we have seen a lot of our partners that have modeled this well, where they're implementing innovation, starting small, and we do want to continue to celebrate those advancements that are happening in our context. Maybe you guys can share a few of those things that we've seen over the last few years.
Joel Matthews 30:43
Yeah, one, one example that comes to my mind is how Jeff Webster from the seed company, has implemented this small process change where he asked the translators on the field to fill up a small form at the end of their day that reports on what they did that day, and it's just a few questions easy to fill. Might just take them a few minutes, but somehow that added step seems to have increased the productivity of the team disproportionately, just by a large percentage, prior to doing that. So it seems like that there. You know, it's one of those counterintuitive things in innovation where it doesn't need to be this extremely technical solution that suddenly solves all problems. It can be small steps, practical steps, and even in your process, and process changes, I think, are like major have major impact on the on the output, even sometimes more than tools themselves. So this, this seems to be one of those examples where they've experimented with it in a small context, and now can have continuing to expand this to more projects, and have seen continuous improvements by introducing that. And I think that's really something to celebrate how they have done this in a more principled manner, and have are reaping the benefits there.
Klappy 32:29
I find that really fascinating and exciting, that just an iterative process change or process improvement can yield such a big result. And to me, that that's really encouraging to hear, is it just reinforces just a sense of ownership and excitement about your work. You know, when you're documenting how far I've come today, and you're tapping into, you know, the motivation of the team, as much as you are technically improving the process like that. Addition has little to do with the actual quality or speed of the translation, but somehow it increased the motivation. Now, you know whether, whether it's motivation, excitement for what I get to report at the end of the day, or a little pressure, you know, my keeping up with everybody. And, you know, I think by measuring that, you know, it does reflect and help you think about, Okay, now what, what's the overall progress? Are we on track? And it helps tie in, you know, just a sense of pace that I think we focus on a lot at the lab, and I know, at this, at this level, but on the field, you know, sometimes they're, you know, appropriately, more concerned about how they translate scripture, not necessarily, of what is the date I'm going to be finished. Yeah, that's, that's, that's really good. I'm glad to share that.
Isabella Scarinzi 33:56
Joel clappy, I also have heard you talking about the partnership of spoken and how you guys were putting AI and laptops and sending that out.
Klappy 34:09
Yeah, yeah, that's a good example of like, pausing and restarting and, you know, pulling something off the shelf in dusting it off and pivoting right? You're talking about, when is something going to be ready, and how do we move through the stages of exploration, you know, Ed, Ed Weaver from spoken, you know, he has these big ideas, and then we assess whether or not we feel like they're worth investing in. And we had this opportunity for Daniel Wilson from XRi to help build this laptop that does this multimodal AI, in data retrieval, like this, very complex processing, all on this laptop, things that are, you know, at the time, only positive. Online on the internet, and even then, we hadn't even plumbed all the pieces together on servers. And so we had this experiment. Hey, if we limit the scope of it, can we fund an experiment where you pack a laptop with with all these good quality resources we trust, and then have a large language model sitting on top of that that can fetch and retrieve it to answer questions on the field, but we want to test it offline. And even more difficult was like, okay, these people don't know how to type. You know this. This is actually an oral culture, like they know a language of wider communication. So we can do it in French, or we can do it in, you know, these other major languages, for them to actually ask biblical questions and then let it respond not from its knowledge that it's already been trained with, but out of resources that We trust. And so that experiment was both a success and a failure, right? And that failure was great learnings for us in there's a few things that we learned. The first thing was, yes, you can do everything we said, but it's really difficult, really expensive, and it takes a long time to get that all set up on a laptop and then ship it off, deploy it. And does a laptop even run in the temperatures of some of these countries? Like managing that laptop is actually a very difficult thing to do, so with those challenges of cost and time and limitations, we had to put a pause on it from 2023 and then now, you know, thinking and had a gap. We had unfolding word come to us with with an idea for having the same type of underpinnings, but they expose it on mobile devices through WhatsApp. And, you know, we've already had our WhatsApp episode, you know, a couple of months ago. But being able to have the same need met, but we learned on the device and the situation there, we paused, we pivoted, and we're able to take a new approach and actually able to deliver something over WhatsApp. And you know, in that episode, we talked about whatsapp on how that does meet a lot of needs, much further needs, then maybe even a laptop that works offline. And sometimes that's counterintuitive, like you're thinking it's offline, how can it not meet everybody's need? But sometimes you meet more needs with dancing around those constraints. And you know, Ed from spoken has been a great partner, because he's, he was, he had a big appetite for risk. He's like, let's take this risk. And we learned from these the feedback from the field is you need to actually have some training. You can't just drop some an AI assisted tool in somebody's lap that's never seen AI before, and just say, ask it questions. Because, you know, there's some training involved in that, and we had a lot of iterative learning in that process. And now we're on the other end of it, two years later, actually, goodness, two and a half years later, really, at the point to where BT servant, which is coming from that early learning, is now turning into something that is almost to that point once we see it replicated across more of our partners and them testing, they're at the point of testing, so we can say it's ready For utilization.
Joel Matthews 38:39
One One practical thing to do would be finding good matches of projects to experiment. And what I mean by that is there are some projects, when you look at it from the at risk lens, that are on pace and seem to be on track to complete their goals, you know, from what we're concerned and especially at the lab for the 2033 goals, but there are certain other projects that are actually lagging behind, And I think it's it's good to first focus on, on, on those projects that you expect, that you already know are not on track, or there is something that needs to change without which Things will not be achieved by 2033 so finding the the I think your appetite for risk should be larger for those projects that already require some intervention. And the second dimension to look at it is even from more practical point of. View of is, what stage is this project in? Are they really just starting out? Is everybody so new that, you know, experimenting something up front will just disorient them from the work itself? Is there a way to maybe even pull one or two people out without sabotaging the whole project for running an experiment. So those are other considerations. Of course, there's a security and there is also accessibility concerns that you would have for any of these projects that you would try to experiment with. But those are practical things to look at among your project portfolios, a portfolio to decide which projects may be more ripe for experimentation as compared to others.
Klappy 40:42
Yeah, that's great. Joel in think sometimes it's not just the projects but the people right like it. There's nothing wrong with different people having a different appetite for risk, but you may have people on your team that are more open to change and more open to trying new things than other people. They have a higher risk appetite, and I think that's a good indicator of like who you would have a better chance of succeeding with. You know, if somebody is resistant to change, most likely, there's a predetermined outcome already. So I think as much as picking the right project, picking the right team lead or whoever, whoever in your organization, in your process, whether it's a translation consultant or consultant in training, or, you know, trainer, or however you manage those projects, Having having the right people who are motivated and have a reason to try something new, to to see something speed up to increase in quality, speed and lower cost.
Isabella Scarinzi 41:55
Yeah, that's great. This has been a great conversation. Thank you for listening. And today, our focus in 2026 is on the All Access goal languages at risk. And if you want to help us advance any of the specific languages that are at risk, we would love to partner with you. There's always an open invitation for participation. We're also going to start a Bible translation innovation question time on this podcast. So if you have specific questions and you'd like us to address on the show, you can either send send an email to us at lab, at eaten dot Bible. We're also going to include a link on the show notes, and you can just record an audio message. So we're excited. If you have any questions, send them our way. Don't forget to subscribe to the show, and we are going to see you at the next episode. Thank you. Thank you.
Theophany Media Media 42:53
The Bible translation innovation podcast is brought to you by the E 10 Innovation Lab. This episode is edited and produced by Jake dobrins With Theophany media. Your hosts were Joel Matthew and Christopher Clapp, with facilitation by Isabella scarenzi, please subscribe on your favorite podcast platform, and we'll be with you again next month.