Supercharge Your Business by Upleveling Conversation with Otto Hilska, Founder & CEO of Swarmia

(Intro Narrator at 00:00:00) Today, we're talking to Otto, the CEO and founder of Swarmia, about harnessing the true potential of your developer teams, his experience as a serial founder, and more. You're listening to Joel Beasley, Modern CTO.

(Otto at 00:00:19) During the summer, the sun never sets, or there might be an hour or two when it's a little bit darker. And then during the winter, there's nothing but darkness.

(Joel Beasley at 00:00:29) Oh. Where are you located?

(Otto at 00:00:32) Finland.

(Joel Beasley at 00:00:33) Okay. Are we in darkness right now, or are we not in darkness right now?

(Otto at 00:00:35) No, the sun is still shining for one more hour. So the summers are really nice, and we are at the end of the summer, I guess.

(Joel Beasley at 00:00:44) Nice. I spent some time in Sweden, and when I got over there, I forget what time of year it was, but when I got over there, I just remembered it just never really got dark. Like, it got like 5, 6 PM feeling, and then it just stayed like that all through the night.

(Otto at 00:01:00) Yeah. That's why it feels so weird to go to California, for example, because it feels always like summer, but then you don't get those Finnish summer nights where the sun is actually shining throughout the night.

(Joel Beasley at 00:01:14) That's not the only reason why it feels weird to go to California.

(Otto at 00:01:18) For sure.

(Joel Beasley at 00:01:19) But, you know, me being a curious person and reading up on what you have done, I love that you're a founder, a serial founder. You've built and sold these companies, and I was hoping that's where we could start. Could you tell me a little bit about the companies that you've already built and sold?

(Otto at 00:01:33) Absolutely. Well, my background is in software development, so I started writing code when I was pretty young. And my first company was a consulting company, so I just wanted to build software, and I figured it's going to be easier to land these exciting gigs if I'm doing it through my consultancy because no one wants to hire an 18-year-old to do something really cool. And so I actually got to work on some pretty cool stuff. For example, Nokia's Ovi Store, which is their app store. I was the first developer in a project that ended up being like a 200-person project. And so I got to see the complexity of building software pretty early, and we had teams in Vancouver, New York, and Helsinki. So also learned about the communication challenges and that whole dynamic in that complex environment.

(Otto at 00:02:29) And from those experiences, I really got started with my actual first startup, which was Flowdock, a team collaboration product. So everyone else at the time thought that Yammer and Facebook News Feed is the way to go, but we felt that chat-based collaboration probably has some kind of a future. And it seems silly right now because obviously we all know how the world evolved after that, but we were one of the first ones to claim that you could actually do some kind of a modern take on chat-based collaboration. And we got some pretty great customers. We worked with Zendesk, MongoDB, Shopify, and many other great companies. But we also got acquired relatively early by Rally Software. And they did an IPO. I learned a lot about enterprise sales and so on. It was a great experience.

(Otto at 00:03:16) And then when I came back to Finland and figured out what to do next, I had invested in this company called Smartly.io, which is in the online advertising automation space, and they had figured out a product-market fit. People really wanted to buy their products, but they couldn't quite figure out how to build it and how to make it scale. And so I joined the product development teams, and we went from 30 to 350 people over those four years. We were highly profitable, worked with the eBays, Ubers, and Airbnbs of the world, pretty much everyone who's doing advertising at scale, and built tools that allowed companies to automate their advertising strategies.

(Otto at 00:03:54) And so we got to build some pretty cool empowered product teams who were really successful at shipping great products fast, because it's a bit surprising, but ad tech is actually one of the most competitive spaces out there. Like, there's so much money to be made. Facebook and Google and everyone else is investing so much in that space, and they are trying to move really fast in building anything new. So we always had to be the one who's innovating and building something before anyone else. And so Smartly was really good and is really good at doing that.

(Otto at 00:04:28) And from those experiences, as I was always trying to bring some transparency into engineering organizations, that's how we ended up starting Swarmia. So we wanted to bring visibility into engineering while keeping it very healthy so that the developers will actually adopt these products and actually use them for driving some kind of a change. And that's the road we're currently on.

(Joel Beasley at 00:05:10) And I've seen—so my background, software engineering as well, and I remember Flowdock. I think that's pretty cool. But what's driving the demand organizationally? Because I've seen over the past, you know, three or four years, several companies come up that—I mean, we'll get into the details of what Swarmia is and what makes it unique—but I'm curious from a higher level, what's driving this demand within organizations? What are they looking for? And why are these tools the answer?

(Otto at 00:05:42) The answer is probably a little bit different right now than what it was a couple of years ago, because a couple of years ago, we were in this mode where every company was just hiring all the time, adding as many developers as possible. And at that point, the dynamic was that things just tend to slow down, and you don't have an idea of why that's going on. And obviously, when half of the company just started, that's just a very natural thing that happens because people don't know what they're even supposed to do, and there's a lot of inefficiency being generated across the organization all the time. So that was very much the situation when we started the company, and that was kind of the initial value prop that we worked with. And that's kind of where it all started.

(Otto at 00:06:23) Now it's a little bit of a new world right now, with focus more on profitability and things like that. But I think that's actually an interesting change because it means that that solution that you had available previously, which was "let's just hire more developers," that's suddenly not available. So right now, companies are trying to figure out, how are we actually doing with this? And companies are waking up to the realization that building software is pretty hard, and the lifecycle is a little bit more complex. So you just cannot think about building software in terms of shipping one more feature and shipping another feature and so on. But rather, you have to figure out how much are our teams being slowed down by the reactive work and the technical debt and everything else, and where should we invest? Like, where does it make sense for us to spend dollars on engineering so that we get something out of it and so on. So that storyline has shifted a little bit over the past couple of years, but really it's still about understanding engineering organizations in just a little bit more detail than what was previously possible.

(Joel Beasley at 00:07:45) And what's the view—because, you know, I haven't been writing code for about four years now, but before that, I did it for over 15. And so I remember seeing this trend of everybody trying to track developer productivity and focusing on different things, and a book came out that said, "Oh, focus on these things," and then all these different schools of thought. Has that shaken out yet? Is that more solid? Do engineering leaders know, here are the two or three things that I need to focus on when it comes to productivity? Or is it still all up in the air?

(Otto at 00:08:18) It's definitely a lot more clear than what it used to be five years ago. So the brief history of this space is that there was a bunch of companies doing some sort of Git analytics and trying to extract data from source code repositories because that seems like the natural place to extract stuff from. Alternatively, you could have looked at the agile metrics, like just when you estimate some story points, then you follow how many story points you shipped. And some people kind of mix that with tracking velocity, which it's not. It's really about predictability of the team's own planning, but people started to misuse those concepts in all kinds of ways.

(Otto at 00:09:04) And then really, the first kind of scientific take on this was the State of DevOps Report, the DORA research, the book Accelerate, then everything around that. And the basic thing is really simple. They finally applied some scientific rigor to analyzing these things, but it's mostly surveys. And it's really just—usually people remember the four DORA metrics and think about that. But it's really about, how do you iterate as quickly as possible while avoiding breaking things? And that's kind of the whole concept of DORA metrics.

(Otto at 00:09:36) And then there is even another piece of research that came out a little bit later from some of the partially the same authors around something called the SPACE Framework, which basically says that you shouldn't try to have a single number that you measure, but instead look at multiple things and try to balance them and try to look at this in multiple levels, different parts of the organization, and so on. So that's really the way this space has evolved.

(Otto at 00:10:04) Unfortunately, people are quite framework-oriented. So whenever there is a framework, people love to adopt it and love to talk about it. But really, what I would recommend to most people is just using common sense and understanding the principles behind these frameworks, because they are all very solid, but at the same time they are not solutions to anything. So just adopting a framework is not going to solve your problems, but it is likely a useful mental model that you should have when you're trying to figure out what's going on in your organization.

(Joel Beasley at 00:10:46) When you build these tools, you've been building teams with hundreds of engineers. What do you do?

(Otto at 00:10:51) Yeah, I usually just start by a couple of cultural principles that I want to apply. Things like having transparency, having the right kind of feedback culture, having the right kind of platforms in place so that there's this debate of how much empowerment the teams get versus where do we want to standardize and so on. And then you just keep iterating on that. And when you have some of this basic infrastructure and you have this visibility and everything else, then you're going to be able to make good decisions all the way. And that's about it. So it's really about creating your own organization that works for you and creating it from these principles and reasoning about what's an important thing to measure.

(Otto at 00:11:32) Because, for example, for us, looking at something like deployment frequency is not super interesting because we've been doing continuous deployment from day one. That was literally when I started the company, the first thing I did was talking to customers, like 30 of them, to understand what we're building and why. And the second thing was setting up a CI pipeline so that we can continuously deploy whatever we're going to be doing next. And so we've been doing that forever, and there is no point in looking at deployment frequency for us. However, someone else who comes from a different context might find it extremely valuable because that's exactly the type of problem that they solve. So you kind of just create your own way to that and figure out how to get better every day.

(Joel Beasley at 00:12:25) Tell me about the—well, I've got a question about feedback culture, but before I go there, have you seen people that look for these tools as a solution to what is ultimately underlying a culture problem?

(Otto at 00:12:41) A lot of problems are culture problems. The problem is that when it's my opinion versus your opinion, these things never get resolved, and then it's really difficult to drive change in that kind of an organization. And that's kind of the problem that all kinds of improvement stalls, and there's reasons why it doesn't happen and so on. And so the way you improve this is by having that visibility, and you're going to uplevel the conversations that you're having by not just arguing about some simple basics, but actually going to the next step and the next step of, so why is this happening and what are the facts behind this? So yes, a lot of times it's some kind of a cultural problem, but also people tend to appreciate the facts around this conversation. And so it is still often the right thing to do, even when that might not be obvious.

(Joel Beasley at 00:13:45) So what's the feedback culture? You said that's one of the first things that you make sure you get right, transparency and feedback culture in an engineering team. Explain to me what a healthy feedback culture is.

(Otto at 00:13:56) Yeah. There's different takes you can have on this. I mean, there's a popular book about Radical Candor, and then there's arguments against that kind of a culture. And you can kind of choose what kind of company you're building and what kind of feedback culture you appreciate, but then you should also try to make sure that you build your team and organization so that it's not a surprise for anyone that this is the way we operate. Because there's a lot of companies that are very direct and have these conversations about different topics in pull requests and so on. And for someone else, it might look—

(Joel Beasley at 00:14:36) I'm going to stop. Sorry to interrupt. I want to know about your company. I don't want to know about advice. I want to know, like, what do you do?

(Otto at 00:14:44) Yeah. So we want to balance the feedback in context of a few other goals that are also important in collaboration. So we talk about trust, transparency, feedback, and ownership as kind of key elements of collaboration, and it all builds on top of these principles. So, for example, trust enables better feedback culture because when you are in a trusting relationship, you take that feedback much better even if the wording is harsh or anything else. And, for example, to build trust, you have to be proactive and you have to acknowledge that trust doesn't just automatically exist. It's a human nature that the more we spend time with someone, for example, the more we are able to build that trust. And as we see that someone is delivering and doing a good job, we just automatically build that trust.

(Otto at 00:15:29) And so feedback is one of those elements, but then it comes also with counterpoints like ownership. So we also have to acknowledge that this person, for example, might own this project, and it's going to be their decision to make about whatever topic we're discussing. And so we have to give the feedback from that perspective that we made an observation, and to us it looks like this, and I would maybe do it differently, but also acknowledging the ownership piece and how that person needs to make that decision and so on. And so we talk about how you balance all of these different things because it's not trivial, and at the same time, we want to highlight things that, like, for us, it's more important to get good results than give perfectly independent ownership about everything, because there's other companies that value ownership much more, and they might not want to get feedback about that kind of things. And we just want to be explicit about how we intend to operate.

(Joel Beasley at 00:16:51) That's really interesting. I like that you brought up about how trust works. I love that visual of it's like a bank account. You make deposits, and you have your relationships and your ability to make debits and credits on those relationships. And I like that you brought that up because that learning that for me helped me develop significantly as a leader. So when, let's say a company is getting all these things right—they know their culture, their culture's working for them, they've got a group of people that have these similar core beliefs, they've got transparency, they're constantly in a state of building trust—what are tracking these metrics going to tell that company that—like, how would they identify that there's a problem? Or what type of useful information comes out of a software like Swarmia that they can actually say, "Oh, well, we have—everyone gets along. We're productive. We produce stuff. You know, things seem to be chugging along, you know, relatively on time. We've got this down." And then what would a system like Swarmia tell them?

(Otto at 00:17:57) So there's a couple of use cases that someone might use Swarmia for. And even when the company implements transparency to some degree, it's good to acknowledge that as an individual developer, for example, you have a limited view to everything that's going on. And similarly, as a leader, you have limited visibility to everything that's going on. So in a way, establishing some kind of shared language between different parts of the company will help people have a better conversation about the work itself. You can use a tool like this to recognize stuff that's difficult to see from your own viewpoint.

(Otto at 00:18:40) So, for example, figuring out why stuff takes so long. Turns out in a bigger organization there's a lot of waiting that's related to shipping something, and these are systemic issues. If you have something that would really take just a couple of days of work to do, but you have four teams collaborating on it, it will likely take you a month or two to get anything done, and that's often the reality. And so this kind of dynamic easily escapes when you look at it from your own perspective, which is just "What is my team doing? Are we getting everything done?" Well, yes, we are doing a lot of things all the time, but if you look at it from the perspective of this company initiative, for example, it might be that even though every team is doing something really important, we're not, as a company, able to make progress on certain things. There's also a lot of bias both personally and in teams.

(Otto at 00:19:37) So, for example, some developers prefer some type of tasks to work on, and some teams constantly avoid some type of features to work on because there would be a huge refactoring. If you have transparency into the organization, then you're going to be able to have a lot better conversation. And I also want to say that oftentimes, it's actually not about metrics themselves. I know when we talk about development productivity, it sounds like it's going to be all about numbers. Like, we're going to measure this and it's going to go up or down all the time. But that's actually not very exciting for most development organizations because you just want to get your work done, and you don't want to focus on this stuff that management is imposing on you.

(Otto at 00:20:34) And, actually, one of the things we recognized very early was that developers are quite excited to see the work that they just did and what they can learn from it, and what seemed to be the most difficult part about it and how much waiting there was in different parts of it and so on. Because that's about the work. It's not some kind of an abstract metric that's really an aggregate over a lot of different people and teams. And so that's one of the ways that it stays pretty exciting. And then metrics improving are just the result of doing that and getting better at what you do and eliminating the bottlenecks as you find them.

(Joel Beasley at 00:21:13) And so what are you most excited about? You've built these. You're on your third—well, you might have done other companies, but you're in this big project right now. You're building up Swarmia. How long ago did you start and where are you at today?

(Otto at 00:21:29) We started about four years ago and we're right now about 30 employees. And we're working with some great modern product development organizations that we built the product together with. And so it's definitely a good start. But at the same time, I see a lot of potential in this market because if we think about how software companies are modernizing their practices, and by the way, we're living in this bubble. We've always probably worked with the most modern companies out there and always adopted the latest best practices and so on.

(Otto at 00:22:07) And it's good to recognize that there's a lot of companies that are not doing CI. There's a lot of companies that are not doing code reviews. There's even companies that are not doing version control. Seems crazy. Yes.

(Otto at 00:22:26) But there's a huge lag in adopting some best practices. And oftentimes, these best practices are adopted in form of agile transformations or something like that. And I think that's a fundamentally flawed approach to fixing a company. Because when you do that, you're not able to take into account any details about anything. You're just going to roll out some kind of big process for the whole organization and try to teach people to follow some kind of a different process.

(Otto at 00:23:00) And it's really built from the process angle, which is such a small part of building great software products. So it's not actually going to fix many of your things. And when anything goes wrong, and we know that something's going to go wrong if you change everything for a big organization, then you're going to attribute those problems to this transformation and you're going to hate it. And so it's just not the way to go in adopting any better practices. Almost every company would just need to adopt a more incremental approach.

(Otto at 00:23:35) And to do that, you need, for example, trust so that the leadership can trust that we are going in the right direction, and the teams are able to solve whatever are the most important problems for them. But if you are the newly hired CTO of this company and you kind of need to turn it around, are you just going to hope for the best and wait for a couple of years until you're fired from that position because you didn't get anything done? It would be really encouraging to get some kind of information that we are making progress in some front. And so in that sense, there's going to be a lot of companies out there who will find it pretty interesting to adopt tools like this to accelerate their way to more modern practices. And so I think that's something that this industry really needs.

(Joel Beasley at 00:24:26) What's the hardest part when a new company is going to buy Swarmia and implement it? Obviously, in sales processes, there's all sorts of roadblocks and objections and all of that. But what's the thing that you hear the most as far as difficulty being able to bring a new product in to their company like this?

(Otto at 00:24:45) I think it's overall always difficult to do anything that changes the way, for example, developers are supposed to work or anything like that. And that's why it's been so important for us that you can always get started without changing any of your existing ways of working. So it doesn't matter that you have bad Jira hygiene and the issues are not always fully up to date and so on. That's life. That's the situation in every single company.

(Otto at 00:25:16) So you're not unique in that sense. But then as you want to get towards some results, then, of course, you need to start investing in it and driving some change and so on. And there's so many companies where the comment is always that we would love to improve things, but we have to ship a couple of things first. So the end of the year is really busy. We're going to build everything, and then it's going to get easier next year, and then we're going to be able to invest in our developer experience and productivity and everything else.

(Otto at 00:25:51) And, obviously, we know that's not the case. There's going to be new stuff next year that you need to focus on. So finding time and making the case for this kind of investments is always difficult. But then when you start doing the math and thinking what kind of upside there is available, that tends to be still a very good investment. For example, I've always seen, like, whatever investment we've done on things like CI pipelines, it's always paid itself back within the next couple of weeks.

(Otto at 00:26:23) So there's just so many investments in engineering that make sense, but there's a lot of fighting between different parts of the organization on whether you should do that. And lack of that shared language is one part of the reason that could actually help you make those cases.

(Joel Beasley at 00:26:41) How do people get started? Is there an open source version or a free trial? Or how do they get their hands on it?

(Otto at 00:26:48) Yeah. We do a free trial, also a longer proof of concept. It really only takes you a few minutes to figure out how this works for your organization, but then for the longer term, actually having those conversations and seeing things improve, that's going to take a little bit longer. But practically everyone learns something within the first hour of looking at their own data.

(Joel Beasley at 00:27:10) Like what?

(Otto at 00:27:11) What most companies will figure out very quickly is that they are working on way too many things at once, and the end result is that you're getting less done than what you would like. And this is especially true with the growth companies that are otherwise doing really great. They have a great engineering culture and they're really good at what they do. And yet, there's so much demand from the market and so many things that you would always like to do. And it's a natural reaction for people to try to please whoever is asking stuff from you.

(Otto at 00:27:49) It's always easier to say yes than saying that, unfortunately, we can't do it. But you are doing a disservice to the stakeholders by starting to work on something and then never finishing it because then you're not managing expectations properly. And as a team, you're not getting things done as well as you could. So that's one of the first learnings for most organizations—that there's too much stuff in progress and you never realized it just by looking at something like Jira. But when you finally combine all the data, how you're dealing with your Jira projects and objectives and bugs and just something you're doing on GitHub and incidents and everything else, you'll realize that it's a mess, and we need to find ways to focus.

(Otto at 00:28:35) And we need to find ways to automate this stuff so that we can focus on the work.

(Joel Beasley at 00:28:41) This is kind of separate from Swarmia, but are you seeing in the marketplace a huge adoption of the tools like Copilot or assistive coding tools, or are you not seeing a huge adoption?

(Otto at 00:28:55) Yeah. That's definitely happening. And I think it—I mean, many of our developers are playing with Copilot. I think it's less relevant for super experienced engineers that we mostly hired. But at the same time, who doesn't want their test case to be automatically completed and so on.

(Otto at 00:29:17) So there's definitely plenty of use cases and I think what we're hearing from Microsoft is pretty promising. So I think it's going to be an important tool in the toolbox.

(Joel Beasley at 00:29:27) When do you think we'll start to see how that unfolds in the marketplace? Do you think there's going to be more developers, less developers? How do you think that's going to happen?

(Otto at 00:29:39) Yeah. It's interesting, and I think this has two levels. So Copilot is maybe the more tactical level of applying AI in the developer job because it's that kind of stuff like auto-completing that test case. And, actually, it's interesting because it's not only about productivity, but it can be even about quality of the work because maybe you wouldn't have written that test case unless it was so easy to do. And so it might actually help you do things that you would have just skipped previously.

(Otto at 00:30:14) Also, it's just going to make it more productive to work on almost anything. So it's the type of improvement that we've already seen from things like frameworks getting better and so on. So it's going to just help you accelerate. What's difficult about this kind of improvement is that it just means that there's going to be more stuff to cover, and your team is going to have a broader domain to address most likely. You're going to have more features to put together.

(Otto at 00:30:42) And what Copilot is not doing for you is figuring out how are you going to put all of these pieces together and what's a good product and all of these other things. So it just means that the mental load of a team is increasing, and when you maintain that software, there's still going to be bugs in that software, by the way, even if you used Copilot. And that means that there's going to be stuff you have to figure out and diagnose more than ever before. And so getting visibility to all of your team's work might be more and more relevant in this world. And I think the other interesting area about AI in development is the more strategic level.

(Otto at 00:31:24) And I tried this with ChatGPT myself as we built some kind of an integration with Snowflake, and I wanted to see could it actually help me in figuring out the strategy for building that integration. And it actually came up with an API that I should be using and the kind of logic that we should follow for building that integration and how we're going to batch the changes and so on. So that's pretty impressive. And that also means that there's going to be junior developers who are finally able to take ownership of figuring out the technical direction of their work, which kind of makes them more senior developers. And one of the big challenges post COVID has been how junior developers are entering this market and how companies are able to onboard them successfully and so on.

(Otto at 00:32:15) So I'm hopeful that this will actually help them onboard these technical roles and approach the more senior developer skill sets a lot sooner.

(Joel Beasley at 00:32:27) Yeah. I think it'll ramp up the newer people faster, and then it'll just—one of the things I'm excited about is to see the day that comes when you've got your entire environment and all this infrastructure and these different applications. Right now, when a bug or a crash happens or something, you alert all the teams and everybody's trying to figure out what's going on. And just for that system to say, hey, this is what happened. You need changes in these three code bases to prevent this from happening again, and have the GPT system implement it. That to me is a future that is not insanely far away because it can hold so much context in its head of the environment as a whole. Where right now we spread that across teams and teams of teams.

(Otto at 00:33:18) Yeah. Absolutely. And, indeed, more of that company-specific knowledge as it exists there. It's a different thing to have a generic ChatGPT instance versus having something that knows all of your company policies. We're SOC 2, Type 2, audited. So we have certain things we need to take into account when we're building new services or adding credentials somewhere or whatever.

(Otto at 00:33:42) So when it's able to take that kind of things into account, it's going to be, once again, more and more senior developer-like in coming up with the risks and things to think about when implementing something.

(Joel Beasley at 00:33:56) What does the name Swarmia mean?

(Otto at 00:33:58) It's coming from, I guess, an agile term, swarming, which is about a team coming together to solve a problem. So that's kind of the starting point. When I started the company, I actually was able to fundraise before coming up with the name for the company, and then I figured that I have one day to register the company before we have to sign the funding agreements. And so I went through—I've come up with company names several times so I have a method for doing it—so I just came up with a lot of different words that I think would be potentially related, and that's how I ended up with it in one day.

(Otto at 00:34:43) We were prepared to change it afterwards, but we didn't.

(Joel Beasley at 00:34:47) I love it. I've gotten some good stories. One dude I talked to, I think it was Rimini Street, I think investment-type technology. He had to come up with the name, and he looked up out his window and saw Rimini Street. And he was like, ah, we'll just call it Rimini Street. And that's the name of the company. And I think that that is hilarious.

(Otto at 00:35:04) Yeah. That's one of the perks of being a founder. You get to choose the name.

(Joel Beasley at 00:35:08) You get to choose. That is one of the perks. Yes, it is. All right. So if people want to learn more, if they want to get their free trial, where do they go?

(Otto at 00:35:16) You can go to swarmia.com and get a free trial. We also have a new podcast, Engineering Unblocked, where Rebecca Murphy is interviewing engineering leaders. And we have a new book coming out called Build: Elements of an Effective Software Organization. So we've turned some of this thinking into a more longer-form content piece.

(Joel Beasley at 00:35:39) Oh, nice. And the podcast is already out today, so people can go check it out?

(Otto at 00:35:44) Yep.

(Joel Beasley at 00:35:44) And then is the book in presale or is it something that's coming soon?

(Otto at 00:35:49) We have the first couple of hundred copies distributed to a selected group of friends and family, but then we're doing a bigger print later this year.

(Joel Beasley at 00:35:57) Oh, cool.

(Joel Beasley at 00:36:00) Well, let us know when that comes out. I'll give you an Amazon review.

(Otto at 00:36:04) That's great.

(Joel Beasley at 00:36:06) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.