3565: CKEditor and the Reality of Supporting Developers Across Every Tech Stack

[00:00:02] What if the most influential software in your life right now is one that you don't even notice? Well, today's conversation is going to zoom in on the quiet layer of technology that sits inside countless products and shapes how people write, edit, build and ship without ever putting its name on the screen. Yeah, we talk a lot about flashy platforms and headline-grabbing tools,

[00:00:29] but far less about the developer experience that makes them usable, trusted and sustainable over time. And this episode will explore what happens when curiosity, tinkering and empathy for how developers help guide technical decisions. You're in for a treat today. So if you've ever wondered why some tools feel natural to work with, while others feel like a constant uphill fight, this conversation will hopefully hit home.

[00:00:56] And a company I'm proud to call friends of the show is Denodo, because not only have they been on this podcast multiple times, they also help make sense of the AI data chaos that we're seeing now. Because the data world is louder than ever. AI hype, lake house complexity and pressure to deliver more with less. These are things that I talk about every day on this show. But Denodo is helping businesses make sense of it all,

[00:01:21] because they provide a unified data foundation for trustworthy AI, lake house optimization and data products to finally bring service to life. So if you're ready to unlock real outcomes, simply visit denodo.com today. But enough from me, let me introduce you to my guest today and we'll talk about all this and much more. So a massive warm welcome to the show. Can you tell everyone listening a little about who you are

[00:01:50] and what you do? So my name is Andrei Krastina. I'm from Brno, Czech Republic. If you don't know Brno, it's basically one hour or one hour and a half from Vienna. You just drive north and you will hit it. Personally, yeah, I'm the guy who likes cooking and more eating, to be honest. I'm kind of a foodie. What's the new term that is being used? I like sports. And yeah, I just bought a house and I'm doing a

[00:02:18] little bit of a tinkering around lately, smart home thing. So all of these tools with lights and sensors, if you close the doors and these kind of things. And professionally, yeah, it's kind of close. So I'm basically tinkering with the technologies. I spent around a decade within the content management systems. Yeah, it was a typical start for me. So I finished the IT college, started as the QA, then worked through the

[00:02:45] development of the software. Then we moved from content management to a little bit broader. So I was doing e-commerce, online marketing modules and so on and so forth. And then I saw our touch first open source repositories for the content management system I was working for. And it brought me to the developer relations. So yeah, I just got deeper and deeper. And that's what I'm doing up until today. So that's basically my story.

[00:03:13] I did a little jump away for like two years to the data management platforms, again, in data developer relations. But it was a little bit switch of the field that I was doing the development. Love it. What a great story. Sounds like you do love tinkering. We'll call you the tinker man. I think. But when you're tinkering with tech, not just tech, food, I mean, what would your favorite food

[00:03:39] be? Whether that be eating or cooking? Is there a particular kind of... I really love experimenting with these single pot meals. So basically everything you put in the pot, you just need to know the right order and you will get something super great. Yeah. So carbonara way is... Yeah. Carbonara is the way I go. Doesn't matter if it's spaghetti or I put basically any pasta in

[00:04:04] there and it always ends up incredible. And you said sports as well, a particular sport that you're interested in, is it? Football or...? Yeah, it was football for many years, but after four surgeries with my knees, I'm getting it or taking it a little bit more easy. So it's badminton, tennis. I know it's still pretty hard sport on the knees, but I can just ruin them myself not being tackled by the other players.

[00:04:31] So it's a little bit safer. So these are the sports. So basically I'm trying to get to pedal. I don't know if you know it. It's basically a combination of tennis with, I don't know, ping pong a little bit. Yeah. The rocket is a little bit different. So this is what I'm getting to right now. Yeah. I'm hearing from more and more people taking up paddle at the moment. It's hugely popular here

[00:04:56] in the UK as well. And when I was looking back at your story before you came on the podcast, you started your career in QA and development before moving into developer advocacy. So looking back, how do all these experiences and day-to-day developer frictions that you might have encountered, how do they shape your way today with your approach with developer relations? Do you look back and see how all those dots joined up?

[00:05:23] Yeah, I do. To be honest, the QA or the testers had this stamp of being like really beginners in tech, but I started as the QA and I don't really think so. But besides of that, these roles basically have the unique position to use the technical products as the users because they are testing it from this point

[00:05:47] of view. And I was also exchanging a couple of things in the third level support when I was doing QA. So I definitely recommend at least to test it out, try it out and show the boots because it gives you really unique position and get the experience of the product from the outside, which I'm always trying to do when I'm doing developer relations right now. And I started when the Scrum was very

[00:06:14] setting up, let's say. If you're not aware of Scrum, it's basically you're building the teams with various roles and you are reviewing each other. So no job shouldn't be done without review. So it gives you a lot of insights, not in just software development, but in product work, testing work, design work, and so on and so forth. So I think being QA as well as being the part of the

[00:06:39] Scrum team gave me the really big base for my current position developer advocate, as well as all of my friends that we went to college together were developers and product owners at the beginning. So yeah, we're basically trying to get the most of each other. We are still seeing each other. So this also gave me the opportunity to learn not just about the company that I was working in,

[00:07:08] but their company as well. So that's basically what I did with the QA. So I think it gave me a little bit edge over the others because now I have the credibility, which is nice. But honestly, from my point of view, I'm much easier to impersonate into the user and let's say outside customer of the product.

[00:07:33] And I was also reading that at Kentico, you became one of the company's first dedicated developer advocate. So what signals told you the role was needed and what did you learn about earning trust from developers inside an established product team? I feel like there's got to be a lot of lessons learned there. Yes. So it was probably one of the biggest, let's say switch or detours or

[00:08:02] steer in my career because yeah, it was usually you go developer, then you are going to senior principal, you are getting deeper and deeper into technology or you go to management. But I find basically this role by accident. I was not the first, I was basically the second. But yeah, the beginning of stories, Kentico itself, when I started, there was already well established technical community. And so there was a forum and emails with the support. So there were already

[00:08:30] many people using the system and basically helping, helping each other even when, when, let's say building the digital, digital products based on the system. But these questions and issues and resolutions became to repeat. So that led to, let's say, open up the possibility to somehow do something about it was not like, hey, we do developer relations, because it was not a thing even at the

[00:09:00] time. But my colleague, or my former former customer, Peter, who was working for the agency, basically came to the company, and arrived to set up the, let's say, the management of the developer community, just developer community, nothing super, super broad. And yeah, I just saw that he's sometimes doing a little

[00:09:24] bit of the open sourcing of the showcases as a part of developer building, and I start to see that it might be something interesting for me. So I immediately start to, let's say, drive towards that. I didn't know it's developer relations at the time. I was basically just wanted to do the open source repositories about the product and get to the actual usage of the product, not just developing the system itself.

[00:09:49] And then after a couple of weeks, I became the second developer advocate. So we're two of us building the team called the developer community. And slowly we were transitioning throughout the time from just basically community management to full blown developer relations. But it was a long time or long transformation ahead of us.

[00:10:15] And I also read that when Kentico spun out Content AI, you were supporting developers across JavaScript, TypeScript and .NET. I've got to ask, how does developer relations change when you move from a huge monolithic platform to a headless API first model? I'm sure you picked up a few stories from that too. Yes. So just connecting to the previous question. So we are basically starting as a developer

[00:10:45] community and expand for the developer relations. So we started to do a little bit of a developer advocacy. So basically bringing the feedback back to the company and basically sharing the product updates out. Then we are doing evangelism. So we're trying to evangelize the product and put out the word about the system on all around the place, conferences and so on and so forth. And also the developer enablement.

[00:11:12] So we're doing the tools like SDKs and starters for Kentico itself for the product. It was the dotnet based. So it was 99% dotnet libraries and dotnet scripts and dotnet showcases. But when the content dotnet, and it was again, a long story of spinning up the internal startup by pivoting multiple times. But when it already settled and business case and the product was already defined,

[00:11:41] we slowly got to the got to the phase that it was API first platform without any developer tooling around. And that became like the most interesting part or like the most exciting part of this career, because I didn't know anything about the other technologies, or I knew a little bit about JavaScript, but not that much. But I slowly, slowly moved from this monolithic one platform, which basically

[00:12:09] the definition of the practices was the dotnet practices plus hours. And that was it. So it was really narrow focused and deep dive deep dive implementation practices. But when we went to the API first model, you're basically opening the gate to everything right to any technology. So it was JavaScript typescript and dotnet was the core.

[00:12:35] So we needed to have everything in these three languages. But I did a little bit of Ruby, did a little bit of Java, a little bit of PHP, just to showcase that it's also possible to use this platform with. And it was really, really exciting and a lot of learning behind the curtain as well. So it was basically two of the shifts that I did. So first, broader up from just developer community to

[00:13:03] developer relations. And the second one opening up to every single technology that can consume the rest API. Yeah. And your backstory is one that keeps giving because I think from there, Atacama, you've, uh, folk, your focus then shifted towards data engineers and cloud platforms like snowflake and Databricks to name but a few, but I'm curious on that journey, what surprised you

[00:13:27] most about the developer experience in the data world compared to the traditional application development that you were used to? Mm-hmm. Uh, I switched to Atacama because I already spent around a decade about content management system, the candy coin content and kept repetitive. So switching to Atacama was really opportunity and they didn't have any developer relations, but to set up the developer relation

[00:13:52] themselves. And as you said, there were surprises. And the biggest one was the target persona because I thought that it will be, yeah, it will be developer with the different, uh, different point of views. But yeah, it was a little bit different because the main person persona that we are aiming for is a data engineer. So this person is basically don't care that much about implementation, the architecture,

[00:14:16] these nitpicks of, uh, using it, uh, effectively, flexibly, and so on and so forth. This person is focusing on data itself. So completely different layer, uh, in the, in the technology. So again, I needed to learn, uh, a little bit, uh, but the core and the course, uh, the core of the showcases were a little bit different because before I just showcased the GitHub repository

[00:14:41] or showcase the script, uh, showcase the capabilities, make a documentation. And that was it for the data engineers. It was more about, Hey, this is how you do it. This is video tutorial. This is guide how to do that. Uh, you basically showed the same thing, uh, three, uh, different, uh, three different ways just to, uh, be able to tackle all of the possibilities. And as well, the article was different because when I was doing content management systems,

[00:15:08] content was basically the content that you are putting on your website, on your legal documents, on your digital portfolio, whatever. But with, uh, with the Atacama, the data was a little bit different. It's basically, I don't know, records from your bank recons from your, uh, IoT devices even, right? So the temperatures and so on and so forth. So it was really structured data. So even this, uh, needed to be presented a completely different way, but the biggest

[00:15:36] surprise was the persona. Yeah. And it took me, it took me a while to set it up. Quick, thank you to the sponsor supporting all of the shows on the tech talks network. And this month I've partnered with Alcor and if expanding engineering operations beyond your home market can be overwhelming, you're not alone because if you've ever wrestled with local laws, slow response times, and, and partners who treat each country as separate rather than part of a wider

[00:16:05] strategy, you might want to check out Alcor. They approach expansion completely different. They specialize in building tech teams across Eastern Europe and Latin America, and they combine employer of record services with recruiting. So you get one singular coordinated process. They help you choose to write your restriction based on your needs, run proper evaluation of candidates and onboard teams quickly. And their model is also refreshingly transparent.

[00:16:34] Most of your contribution will go straight to your engineers and their fee shrinks as your team grows. And there is no cost to exit if you move the team in house at a later date. And I think that kind of clarity is why so many high growth companies in Silicon Valley are working with them right now. So you can find out more details at alcor.com slash podcast, or simply use the

[00:16:59] link in the show notes. And as someone that has built SDKs, internal tooling tutorials and start a part, start a pack across several companies from your experience, looking back there, what is it that separates developer relations work that genuinely helps developers from content that simply looks good on

[00:17:20] and takes a few boxes. Where does the magic happen? Well, I strongly believe in showcases. So I always try to showcase and do the evidence. So I don't want to write an article about something theoretical. I always try to at least try it. I most of the time don't finish up at the end. I don't do the full blown application. I just try this

[00:17:45] little use case, I build a repository around that or something. And then I'm able to showcase it. I think it brings first brings the credibility and people are really interested to see it. Or if they don't, they just drop right away. So it's really big, like this decision is being done fairly quickly, they don't read don't need to read like, I don't know, a couple of paragraphs just to get the idea, right?

[00:18:12] So and once they decide they want to do it, I'm trying to do this pieces and it doesn't matter if it's SDK internal tooling or something, I'm trying to do them repeatable. So even for the article, for example, I'm trying to put there the code sample or the script, or I don't know, three key points that you can take so that people can like save it. I don't know for the SDK, you fork it or you download it for the article,

[00:18:38] you copy and paste it or you bookmark it into somewhere, or you put it into your library of the reading list or whatever. But I'm always trying to do this action. Because if they if people do that, you can right away see that it's useful. Now, I don't always hit the mark 100% of course, but I'm trying to do something repeatable that people will use sometimes they need to adjust it or tweak it a little bit. But that's what I do. And yeah, maybe the last thing that came up on my mind is

[00:19:10] something like make it relatable, or if make the reference with their day to day tasks. Because for example, I was just I just finished a CKEditor AI webinar, the CKEditor AI is basically the add on to the CKEditor that gives you the AI capabilities. But explaining it, it was really hard to just say, hey, this is what it does. And that's it, right? Yeah. So I built the mockup application

[00:19:39] that was basically combination of CRM, CMS, ecommerce, BA platform, whatever, just a couple of menu items that people might be familiar with. If you clicked on it, you just saw the editor, and but the form was getting closer to their use case. So for example, if somebody was using this or using CRM, which is a customer relationship manager platform, basically, where you're storing

[00:20:04] information about your customers name, surname, and I don't know, meeting notes, and so on and so forth. I showed them that, for example, if you have the CRM, you have meeting notes, and you can use this CKEditor AI to get the summary of the meeting notes for the last three meetings or something like that. And if you create this reference or relations in between their day to day jobs, and the story that you are

[00:20:30] showing, I think that generally brings the value to the content that I'm creating. So basically, it is free showcasing repeatable, repeatable action and the relatableness or references. And you mentioned CKEditor there, that's where you're spending 20, 26 and beyond. You're working

[00:20:57] in a space that sits inside countless products, but without most end users even realizing it. So I've got to ask, how do you think about developer experience when your product becomes almost invisible infrastructure? Does that change things? It very much does. Honestly, even Kentico and Atacama and all of the systems, it's very far from, let's say, day-to-day business users. But for CKEditor, it's a

[00:21:27] completely different story. Maybe a little bit about CK before we get to it. So basically, the CK editor is the editor component. So when company wants to, they can buy this component integrated into the application, and they can have the editing capability. So it's basically like the Google Docs or Microsoft Word that people can integrate into the application. There are two typical use cases that you are basically

[00:21:55] integrating the CK editor to. First one, you have some product. I don't know, you are creating the new super SaaS solution application, and you don't want to border or you don't want to waste your resources on the editing capabilities, but you need them. For example, for, I don't know, description of some entities. You need them for document editing, email editing, and so on and so forth. So you just buy this component, you plug it into your application, hook it to your storage,

[00:22:24] and you're done. There is one thing that you mentioned, and this is the white labeling. So basically, yeah, you don't really see that this cool new SaaS application or product that you start selling. So as the customers, you don't even know that you are using CK editor. And this happened with countless products already, right? So you have really big brands, and if you're editing

[00:22:49] some content within your software, you don't really know that the CK editor is in there. So this is the typical use case for the CK editor. Sometimes even the consulting companies which are doing the software definitions or some software houses use just CK editor and they use it everywhere for their projects because they don't want to repeat the work. And they already know it works,

[00:23:15] so they just bought the license, and they are reselling it into their custom software, again, white labeled. So this is basically the CK, but enough of CK and its capabilities. Long story short, you don't really see that you're using it, but it's a really powerful component and the platform behind it. So if you want to

[00:23:40] attract this to the companies which are building the super new cool systems or need to have the editing capabilities, you need to show them the value, show them the benefits, right? Why they decide or why they should decide to buy the editor and integrate it rather than build it themselves. So the value is fairly

[00:24:05] easy because if you take a look to the web standards or HTML standards, there is no out-of-the-box component that you are able to just plug to your application and have the editing experience there. So there has to be some catch, right? And there are a lot of them. I don't want to go deep, but HTML editing is really hard. The standard is very vague. So having it standardized and being in place,

[00:24:35] it's kind of a tough job. And I think the CK editor is doing a pretty good job to solve it. So this is something that you start with. So just to show them the value, doesn't matter the developer experience right now. And the second part is the developer experience, because if you show people that they can save some time, money or something like that, you also want to show them that they are able to use

[00:25:02] this component for various use cases because they already bought something and they want to use it as much as possible. So it needs to be flexible, it needs to be customizable, and it can be integrated with any systems that they have. So this is something that you can write, make videos for ages, right? Like the capabilities are endless. Basically, any software now can run throughout the web browser. So

[00:25:29] it's fairly easy to do something, you just need to pick the right pieces. And the last thing that is sometimes being a little bit, you know, putting into the into the background is maintenance and support, right? If you implement something, it's super hard to keep it, maintain and support it if you don't have the long term commitment to it. If you implement

[00:25:55] the library, you put it somewhere and you are not willing to maintain it, support it and improve it throughout the time. It's super hard. I remember there was a library called Left Pet. It's a JavaScript company, sorry, a JavaScript library, which was maintained by just one, just by one person. And he decided to delete the repository and it broke half of the internet. Like,

[00:26:24] honestly. So that was super critical. And I use it all the time. And people ask me like, why should I buy this? Like, yeah, we are not Left Pet, right? You're buying license. So we are obligated to keep it there. It's not something that somebody put somewhere on the free time and then you are relying on it. So these are the couple of things that are a little bit different when you have the

[00:26:48] product that is invisible, because you can show the value. You have to show it makes sense. And the other aspects are more or less the same. You need to showcase that it's easy, how to do things, how to do the practices, how to integrate it by the various use cases. So it's very much the same for the other parts. And yeah, of course, the brand environment is a little bit harder to talk to.

[00:27:16] So if you have the conference and you are on the booth and people see the brand, it's not like, hey, it's Nike or something, right? It's like, hey, what are you guys doing? And like, yeah, these are the companies that are using us, but you probably don't know about it. But yeah, that's what we do. If you open up your mobile phone and show me these two free applications, you probably have it right. Brilliant. And you're an incredibly busy guy, because not only

[00:27:41] everything we're talking about, that keeps you busy, but you also spend time on open source, YouTube, blogging and conference stages, all in parallel with your full-time roles. And for companies building developer relations teams today, how do you think they should be balancing community authenticity, authenticity with business goals, etc., without losing credibility? Because from the outside looking in, it seems to be something that you've mastered here.

[00:28:11] Yeah, I'm spending the time on these, but not as much as I would like to write. Yeah. But yeah, I think it's basically implicit, right? You have to build the authenticity, authenticity, maybe like credibility, even like, I think the credibility is a little bit more important than the authenticity. But I still think the authenticity should be there and I like it,

[00:28:36] but I don't think that it's necessarily a rig fired. So for the credibility, I think it's a good prerequisite or it is a prerequisite. It's not good to have it. You have to have it. And it helps the long term. So for example, if you are building your personal brand, you need to keep yourself up to date. So you need to go to the conferencing, talk to people,

[00:29:02] don't read the updates, right? Try to find a possible integration opportunities, catch the hype, you know, you know how the AI is right now. Before it was, it was a collaboration, before it was distributed systems and microservices and cloud, right? So you need to catch the hype and be up to

[00:29:26] speed with everything. And once you have it, my, and I think many developer advocates has a little bit bigger ego that they shouldn't have. And they want to like share it, right? Some of them has the good reasons and I won't lie. I'm trying to have it, but I also really like that when I'm sharing something, it has some success. So you want to, you want to put it out there as well. So that's, that's how

[00:29:53] you are building this personal brand authenticity and the credibility out there. But for the business, you were asking how to balance it. I think, uh, it's a, it's a, it's a requirement to have the credibility. So you just need to showcase the business that this is actually the, this is actually the base. So yeah, the first thing I think, even if you just, uh, if you just ignore the things that I

[00:30:19] previously said is when you want to, or if the company has developer advocates, egoistically, uh, it basically gives it a business stamp that the product, uh, is good enough that some people wants to and are able to do the developer relations around the product, because if the product is

[00:30:40] useless, hard to market, hard to explain, uh, or not usable at all, nobody would do the developer relations, do the videos and articles. Right. But yeah, this is just the side note that, uh, came up on my mind, uh, before, before I want to get to the, uh, get to the case. So internally, um, you are helping the business because you saw how the people are using the product as I was,

[00:31:08] uh, when I was QA, I'm currently trying to use the product as the developer, as the integrator. So it's basically a free customer call every time you need it. Right. Because yeah, it's like, Hey, we are thinking about this. What do you think? Does it make sense? Can you try to use it? It was like, yeah, this is useless. This is useful. This is really great. And you have really, really, really nice,

[00:31:31] um, and quick, um, responses. So this is first thing for the internal one. Uh, then, and I, it's, this is probably one of the hardest, uh, one of the hardest, uh, work when you're working as a dev rel, your connection in between multiple departments. You are, and I was working under the R and D under the marketing customer, customer success management, even sales or pre-sales for a bit. Uh, currently,

[00:31:58] I'm under marketing, but I'm working with all of these, uh, departments, uh, very closely. And you are basically doing the connection in between sometimes or corrections even, right? Because every single person in our department is seeing the, seeing the thing differently. I don't say that I, I see it correctly, but I can even, I can sometimes correct the trans, uh, like information of flow

[00:32:23] because yeah, information get lost or sometimes it gets corrupted or, um, sometimes it didn't even go through, uh, all of the departments. So that's what are you doing just implicitly? Because yeah, you need to, you need to get in touch with the people. So you just share the information. So this is just the benefit of having the developer advocate, uh, in the company. So the informational

[00:32:49] flow, uh, just right or better. And externally, yeah, uh, you're the connection for the outside world. If I have the, let's say network of the people that I have met on the conference, or I have, uh, I had a talk with, uh, somewhere it's much easier to re-approach them and ask them for feedback. You don't really need to do really huge marketing if you really need to target something because you

[00:33:14] already know, uh, the specific, let's say sub channels that you might be able to use. And yeah, I can comprehend the product idea and, uh, marketing messages. So basically, yeah, the internal benefit of combining all of this information and send it out for the persona that we are aiming for. So currently it's integrators for the CK editor, right? So how to integrate it into

[00:33:38] the application with all of the benefits that product things are really cool. Marketing things are really cool. So you combine it and basically picked up the, the ones that are really important from your perspective as the developer advocate for CK editor. Wow. We packed so much into just 30 minutes there. And I suspect there'll be many people listening that want to dig a little bit deeper on some of the things that we raised today. So for people listening, wherever they are in the world, if they want to

[00:34:08] start a conversation with you, keep up to speed or learn more about CK editor, where would you like to point everyone? So yeah, I will start with me, of course. So, uh, my personal website is andre.crustina.dev. It's basically my name. So O-N-D-R-E-J dot C-H-R-A-S-T-I-N-A dot D-E-V. So this is my personal website with all my socials. I recommend LinkedIn and my YouTube. This is,

[00:34:37] these are the channels that I'm using the most. Of course, there is not everything up to date as usually with the developers, right? And for the CK editor, just go to ckeraditor.com or CKEditor LinkedIn or CK editor YouTube. These are the channels that I'm contributing the most. So, and this is where you get basically anywhere, um, uh, is the guide post. So these are the things that, uh, you should definitely subscribe to. Awesome. Well, I will have links to everything

[00:35:06] you mentioned there. Make it easy for anybody listening to find you just check out the show notes and the blog posts associated with this episode. There'll be a way of just clicking on that and getting access to everything that we've talked about today. And I just love hearing your story today, a decade of experience in bridging the gaps between a product and developers. It's something we don't talk about enough. So just a big thank you for talking about it and a language that everyone can understand today. Really appreciate you, Tom.

[00:35:35] Tom Thank you. Thanks for having me, Neil. It was really nice to talk about. It was really great. Thank you for your question, Neil. So as we wrap up today, I'm left thinking about how great technology rarely succeeds on features alone. It succeeds when the people building it feel supported, respected, and understood. And developer trust is built quietly through examples that work, tools that save time, and documentation that respects real world time constraints.

[00:36:06] Because the invisible parts of the stack, they're the ones that carry the greatest responsibility. Because when they fail, everything built on top of it starts to wobble. So here's the question I'm going to leave you with. In the products that your teams rely on every day, how much thought is really being given to the developers behind the scenes? And what would you change if their experience became the starting point rather than just another afterthought?

[00:36:33] In short, give your developers a little bit of love. Maybe watch the Steve Ballmer clip shouting, developers, developers, developers, developers. Maybe go by and do a little impression of that. But I'd love to hear what this episode made you reflect on. Please share with me, techblogwriteroutlook.com, techtalksnetwork.com. You can leave me an audio message, connect with me on social, and there's links to 4,000 other episodes. But that is it for today. Thanks for listening as always.

[00:37:01] I'll speak with you all again tomorrow. Bye for now.