Latest / Rethink Engineering / Scaling AI Enablement: How Odevo Upskilled Engineering

Transcript

Scaling AI Enablement: How Odevo Upskilled Engineering · Rethink Engineering

• Deejay: This is the Waves of Innovation podcast and I'm DJ your host today. I am talking to Tomasz Maj who is head of product operations at a company called Odevo We'll be talking about Odevo's upskilling, enablement and training journey on AI native practices for engineers, product folks and beyond. Tomasz has a home office that is cavernous. So there might be a bit of reverb on his voice. Just imagine we're having a conversation in a cathedral or something picturesque like that. Hello, Tomasz Maj. In fact, I've never asked, I don't think, how to authentically pronounce your surname in the Polish style. So for our non-Polish listeners, how is your name pronounced? As always, I hope that you enjoyed our conversation. Tomasz is a force of nature, very energetic and enthusiastic gentleman. I do warn you, if he takes you out drinking, like, don't be surprised if it ends in Jägermeister at midnight. I may have made that mistake once or twice myself. ⁓ yes, I did talk about AI native DevCon London discount codes. So if you use the discount code RECINQ30 that is R-E-C-I-N-Q-3-0. ⁓ Tomasz: Maj Deejay: Tom, Tom, my, is yeah, my very different to what I was expecting. Cool. So ⁓ have learned something already straight in the first few seconds of the podcast. You work for Odevo, ⁓ a third largest tech company. Now you've got Spotify and ⁓ okay, largest private tech company. And like in terms of Swedish tech companies, you've got Spotify and you've got Klarna who everybody's heard of. And then there's Odevo Tomasz: My Deejay: at https://tessl.io/devcon/ then you should be able to get yourself 30% off a lovely ticket for both days of activities there including a talk from Tomasz and I going into more detail and more of the statistics ⁓ on their native transformation journey. In the meantime, if you have any feedback, please send it to wavesofinnovation@re-cinq.com that is R E dash C I N Q dot com ⁓ and be good to each other you'll hear me. Tomasz and I will be talking at a number of conferences in the near future, one of which is AI Native DevCon London. And if you listen all the way through to the end, we'll have a discount code for 30% off tickets to AI Native DevCon London. So do make sure you hang around till the end for that. In the meantime, do whatever it is you're doing at the moment, whether that's running, walking, sitting at your desk, driving, trying to get sleep at night and enjoy. Tomasz: Private tech company, private tech company. Deejay: ⁓ So what do Odevo do? Tomasz: Yeah, mean, number one is lovable. we're like, we're in a nice ⁓ right? ⁓ yeah, what does Odevo do? Odevo is ⁓ in the property management. So if you're living in an apartment building or in a housing association, ⁓ we manage that. We manage residential properties, right? Residential properties are the largest asset class in the world, right? Everyone has a residential property. ⁓ Deejay: you in the next one. Tomasz: It's a big deal and also residential properties usually is one of the hardest and most important decisions you make in your life. Buying a house or you know moving into an apartment or anything like that. So it's it is a big deal right. And what we do is we we are we are a collection of companies a group of companies now quite large footprint across where we started in Sweden. We then moved to ⁓ England or United Kingdom and we're now also in Finland, United States, ⁓ Germany, Spain, Mexico, Italy, Portugal. So we are growing, right? And we are building a of a collection of operating companies which we call Opco's. And of course their technology is there and plays a big part. So Odevo in short is a collection of operating companies where We have something we call SureServices that supports them with one of the main things we support them with is technology or applications, tech solutions. And I work as head of products, which is a function about bringing our engineers, our product people, our opcos together to build cool products, cool technology. Deejay: And so the software that you build is about all of the kind of things that a property management company might need to do, Of like, I don't know, repairing HVAC systems and processing payments or subscriptions or whatever for ground rent and service charges. Is that the kind of thing that your software offers to companies? Tomasz: Yeah, we say we, So I think we always divide our tech into, let's three major parts. It's ⁓ customer management. So everything on like a self-service portal where you can raise a ticket, you can see your invoice, you can pay your invoice, right? So anything around managing your relation. You as a ⁓ customer of which is a person, either ⁓ a housing association. or a housing board, which is our typical, or also residents, right? So we have, we consider that we have our financial management. which is everything around accounting, right? I mean, these finance, the real cool, the real cool thing about property management is that most of these companies are managed by people who are volunteers, right? They're not, they don't have a financial background and we, we provide a service for them to help them manage their finances. I really think that's something not to be undervalued. We are helping people who sometimes don't even get paid for it manage a lot of valuable things with sometimes quite big budgets for these properties. So we provide financial management ⁓ as a service. And third, it's asset management, which you described. An HVAC is broken or an elevator doesn't work. That's asset management, we call it. So that's a collection of all the assets that companies or buildings have also paired with repairs and maintenance, fire safety, which is a very big thing in the United Kingdom, as you know. And, or in the States, it's all about elevators and just properly managing all the assets on things. So we divide our products into those three sort of distinct categories. Deejay: It's a. And it's a big kind of like invisible category of software really, when you think about it in that like most of us either do or have lived somewhere with a property management company. And like you said, some people are volunteers, so they're not getting paid when you end up living somewhere where you've kind of got to pay one of these companies, you know, it's always like, well, why am I paying this company? What are they doing for me? So you want to get value out of it, but also the value that they can provide. you know, in having like good facilities and, ⁓ you know, where I am, there's a like playground for the kids, you know, kind of a few hundred meters away and you want that to be in good condition. You want it to be looked well after. ⁓ and if you've got like either chaotic processes or terrible software or financial ineptitude, like everybody suffers from that a little bit. So like by having, ⁓ those things running well and being kind of digital native, ⁓ then. ⁓ Hopefully everybody that's living in one of those situations can have a slightly better experience of life. Tomasz: Yeah, but it's also things like you forgot to pay your utilities bill because you might have had other things on your own. We help with that. Or you didn't remember that your elevator needs your annual check. These are things that are easily missed. And I think our job is to help. I mean, it might sound cheesy because I work for the company, but I do feel like we are helping. We are helping people that This is not their day job to be successful in it. And I feel it's an important mission in a way, right? And so it feels good to when you hear like, hey, thanks for doing this or thank you for helping me. This solution is really good. This is easy. This makes my life easier. think it's a ⁓ very positive feeling. Deejay: Yeah, it's always nice to have happy customers and know that your work is benefiting someone. So that's what Adevvo does at Broadstroke. And you've been going on quite the AI journey. So my colleagues at Resync and I have been helping you with parts of that. But if we wind the clock back to before we met, maybe last summer, around about that time, do you want to take us through the kind of journey that Adevvo's been on? Because I think without too many spoilers, like the breadth places that AI is touching inside Odevo and the kind knock on effects are really quite interesting. And I think you folks are probably ⁓ quite ahead the curve. So the journey that you've been on is going to be instructive for everybody else ⁓ going on catching the wave slightly later. So ⁓ yeah, take from the top. Tomasz: I mean, I joined in August 2024 and already then when I joined, we had an internal AI team. This AI team's job wasn't to build AI or help AI for engineers. It was to create AI solutions for our operating companies. It's important to understand that many of these operating companies are still pen and paper, right? Or they're not very digitized. Digitized in this case can be a Google Sheets, right? a word document or stuff like that. And that's where you manage a company, right? So of course, depends on market. Some markets are much more digitized and much more ahead on that journey while others are much behind. It really depends on the market, which is also super cool about this industry is that no market is the same. But we had an AI team that's been building a lot of things to help our operating companies like document sorters. I mean, if you're in the UK, you know that some of these lease agreements go back 100 years, right? And now you want to understand, can I have a pet in this apartment? And the lease agreement is 100 years old and it's written in very complicated English or no one knows where it is. So we're helping stuff like that, like easy to take documents and then make the search through those documents or analysis of those documents easier, right? So that... onboarding process, all these things to help our operating companies make their life easier. Right. So that was something we had ongoing and was internal. also built our own internal GPT, which we call a Divo GPT, which was sort of roll out a, Hey, how about because we have a lot of private personal data. So we don't want that to be going out and being used to train models. So we build our own Divo GPT where people could feel safe to process. ⁓ PII data, right? So that was ongoing and our engineers, you know, we're doing things. mean, we're also very, we have multiple products in multiple countries. We do not have a core central system on anything, right? Because all the countries are very different when it comes to legislation, when it comes to use cases and it's a death by a thousand cuts. From a very high level picture, you're like, hey, It's always the same thing. This business is the same. But then you go into the details like in Sweden, the BRFs or the housing institutions have one bank account. You go to Finland, they can have up to 10. You go somewhere else, they have to have two. It's like from the high level, they all look the same. But once you go into the NTT details, you can easily fall into the death by a thousand cuts because then it's a customization here, here, here, here, here. And that makes... No sense. So we really just thinking about where it makes sense. It does, but we are not sort of trying. The goal is not to bring everyone onto a core platform. But so we were building, like, you know, we had, we had multiple teams doing building different, different products for different markets. And I think, you know, they were playing around with, with GitHub co-pilot that was sort of, we did it and our AI team would always enable the newest models. ⁓ but everyone was feeling like Something happened in the beginning of 2025. I remember a Slack discussion. ⁓ When I joined, we got on Slack. can't be a tech company without Slack, ⁓ I remember a Slack discussion around, what about AI to boost engineering productivity? Like, hey, this is an interesting topic. We had a bit of back and forth. We discussed it. We're like, yeah, but is it really, first things started coming out. Deejay: Yeah. Tomasz: Then Cloud Code or Cloud and Anthropix launched it. We're still, it was skeptic. And then over the summer we said, come on, it's no, it is. We are seeing game change. We're seeing, and those that are using, there was some sort of small pilot groups of people using Cloud Code or other tools. is, it's still not great, but it is different. It does things differently. You build things differently. It's a different experience. So we sat down and we said, let's do it. And I created with AI, I always said that to an RFP for an AI training. we got inspired by AI training for engineers, I think we called it. And we outlined like what we believe, what are some different styles of using AI. Like we had, know, vibe coding, agentical, those terms were already floating around. So we had those. Um, prototyping, all these things where I think we made a decision to remove prototyping from our AI for engineers to focus more on that journey from writing it using a chat interface all the way to agenda. And we played that out and we, and then we asked around and we sent it to a couple of companies. I made the mistake of posting a LinkedIn post asking, Hey, I'm looking for companies to do AI training. I got a lot of 15 year olds telling me they have 15 years of experience in agentic development. Deejay: You Tomasz: That wasn't what I was expecting, but I got like 40 people knocking on my inbox. yeah, we sent it out. We sent it out to those that we felt like, they were. I mean, I remember we had a bit of email exchanges and then we met. And I think from that, that's where it started. I think that that feeling of we have nothing to lose. We should set out on RFP because... It is something is different. can't put your you can't put your finger on it, but it feels different. there was this like this smell in the air, you know, was and it's and we have to do something. We have to be bold about it because we can't just think it will happen naturally because we all we had a small group of people. We all believe that AI adoption is super difficult and we really wanted to guide it. We wanted to provide some sort of a a structured way of going from zero to hero of providing a guided path towards it because we knew it's very easy you can misinterpret or your bad practices will get worse. So we really wanted someone that would guide our engineers and we really wanted this to be engineers for engineers, right? So not a training company that would have a, here it is. This is what, this always works. Here's our PowerPoint. No, we wanted to feel make it genuine because as you know, you're an engineer, the best that they BS, you know, they will smell it and they will feel it. This person doesn't know what they're talking about. So, but yeah, it was mostly about that. It was about this pace of change and the AI team who has been quite on the forefront of this also felt like they could unlock more if they got it in a structure. So it was a general consensus that this is good ⁓ idea. Deejay: Yeah, the I think one of the things you mentioned that is really interesting to me is the sense of it being different, not just that here's a new thing, we should learn it, but like the rules of the game might be changing, therefore we need to be ready to adapt. ⁓ It's that kind of disruptive change, I think is the signal for folks to do something different in response to something that's different. And the engineers that you you've got ⁓ at the time, there was a really widespread, wasn't there? I mean, you mentioned you had an AI team, which a lot of people didn't have and don't have right now. And then, you know, through to your kind of AI enthusiasts, people who are kind of, nah, could take it or leave it all the way to a few people that were quite AI skeptical for various, quite valid reasons. So there was quite a broad spread. ⁓ Do you remember what the mood was like amongst the development community in the organization when that ⁓ training and enablement program first kicked off when they first got to hear about it. Tomasz: I think like I would say most of them were excited to go to a trading, right? And that wasn't a learning platform that you have to self pace yourself and learn that it would be structured. It would be an intense journey, right? That ⁓ you're have a person is gonna take you on this journey to go from very basic to agentic. We had that. Even then when we created a RFP in August, we already knew we should do something around agentic. We of course had a crystal ball and we knew it was going to be the next big thing in February 2026, right? But no, just, I think it's one of those, the mood in the organization was positive. They were like, ⁓ let's go, let's see it. Of course we had, you can, we can, we had some outliers, of course. Some people they're like, engineering writing software is a craft. I don't believe in this. This goes against what I've. what I believe or what I've spent ⁓ decades ⁓ building as a craft. So those were quite skeptic, although they did say, okay, but I'm gonna give this training a try. Deejay: Yeah, and then so we went on working together to do a few different things. Luckily, you insisted on a pilot cohort. So we learned lots of things by having just 20 % of folks go through that, one of which was that dev containers are a massive pain in the backside and are really hard to configure. ⁓ Definitely acutely learned that in the first set of exercises that we did with your folks. ⁓ And then kind of rolled out to a larger group. Tomasz: Yeah. Deejay: And we did lots of workshops at the beginning to ask people how they felt about things and the ways they thought it might go wrong. Um, we deliberately kind of paste it out a week or two weeks apart. I think we started with two weeks, didn't we each module, and then we kind of collapsed it and then compressed it to, to, to, to one week each to get the, to keep the pace up. So people had the chance to take it home and, or not take it home, to kind of take it back to their desk and see how it worked. Tomasz: Yeah, we did bi-weekly, right? That was, yeah. Yeah, we started with bi-weekly. Deejay: And just on the subject of kind of skeptics, I think it's a question I get asked a lot now of like, how do you change the minds of people that are quite against this stuff? I think one, making sure they're listened to as we did in those workshops, but also just allowing people to see what the tools can do is probably the most convincing thing of that. distinctly remember a couple of folks who were very reasonable, but they were like, I don't think this is any good. I don't think it's the code that it's going to create is good enough. But then once that actually spends a couple of hours going through an exercise with Claude code, they were like, ⁓ wow, this, this can do more than I thought it could. Tomasz: Yeah. Yeah. I, I think that that was a general feeling. Even the ones that were very good or they've been using it, let's say they were, they were already heavy users of also Claude code. mean, we had several people that have been using it since September, August, September. Yet they're there and they still felt, ah, it's like, it's okay. does like, it does gives you, takes you 60%, 70 % of the way, but still being an engineer. is required. You need to understand the code. need to you still need to be there. But yeah, I think that was it. Like, first of all was that it wasn't a self paced course. So you saw colleagues, right? ⁓ What you weren't like going on this alone in a vacuum. You had other colleagues saying, ⁓ wow, look at that. ⁓ that's super cool. I did this. Have you tried this? And they're like, ⁓ it's not only it's not me, myself and I it's others and they are and they are sharing I think also being you and Michael who were there running the session from RISING, you know, both saying, we're engineers. We are, we've been doing, we have combined like a hundred years of experience. This is of course talking about Michael's age, which we shouldn't, but I mean, you have a lot of experience, you've done this. I mean, I think it also helped that you show that you are engineers as well and you've seen the good, the bad and the ugly. You've tried, you've played with it. I think, I mean, one of the cool things around it, Deejay: you Tomasz: you said around the pilot cohort was like, sometimes things would not work. And that made it actually more genuine. Rather than if it's perfect, it's all just everything works, I think would have made it feel like it's fake. But showing that, hey, this is something we didn't work, we're learning, let's fix it together. I think you even fix some of these things during the actual training, just to show that it's real. And you highlighted, I built everything with AI to build Deejay: Yep. Tomasz: these materials, these things, and look what's happening. That made it also more genuine, I think, for all the participants. But I think it was three things, really. First of all, we insisted that every kickoff, or we called it the foundation module, was always in person, right? So we said that you're required to be there in person in the first one day, see people, have interactions, also, you know, feel that, okay. These are all real humans. This is not another team's call. I think that helped. Second, we made sure we mixed it, right? So we had people with different tech stacks. mean, at Odevo, we have multiple tech stacks. We don't have a single tech stack that has both pluses and minuses. I think that's a separate episode if we were for discussing that, we had separate, we had that also we made sure that we had varied experience with AI and that diversity. made it also that they could follow on someone or when they asked the silly question, they were like, okay, it's not a silly question, right? So we had that. in one, I remember till this day in the first cohort, you have a guy that's been writing ⁓ research papers on AI before he joined the UN, he's like, but no, scientifically you're wrong. And you're like, I know, because I'm not a scientist. So those interactions also made it real, right? And then I think, I think third, it was the pace. This was intense. Even the two week, every two weeks, jumping to a next level around working with AI, it wasn't intense pace. It wasn't sort of a fluffy seven months, every month we meet. It was every two weeks. And then with the second, with the bigger sort of launch, it was every week. And I think that also made it that people... You know, they were able to, they had to, couldn't forget that you had to practices and then the pace also helps. Some people of course missed a session or two. mean, it's, is a lot, but I still think for majority of the group, the pace was good. helped them stay, make it like, make this real and, and not sort of make it, you know, forget about it or, or lose, lose focus. think those were, were all success factors around the training. Deejay: Yeah. And I mean, the, we, we've got other kind of potential customers we're talking to at the moment who want training, but like collapse down into three days. And it's like, okay, we can deliver it, but whether your folks are going to have the time to reflect on it between each module and kind of absorb it and take it on as their own. I, I, I don't think it will be as successful kind of collapsing it down into three days straight intense because it's, it's different. Like if we, were learning Kubernetes or Docker, it's like, there's a load of knowledge. Tomasz: Exactly. Deejay: like facts that you need to remember. But this is about changing the way that you do things, your behaviors and what you believe, you know, it's a different beast. Tomasz: And I think it's digesting it, right? I mean, I'm not an engineer, but I mean, I'm on the hype frame, baby. I'm like, I got to open clone my mini Mac and doing all that. I'm on. And I think it's sort of you read about something now, like harnesses and all this, like you read it, you hear someone talk about it. People process information in different ways. Some people will be like, aha, aha, got it. I'm going to go and do it. Some people are like, wait, I need to do a bit more research. I need to... Deejay: You Tomasz: put it in my own words, I need to see how this relates. I think that was also giving that sort of one week to digest it. Also, we made sure you were on Slack. We created Slack channels for each group that they could ask questions. They should share their wins and their losses. We also made it, hey, just share what you did. If it didn't work, it's okay. Like we created that space. But I think, you know, made it, made that. But yeah, I think having a three day workshop to go from through all that without that moment of reflection, without that moment of giving people some time to process this because this is, might, I everyone feels like this is now obvious or you can just Google it. No, but then applying that is not as easy. And I think another one thing that really worked well in the first cohort less, but in the following, we brought people from the first pilot cohort, which I call the Polish independence. they cohort because it was launched on 11th of November, which is Polish independent day. Here you go. You now learn two things about Poland during this podcast. I think we had a couple of guys in there who were like, yeah, I mean, this is so cool. I want to share this with the world. So we then brought them as co-facilitators, right? To run the sessions. We also made it very explicit in the RFP that we want to have a train the trainer module there where you will help and transfer knowledge. Deejay: You You Tomasz: and all the knowledge around the training, how to run it, what materials into our own internal, into our internal trainer. So we have people in our organization who can then run this training in the future, right? So I think that also made it, it show that it's, this is not another one of those. This is something that is big and we are fully, we're investing all the time, effort and resources into making this a success. So all those things, plus I think having the CTO. join each group and share a bit about how he sees the world and how it will change. Also just legitimize it even more and show that this isn't a cool, this isn't a training that you know you can, that just happens. This is a part of a transformational journey that we are heading towards. Deejay: And speaking of transformation, before we get onto things like the impact on products and the rest of the organization, I probably shouldn't drop this on you. Do you have any of the like, how did development change over the course of things? mean, I think I've got some stats over on my right hand screen about like a number of PRs increasing and stuff like that. But generally you've seen positive effects, Tomasz: I think everyone started using, we have 100 % of engineers that went through the training are now using AI in their day-to-day job. Some less, some more, some heavy users, some less, but everyone is doing it. I think it's a massive, everyone is using it. I think also, mean, we saw that the ones that were like already highly productive in a way, let's say number of PRs, they are now doing 10X and generally 10X measured by number of PRs pre post-training 1000 % more. And it's also because of the frequency, easiness of it. ⁓ think another thing that was I think very cool outcome, it's not you can measure by numbers, the curiosity increased. People are like, What's the Ralph Wiggum loops? ⁓ I want to get into that or, I want to follow more people. want to see I'm interested in what are the things. Sure, Claude is great. Hey, what is OpenAI doing with Codex? they're generally getting interested in the topic rather than just enjoying the ride and waiting until somebody brings them something. They are generally challenging and think about how the world is changing and want to change it themselves, right? I think another one is that at least we have several of our strongest engineers saying, haven't touched, I haven't written code like I have before the training. I don't, I use, I now rely heavily or fully on AI. Of course I still check what I do. mean, they, I mean, they're not, it's not, they're not blinded by it. Deejay: Yeah. Tomasz: because one of the important modules that we did was the foundation module, which was very basic, but setting a baseline. Here is what good looks like, here is what bad looks like. Here are practices. No matter how experienced you are, you should follow these. We said that as a baseline. I think that's very important because a lot of people want to jump right into the hardest piece. No, we paste it on purpose to set the baseline and... ⁓ Bring the people that are high-performance to be guides while the lower, the people that haven't really adopted yet, that also helped. First PR speed, I think across all repos, is day or less. We had sometimes a lot. I think the option to experiment and do one-shots has massive significance. People try it. They see what happens if I one-shot something. Of course, number of PRs has dramatically, I think the smallest increases is 3x. Well, the largest, like I said, is 10x. So we're seeing all of that. But also I think customers are seeing that the response time to their request is much faster. And we're also bolder in what we do. I think that has made it like, instead of saying this can be done, we're saying, let's try and see, rather than no. This could never work. Deejay: Yeah. And I think one of the things that is encouraging about your example is that not only have the number of PRs raised gone up massively, the time to merge has gone down, you know, from the stats that I've seen across the board and quite significantly, by time going down to merge by 50 % is a typical case, not an outlier. And the size of PRs as well, down a little bit, which is good. I've seen in some other places, PRs not only the volume of PRs, but the size of them go up, which is a bit of an anti-packing that people are just like, ⁓ I'm to use AI to change a million things all at once, which kind of speaks to the importance of good development practice underneath all of this. And there is a kind of tipping point of good software delivery practice where if you're on the wrong side, AI is probably going to make you worse. Tomasz: Absolutely. Absolutely. Yes, and I think that the message around, guys, unit tests are important. Hey guys, testing your code or writing documentation is now, it's not a discussion anymore. It's like, I don't want to do it. It's beyond me. No, it's like, I'll just do it. It's like, poof, poof, and it's done. doesn't, it's not a painful process, right? So people are more open to doing the more tedious types of work. And the great thing is, Claw, Codex, whatever to you, it's not gonna say, I don't feel like doing it. Like, aye aye, Captain, here it is, here's another one, here's another one. ⁓ you want more, okay, you want me to merge it, unmerge it, yeah, yeah, sure. Add pages, all that. So I think that that was a massive embrace as well, right? I mean, there is a lot of, I think also the whole, like a lot of activities were not even around using AI, it was just around, would you, if you could, would you do that? Deejay: You Tomasz: If I mean, before I understand, like we use these terms with all the training saying, like, imagine, imagine you would you, would you trust, uh, would you trust a five year old with this? No. And why would you trust AI? But on the other hand, if you really shape it and grow this five year old to be a, a 25 year old junior developer with your guidance, you can build great things together. Right? So some of those things make them people aware. of practices and things like that was also sort of an unintended part of the training. And I think that that's also a big, so sure, we can look at stats and I think they are, they're pretty cool and it's great. But I think the hearts and minds element of it was a bigger change for me and looking at our engineers now. Deejay: And you mentioned ⁓ increased boldness. That's a really encouraging thing to hear. I remember hearing about a mobile app that had been on the back burner for very long time and then got delivered in short order. Is there much more of a story to that? Tomasz: Oh, I don't think it was delivered, but what happened is like one of our engineers said, I'm going to try, I'm going to try to build. Can I, can I take it and on a react front end, can I set up an app and build it? And he tried, he, he took like two days, it get to a good place where it is possible, but it still requires a bit of work. But we show that, you know, this thinking of zero. Like the first step, that first step to try is now pretty much everyone will do it. I mean, of course, maybe generalizing what most people will do, take the leap, say, hey, let me try doing it. I mean, we in this organization are taking more leaps. saying, I mean, we're thinking about rewriting applications, right? Why not? We're saying we don't need to do a two month discovery window on which architecture to use. Let's try something that makes sense right now. And if we need to change in the future, that's okay. Because these are the more, these are these bold moves that we're seeing more and more. People are building productivity apps for themselves because they feel like, hey, this would be really good. And then before they would probably look, you know, a build or buy. No, I mean, I spend an evening with Claude Code. And I have an app that can do this or that. So I think we see that. And the cool thing is we are really emphasizing the element of sharing. If you build something cool, talk about it. Don't store it. We've organized what we call these monthly tech connects, where it's not about work. It's about what hobby or what side thing you're building to show, here is what I did with AI. And we've had You know, we've had a designer show how he's building a skill in Cloud to follow our design process, right? To someone building using OpenClaw, a Roblox Claw, right? So it's also just to show that, hey, it's not only work, work, work. AI can also be something you can use as a fund. cool. It's possible. Look at the possibilities, right? So yeah. Yeah, but yeah, the boldness thing I think is a cool metric to measure in any organization after any type of AI transformation. Are you still stuck in that we have to go through the, like we have to stick to this very clear, straight process and we have to ask for permission? Or you'll go like, hey, let's try guys, let's try. What's worst thing can happen? I'll lose a day. Like I think that's, that is a metric that's unmeasurable, but I think it's a mindset that Deejay: Before we get on... Tomasz: that you know you're doing well if you're seeing more of those types of things happen. Deejay: Yeah, allowing that creativity. And before we get onto the kind of product folks and people making ⁓ non-software developers kind of starting to create things, ⁓ just on the subject of the barrier of entry being so much lower now that agentic coding is a thing, how are you feeling that as a business in terms of creating, I mean, software as service in particular seems to be quite vulnerable and threatened by this because somebody can just point to Claude. instance at somebody else's software and go, Hey, make me a thing that does this. But with all the features I want, and none of those like generic features for all those other users that I don't care about. How is that impacting a dev? kind of the most broad scale. Tomasz: On the broad scale, it isn't because we're still, it's a property management is still a very human business, right? You build a trust, you build a report with your property manager, whoever that is. ⁓ We are, of course, we are aware of it. So we are thinking about what's next. Like what will be the future? And this goes to the boldness. We're not saying like, nah, nothing is changing. We're saying. It is massively changing. Let's explore ideas and let's be bold about them. Let's not be afraid to fail that it will have massive implications or will have negative impact on our financials because we can't really, you know, guardrail and experiment and within a month know and let's try it. Let's find people that want to do this and let's try. So, yeah. I think it will massively impact the industry in next two years. It will change. But we're not just sitting idle. We're not sitting on our hands and saying, yeah, we got it. Don't worry. It's not changing. Which I think some companies, some industries are. And that's scary in a way. Deejay: Yeah. Yeah, there are still people out there who are like, ⁓ it'll all blow over. This is, you know, especially with, you know, kind of conflating things like the economics of it all. And I went to bubble AI is going to go away. Not I wouldn't be so certain of that. Tomasz: I don't think so. I don't think so, no. Deejay: So, yeah, let's talk about non-software developers making things and creating solutions. So I guess maybe there's like two categories that I'm aware of the things that are going on at Evo. One is software being created by non-developers and then there's AI being used by non-developers for non-development purposes. like whilst we were working together on the training, I remember a few of your folks being responsible for like, hey, there are all these lovable apps turning up. and I need to do code review for them and make sure that they're safe. And people were excited. Like it wasn't like it was a chore and a burden. It was like, this is, this is cool. People are starting to like make solutions to tactical business problems. So what's going on in that space of like non developers creating new apps and things. Tomasz: It's even more massive now. think everyone is on the no code or little code or vibe coding the multiple names. I mean, we jumped, we're a Swedish company, so we support our Swedish colleagues in Lovable. So we are using a lot of Lovable. But we are not putting red tape on it and saying, okay. Whereas I like here is you have to complete a 10 minute training that I built in lovable about lovable, right? where you have to understand here is what type of data you should not be processing in lovable. You should not use sensitive data, right? You should be careful with things. Would you send it to a vendor? No, then don't send it into lovable, right? Like these are the things, types of things you should just be more cautious about, right? And we're also, we do a lot of due diligence on What and how are what tools where is it stored right like we when we were signing a deal or we're talking with love was like hey We need to make sure that whenever we somebody builds an app within a divo. It's always hosted in you, right? So make sure it's hosting you so we've they helped us to make that happen right they ensure us it happens, right? So it's not about red tape. It's about understanding and and And yeah go explore See the limits. mean everyone will come to a place where like whoa, this is way too much for me to handle. Now I'm getting requests from 15 people like this guy. yes, explore, find your limits and then let's talk. Once you reach that limit, let's talk how we can, how maybe we can help make it an internal tool or give you someone that can coach you a bit on how to stabilize it so it's good enough and then you can just use it as a normal application. Or maybe we move it in-house. We are looking at multiple options, right? And I think the number one thing we didn't go with a sort of stop here is like red tape, red tape, guardrails, guardrails, rules, rules, rules. Because then that's the best way to just kill innovation, kill product thinking. So we really were about that. And we've seen a huge uptake. And people are just trying things out. It's not about, Some people are just building like random things, personal apps of tracking expenses, right? I mean, they could do that in Excel, but lovable is cooler because you can add icons and you can add animation when you add something, right? Others are taking huge, like massive Excel models that they have now been maintaining, throwing that into lovable to build an app from a model and much easier to maintain, much better on user, much easier user interface. And then you can add... graphs and analytics because it will just build it because it uses like the most power like it uses Claude I think 4.7 now so it ⁓ is a game so we are seeing that and we're also seeing it with engineers. Engineers are also using lovable to hey I want to prototype something quickly I want to just test it boom boom boom they test it nah I'm gonna go here plus it's cool right like lovable you can build in lovable get it into github and then continue building it in github And that's also like, yeah, so I think it's super cool. I am, I'm an addict. mean, I am full bought in. I can't stop building stuff in Lovo Bowl or other. I mean, with Claude Cote as well, anti-gravity. I think, I think that's something that even if you're not a technical person, I still remember our discussion in December. We're like, Hey guys, hey, hey, Daniel, hey, Michael, I want to try a Gentic or agents development. Like, man. Chill out, you're not an engineer, you won't get it, you'll be stuck. Well, guess what? Not anymore, because that's how it's changed. So I really think one big takeaway from this is go and explore. Don't be afraid. None of these tools are for engineers. All of these are for people. Anyone can try. It costs you very little, or no, none if you try the sort of very free versions. Deejay: You Tomasz: But yeah, we are on it and we are truly embracing it as an enabler and we're looking very positively towards it rather than looking at all the risks. Of course, we are fully aware, we have built in also audits inside that, we ask all our Vibe coders to put it on GitHub and now we have, we use one of our colleagues has built a scanner that scans all the repos of Vibe coded apps. and returns like risks or gives a security assessment. So we have that and we ask you to like we have a register of all the apps. So there is a bit of governance, but we always highlight it's there to help you. So if you go on a vacation and someone is using your app and it breaks, we can quickly fix it because we have access to it. So it is building that partnership rather than looking at it from the dark side. We look through the lights, we look through the positive, we look through the enablement. And that has been, that is paying off. That is really paying off. Deejay: ⁓ man, I just had a thought there about SRE practices and like, in a way, people, non-software developers creating an app in loveable and then exporting the code out in GitHub. then like, if you end up being the tech team looking after that, it's presumably massively different from being an SRE in some enormous organization where someone's built an app and you've got no idea who they are. But if they had defined, you know, the metrics that are important to them and they've made that tests and the code available so you can step in so you can fix it. ⁓ That might be a good way of thinking about it. Tomasz: Yeah, yeah. I mean, yeah, yeah, yeah. It's a very good way of thinking about it, yes. Deejay: With the ⁓ point about Claude Code not just being for software nerds, ⁓ yeah, I think I've definitely subscribed to that for you now. Our CFO, Christian, keeps building things in Claude Code and selling them to people. He's very well connected in the Danish business community and keeps on like replacing people's sasses. And he keeps doing that. And a friend of mine is a like stock market analyst and he basically like built an entire website and like membership system and rewrote how all these reports are generated that used to be written by hand, all through Claude code, all like stored in gets, was stored on GitHub and it's, it's like, it's proper apps. He, this is a guy who, ⁓ didn't bother going to his IT like secondary school exam, cause he knew he was going to fail it. ⁓ and yet he is through Claude code being able to kind of learn enough to, be able to make that happen. So with the. Tomasz: Absolutely, absolutely. I think one thing that we have to, everyone has to, I think fully understand is like, once you start using lovable, there will be a moment when you're like, what if I try Cloud Code? What if I edit this out there? What if I start hosting it locally? And then I get my own instance and I move it there. Everyone will have that moment. And I think no one has done more for making, you know, Deejay: you Tomasz: enabling people to become engineers. I mean, they're not writing this up, but they are becoming engineers. They have to think about the structure. have to think, you know, the architecture behind it, the data. It makes you think about it. That's a massive, that's massive. Like your CFO, your analytics colleague, in our case, it's financial managers, accountants, CFOs, CEOs are all doing it and they're exploring what they can do, right? And it's fantastic to watch, I think. It's really cool. It's just being in the middle of that feels super positive. Deejay: Yeah, we're kind of creating many more builders and you know, we could say that lovable lovable is the gateway drug to Claude code. What kind of ⁓ use cases are there any that particularly springs to mind either of things that you've been five coding in the evenings or like particularly impactful like internal things that maybe wouldn't be obvious that have come up from, you know, the Tomasz: Mmm, exactly. Deejay: If from individuals rather than somebody top down going, we should build an app that does this, like somebody self solving a problem. Are there any particular use cases that springs to mind of the kind of things that non-developers have been able to do? Tomasz: I think it's all these excels that are built long time ago by someone who nobody remembers. And now they're used to manage the company and to pull out data or you reconfigure one cell and then you get like a full thing. That's those. And we are seeing that as a very typical one. Or internal small CRMs, right? Just like a 10 person team needs to manage some sort of customers or something. Yes, why invest or something? Just, you we build something small, you close it, a lot of that. What I've built is a, I've built a whole career framework or career, as current framework, including performance reviews, one-on-one discussions. We've uploaded and built a whole ⁓ career framework, a growth model that, you know, across five levels of all roles in product and engineering, or Devo across 10 competencies. You can score yourselves, managers can score, you can have 360 feedback. I've built all of that in Lovable. It isn't now updating that and getting all the people with their great ideas. Well, it's painful, you build it, you own it mindset. I am now really feeling it. And that's something we continuously repeat to all these builders that we're having. It's like, remember, you build it, you own it. You can't at one point when it gets hard or when somebody finds an error, you can't just go, hey, Deejay: Hahaha Tomasz: IT, hey tech, come rescue me. No, no, no, we can help you when it gets really bad, but we expect you to have excluded or exhausted all possibilities of you doing it. And I think one of the cool things about Lovable, the other thing is you build it, you build something, you don't like it, you can just turn it off, remix it, try something else. And it's a click of a button, there is nothing. And it's the... That's also a very important part of Xp. But I think the main message that we're giving to all of our colleagues is take something that annoys you, something that is ⁓ hard to manage or requires a lot of manual things. What if you build a lovable app for it? Try it. And we're seeing people looking at it. We're also, I think, more and more looking at like, it's not build or buy, it's POC and then let's think about it. First, tell the POC of what you want from a tool, right? Rather than, yeah, only let's do a big bio build analysis. No, no, no, no, first POC it in lovable and then let's have that discussion again. Deejay: You mentioned building apps to replace things that are difficult to manage and annoying. That sounds a lot like me. ⁓ How long till the DJ Lovable app? How about the impact on product management? So we've talked about the wider context. talked about engineering. We've talked about people who are non-software developers starting to create software. Tomasz: I'm building one, don't worry, there's a Danielovable app I'm having. Deejay: How is AI being used in things like product ideation, ⁓ communicating product management ideas and things like that? Tomasz: So it's not a structure, right? So people are trying things. We have several product owners or product managers that we sort of moved to a product manager role. Adivo, we're seeing them use cloud code or just GitHub co-pilot to make changes to production applications, right? And there's this one thing that has always bothered me. I'm gonna change it. Submit a PR, get that PR approved. All of that, all those things are happening and I think that that is happening, right? So, but another thing that we're seeing is much bigger interest in context management or how do I, how do I, know, I have all these meetings, all these documents, all these things, how do I start bringing that to use that with my AI? So we're seeing that, but again, it's a bit unstructured. It's people are very interested. So we said, Hey, The AI training for engineers were super successful and helped create structure, to create baseline and learning journey. And we said, hey, that model worked and we're doing the same for product now. So we're starting a training for product. So AI for product in which we will educate our product, people, product, BAs, designers. And the people around, we're inviting people from our operational companies, we're inviting people from finance, procurement to be as a much smaller group in that training to see, to give them tools. Of course, for product, we're going beyond just applying AI to, know, going all the way to agentic. We're adding more things around context management, research, stakeholder management, communication, because these are all very important and powerful tools for a product that we also want to embed. But yeah, we saw it work for engineering. Let's do the same for our product folks. excitement is there. And I think it's also a powerful unlock as well. Deejay: I seem to remember hearing about, ⁓ I hope it was at a dev, otherwise it's going to be really awkward and embarrassing. There was an example of ⁓ somebody, somebody more on the product side, or maybe in one of the operating companies who kind of wrote a document of all of the things that a user needed to do. But as a starting point and got one tool or other to build an app to satisfy that set of user needs. And it turned out to be something quite similar to one of the bits of software. you were creating. ⁓ Was that you folks? Is that something you've heard of? That's going to be my plausible deniability. If you haven't heard of it, ⁓ it must be somebody else at Adavo that said that to me. Tomasz: It's probably someone else at Odivo, but I don't, we have had cases of people saying, okay, this is a problem. Let's just try to build something that solves it, right? Or, really just going into meetings and say, Hey, let's build something together. More of that much more open to collaboration and pair programming in a sense where there's not a single programmer in a pair programming, which is also interesting, right? It's just a product person, a customer or a user or an accountant or someone. Yes, ⁓ much more of that. We don't know how the future will look like, How will they convert? I mean, we are seeing a convergence where it's less and less obvious that, you know, we're all, I remember Scrum, you had the PO who was very responsible for this, this and this, and it was always clear that there's no overlaps, right? I think that is changing. Of course, there will always be someone with that. with a strength in one area and a weakness in another. So there's always a complementary element that will be there. But we are seeing, you know, people are exploring, and being bold. And I think that's powerful. But your case, I'm not sure. I haven't heard about it, but sounds legit. Sounds legit. I could see someone doing that. Deejay: you Yeah. And kind of going back to your point about POCs as a first step versus build or buy. Have you had many examples yet of people kind of ⁓ using prototype as requirements? So product managers kind of knocking something up in lovable and then handing that over instead of spending time writing a million stories, or is that still yet to come? Tomasz: More, more, more of that. Also a big, much bigger shift to spec driven development. ⁓ So I think we're seeing many more people embracing that way of building, which just so not everyone thinks it's very easy. Writing a spec is you just, hey, Claude, write me a spec. Man, ⁓ man, are you up for a surprise? I'm not gonna spoil it. But no. So we're seeing a lot of that, but we're also seeing a lot of like much like shifting left because you don't really need to now manage the day to day of your engineers going like, hey, what are you doing? What is it? What's happening? You're saying, hey, I want to explore the bigger future. I want to be more curious about how we do it. And then, you know, bringing people together. So. Deejay: Yeah. ⁓ Tomasz: Yeah, yeah, I think more and more lovable is being used or even like basic or Divo. Of course, in a Divo GPT, people are building like an HTML mockup and saying, here is a mockup added to the ticket done. And you can already see that, right? I think all these tools are very good in distinguishing like design patterns, right? So can take a screenshot of any app and say, now put X in this app and it will build it in that. Stuff like that is very cool, right? So you don't have to really describe your thoughts. know, a picture is worth more than a thousand words. But of course, a picture is worth a lot of more tokens than words. So that's something to remember. ⁓ we're seeing that as well. Like this exploration of like, hey, I don't need to, let me just try to stick this feature into this already existing UI. And then here you go. Let's discuss it together. Like, yes, we're seeing that for example. Deejay: Hahaha I was just about to segue onto like, where do you think this is going and shifting left and being in contact with your customers and all those sorts of things. And then my, lovely heated desk mat just wouldn't beep. don't know whether it's going to be audible on the final edit, but if it was, that's what the beeping was. It wasn't a bomb about to go off in my office. But then you talk about token costs and I'm very tempted to bring it back to something really tedious and boring, which is in terms of the rollout for engineers. Tomasz: Or mine. Deejay: Which tools did you go with if you're okay talking about that and how have you approached budgeting? do people have a certain number of tokens they're allowed to use? Are they on all you can eat subscriptions? Are there hard limits? Do people have to request more? Did you just go screw it? Like you know, token maxing. Tomasz: So when we started, for the purpose of the training, we said, ⁓ you know, get a personal cloud license just for the training, right? So you explore it. But remember, we also use a DivoGP in the training because then we still didn't know that it was going to be that big hit. And then over in January, February, everyone started realizing that the world is massively changing. I still think like we all went and had our Christmas dinners. We came back after the fireworks and all of sudden everyone got smacked like, boof. Of course, now we know where there was a lot of things coming. It wasn't sudden, it was meant to happen, but that's how they feel. so there was a hit and then also our key stakeholders, our board and our owners said, It's we have to get on this train. We can't, we can't be laggers. We have to begin adopting and we, yeah, we, we are using Entropiq now. So we have Claude and all, for all employees. ⁓ yeah. yeah. Odevo and wider. Yes. Because I, I, ⁓ is it to be the tool for the next two years or three years? I don't know, but it is the tool now. Deejay: Okay, so it's like a enterprise organization wide kind of arrangement. Tomasz: And we can see, you know, the other frontier models are not sleeping. So we're always monitoring and we're trying to find that balance. But yeah, we moved into, and now we have enabled it for everyone. So everyone is on cloud. And you can, I'm talking to people like accountants, to people in performance HR, recruiters to finance. They're like, yeah, there's no going back. Deejay: Is there, are you able to speak at all about the kind of level of investment? it significant? One of the things that I see in other organizations is people being really kind of cagey about spending more money and, you know, spending like maybe putting a couple of hundred euros limit per engineer on the amount of token spend that they have, which, you know, if you were all of a sudden to say like, are we going to spend a hundred, a hundred euros per month extra on every developer? Like, just in absolute terms, ⁓ that sounds like a lot of money. But then if you think that team can now do three times as much work, if you were to hire three times more developers, that would be significantly more money. So in terms of the level of investment you folks are making and the return that you're getting, one, are you allowed to talk about or able to talk about the numbers at all? And two, do you feel like you're getting a return? Tomasz: I think we approached this like, would you say, would you think about the license costs of giving someone access to Outlook, PowerPoint, Microsoft? No, you wouldn't. And I think that's how we approached it. It's not about the cost. The cost is one thing. Of course we looked at it, but it's like, can we really consider ourselves the third most valuable tech private company in Sweden? if we start looking through all the red tape and blockers. I don't know about the exact financials. I don't know. I can't tell you. But we looked into that lens. saying, we are seeing huge benefits. Why not? Why? Let's go. Let's go. We, of course, are constantly monitoring the use. We're very transparent. Anyone can check who's using more, who's using less. ⁓ and we are educating, we're informing, we are building like, and I think the training also helped people realize you don't need to use Opus 4.6 for everything. Now it's 4.7. Sometimes Sonnet is good enough or IKU is good enough or even your good old Odevo GPT can help you. So I think that's something like it make, I think one thing that keeps being a theme throughout this conversation is like, it's more about awareness. than sort of coming up with a positive outcome. Thinking through the positives rather than thinking, ⁓ no, people are now burning money or overusing it. No, this is a time of change. Nobody really knows, right? So rather than trying to put red tape and yell at people that they are, why are you spending so many tokens? Rather than, hey, what have you learned from spending this money? Did you really have to? Like what's happening? Talk about it, share. Let's discuss it. Let's educate. These are the things that we are spending our time on. Not looking to that. Deejay: Cool. So before we wrap up then, ⁓ where do you think all this is going? Like, so, you know, we've been in this together for nearly a year now, at least half a year and quite a lot has changed in that time. ⁓ What kind of changes do you imagine happening in your organization and also like in the wider marketplace? Tomasz: ⁓ yes. Well, I have this, I don't know if it's a dream or an ambition is that we have 14,000 employees at Odivo right now. We've been doubling it all the way. We have 14,000 employees in Odivo. People going like a lot of accountants, blue collar workers, technicians. I have a dream that all 14,000 submitted PR. I think that's how I see it. That's how I would love to see the world where you... you have this freedom. are in PR or they build an app and they share and they're proud of it, right? But I think in PR, like you're using a tool that you think like this one thing is annoying. Let me let me submit a PR. Maybe we'll get rejected. That's OK. But I will at least raise my hand and say this is something. So that's that's I think where it's going. I also think the art of writing syntax that you write, you really open. ⁓ A notepad, I mean, that's how I remember my code. I mean, my coding is like, wrote HTML. I'm not a code, I'm not. But I remember opening a notepad and go, that is not happening. But you still will need to have junior, mid, and senior developer staff principle. You'll need to invest involving those, helping people grow. But I don't see them as being. Deejay: You Tomasz: I don't see that as being, know, only the art, writing code or creating code will only be in the hands of engineers. think everyone will do it. I think engineers will also be, it will not be writing code. They will be using AI and I think it's going to come sooner than we all want to believe. So I think the main message is get on. Just do it. Just do it. Just spend those $20. Just do it. Like it's just 20 bucks. It's like, Deejay: The. Yeah, get on the bus. Tomasz: Kebab or exploring AI, like come on, it's not a big deal and just explore, just something simple. Take an Excel you use, your daily budget, whatever, just do it. You will not regret. Deejay: Yeah, that view of having so many more people solving things that irritate them and being able to raise PRs and create software and change software is something that for like years in my career, you know, I was hoping cloud platforms would reduce a lot of complexity and enable people to focus more on solving business problems and on outcomes for users. I was optimistic about low code, although it never kind of really took off as a way of democratizing software development. And so many people are not even trapped in businesses where the processes are embodied by software that they can't change. Like as the world becomes more digital, we're all becoming trapped in like digital systems that we can't change. Like my kids, 13 and 16, have no idea how wifi or apps work or anything like that. ⁓ And they, you know, they're not going to be able to change this stuff. And like in The 1970s, if there was a business process you didn't like, you could like go to the piece of paper it was written on and rewrite it or change the, you know, the graphs and the, the org chart or whatever. If you are 400 years ago and you're a blacksmith or something, and you don't like the way that you're making swords, then you just change it. We've gone through this period where all of that change is being gate-kept by us technologists. Cause oh, it's really hard. You've got to think about it very, Tomasz: I don't fully agree with that. It's also the process in organizations is because software became very like it was expensive, right? Making a mistake was expensive. It wasn't even the engineers all the time or the product people or the teams. It was also the organization saying, this engineering team costs me a million a year. I need to give it only valuable things and I need to make sure it's utilized 100%. Like it wasn't even them. It was sometimes people that have no clue about. Deejay: Mm. Tomasz: code that were gatekeeping it. Of course, sometimes it was also engineers, I'm not saying, but many times it was the organization that was just, and I think those organizations that don't embrace that the world that they want, that, you know, it's democratizing. Now, anyone who wants can build a piece of code, put it on production and make it available. Then you're going to be in a lot of trouble very soon. I think that's it. I, but I also, I on the more pessimistic. think we're going to at one point we're going to face a lot of like, you know, around Earth there's all this trash, apparently. I think we're going to have this world of app trash that will just be at one point you won't be able to even find a URL address that's ⁓ less than 10 letters because there was someone has already taken it to build a random app that measures the length of grass. I don't know. You know, I think that that's going to be something that some organizations will be you have to find a way to manage that. Deejay: Yes. Tomasz: influx that you're going to the exponential growth of applications. It's not linear. It's going to be quadrupling like every month at one point and whatever you have to some somewhat taking care of that chaos and having those bulls like this app is not used. We're killing it. So make sure that doesn't get out of hand, right? Because in Europe GDPR is still GDPR data is still data. You can't forget about that. Sure. But make sure you also have some, you have an idea in the back of your head. Once this is democratized, how will you feel you can go to sleep at night as a leader in the organization? I think that's something to think about, but I'm still super optimistic. I mean, loved it. I mean, come on. It's, it's a great time to be alive. It's a great time to be alive. To build like the freedom, the freedom you can, you can't replay the dopamine rush, but also the freedom of like, just I have a crazy idea. and build it and then you can it's a prompt away it's fantastic it's fantastic Deejay: That's an excellent point to stop on. Before we do, though, Tomasz, we've got two facts about Poland. One, how to pronounce your name. Two, that Polish Independence Day is the 11th of November. Can we hit third? Tell us an interesting third fact about Poland that maybe not everybody knows that we can round out on. Tomasz: Fahrenheit was from Poland. The guy that created the Fahrenheit scale was in Poland and of course Poland does not use Fahrenheit. But hey, he was from Poland. He was from Poland. Deejay: I'm trying to work out whether that means we should blame you or the Americans for the Americans still using it when yeah, let's go down that route. Right, thank you very much Tomasz. It's been a pleasure as always hopefully I'll speak to you again soon. Tomasz: That's not part of the fact. That's not part of the fact. The fact was just this. Yes. Thanks. Of course.