Liran Haimovitch - CTO at Rookout

(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to Liran, the CTO of Rookout, and we discuss what market discovery looks like when creating new products, putting ego aside to hire people who are better than you, and Rookout's path to making software more understandable. All of this right here, right now on the Modern CTO podcast. Here we go.

(Joel Beasley at 00:00:23) This is the Modern CTO podcast. Hello, hello, hello.

(Liran at 00:00:35) Hey, Joel.

(Joel Beasley at 00:00:36) How are you, my friend?

(Liran at 00:00:38) Good. You grew a beard.

(Joel Beasley at 00:00:39) I was preparing for you. So I thought you had a beard, and I was like, let me go grow this beard real quick.

(Liran at 00:00:46) Yeah. That's what COVID-19 does to everybody.

(Joel Beasley at 00:00:50) It is. It gave us an opportunity, though, because it really opened the door to be able to grow the beard and get through the awkward initial stage without too much in-person shame.

(Liran at 00:01:02) Exactly. Actually, COVID got me the shortest beard for a while because it got so long and so messy. I had to do away with it because it became very scary on video chat.

(Joel Beasley at 00:01:15) It's hard to shape the beard. Like, as it starts to grow in, you've got to kind of figure out the style and then, yeah.

(Liran at 00:01:23) I figured going to a barber works.

(Joel Beasley at 00:01:25) Yes. Well, your beard looks really good. Your whole look looks really good.

(Liran at 00:01:29) Thanks. It's my barber. I'll send him the message.

(Joel Beasley at 00:01:34) So you just go there and you say, make me look amazing?

(Liran at 00:01:38) I have some pointers, but for the most part, yeah.

(Joel Beasley at 00:01:42) And so where are you located today?

(Liran at 00:01:44) Tel Aviv, Israel.

(Joel Beasley at 00:01:46) Excellent. So I actually have a lot of friends over there. I haven't been yet, but I've gotten to go to RSA. And, you know, there was basically a representative of Israel and a whole area at the security conference, and I got to meet a bunch of people. It was very cool to see all the technology there. This was about two years ago. But ended up making some good friends, and it's definitely on my list of places to visit.

(Liran at 00:02:15) You should. Not right now, but you should.

(Joel Beasley at 00:02:17) Not right now. So how is it—I'm curious to know actually about, like, you get to hear the international news, and you obviously get to work with some companies that are in the U.S. How has there been much of a difference between how COVID's happened in Israel versus over here?

(Liran at 00:02:36) Yeah. I mean, COVID got to Israel a bit after Europe, but before the U.S., around—I think just when Spain was getting hit after Italy. And we actually got—we locked down things pretty hard very early on. And so we got through the first wave very easily, maybe about 10,000 people, very not too much. And then after they let things go for six weeks or so, everything got better. And then all of a sudden, they decided in two weeks to open everything back. So now we're in the midst of a very bad second wave already, and things are shutting down pretty fast. So we decided to speed things up.

(Joel Beasley at 00:03:22) Is your team mostly remote? Are they local, in-person?

(Liran at 00:03:27) So they're local, but working from home was acceptable practice occasionally, so everybody is rather used to it. It's a big difference from doing it occasionally to doing it all the time. But once you have some practice, it's not that bad.

(Joel Beasley at 00:03:45) So I'm actually really excited about your product because I think it's—I think a couple things. The first thing that I was excited about when I landed on your website is how clear you had your value propositions. They're towards the bottom, but like, this is how we help developers. But then also, you have this interesting way to explore. It reminds me very much of how when Stripe first came out, and I was trying to—you know, I was a developer, and I was integrating Stripe, and I was used to these long applications and all of these things you would have to do before you could see the interface. But with them, you could click trial or explore, and you would jump right into it without a login and be able to play with it. I thought that was amazing. And you have that similar feel on yours where you can just click Explore, and then the browser becomes the technology, and it walks you through a sample. And I think that's fascinating.

(Liran at 00:04:43) Yeah. Actually, our director of product wrote a blog post about it because, especially early on, setting Rookout up could be tricky. And we spent so much time trying to get users to feel the magic by getting them to integrate it. And then we just said that we don't have to get them to integrate. We don't have to get them to do all the hard work. Let them into an environment somebody else has integrated for them. Let them into an environment where everything is set up, best practices, everything is working, and they can just experience the magic of it without doing all the heavy work, so that they know what they're going to get after they go through all the hurdles and get everything up and running.

(Joel Beasley at 00:05:25) Yeah. It's like when you have a repo and you're looking maybe for a JavaScript feature that you need to implement, and they have the GIF there, so you can see it versus just the code and you having to pull down the code and compile it to see what it looks like.

(Liran at 00:05:40) Exactly. If you're going to pull that repo, it's probably going to be a lot of hard work to get everything up and running exactly the way you want it. But giving you a sense of what you're going to get before you dive into it gives you a lot of motivation. It firstly confirms it's right for you and gives you the motivation to go through the hard parts.

(Joel Beasley at 00:05:59) So how did you come up with this idea?

(Liran at 00:06:02) So early on, about four years ago, as I was actually leaving cybersecurity and deep diving into dev tools and DevOps, I read a whole bunch of books and articles. And one of them mentioned—I think it was the book by Mary Poppendieck—and she said that an organization can be measured by how fast can they deliver a single line of code. And it kind of shocked me because, on the one hand, I completely agree. How fast can you deliver code? How fast can you change the code? That's a huge—that's going to make a huge impact. That's a big KPI. But on the other hand, changing a line of code, sometimes flipping a single bit—I mean, that's a huge obstacle. There's a huge cost you're going through. You write a single line of code, and then you have to get it tested. You have to get it approved. You have to restart a whole bunch of servers, sometimes hundreds or thousands of servers. And all you're essentially trying to do is flip a bit or add a line. And so we kind of figured that there might be a better way, that we could bypass much of this complexity and unnecessary complexity just before all you want to do is just read a variable value or add a log line.

(Joel Beasley at 00:07:19) That's pretty cool. So did you—were you—did you build this while working on another project to assist you, and then you extracted it out? Or how did you come up with it?

(Liran at 00:07:30) So about four years ago, I left my previous job, and I figured I want to build my own venture. I thought I was kind of growing older, and I don't know, I had this go now or never moment. So I figured dive right into it. Spent about six or eight months looking for a partner, looking for an idea. And then that kind of hit us. We were meeting a lot of tech leaders from various industries, various positions. And we saw for all of them, orchestrating, delivering code was a challenge, whether it's delivering to production, but often delivering code to staging and development environments is just as challenging. A lot of modern technologies are very production-first, and so it makes development environments hard. I mean, in a microservices environment, setting up everything on your laptop is not always possible. Debugging in Minikube or MicroK8s is not easy either. And so we kind of dove right into it and figured we know how to build a tool that will make it better. We know how to build a tool that will make it possible for you to change your code and collect information from it on the fly without going through the traditional software development CI/CD cycles.

(Joel Beasley at 00:08:50) That's really interesting. So the example that you have on the website is a JavaScript-related example, but would this work with Ruby code?

(Liran at 00:09:00) So we don't yet have Ruby support. We have support for anything running on the JVM: Java, Scala, Kotlin, Clojure, and so on. There's support for .NET, Node.js, including transpiled TypeScript, CoffeeScript, and so on, and Python. We are aiming to add Ruby, Go, and potentially PHP over the next year or so.

(Joel Beasley at 00:09:23) That's exciting. So, like, as a—my background, you know, I've been writing code for like seventeen years, and I'm always curious to try to bring it back to my experience so I can better understand it. So, like, if you make a change to some data, right, like how you had an example, you're making some changes to some data—how do you—is it specifically for debugging? Are you actually changing the line of code in the file? Or is it for the debugging process?

(Liran at 00:09:58) So there are two portions of it. From a technological perspective, we're using bytecode manipulation and other similar techniques to impact the application code. We literally edit the application code in memory on one or more servers to conform with your needs. But on top of that, we've built a dedicated experience that focuses on debugging and even more so on software understandability, getting you to know what's going on in your code. And so we've built a whole lot of scaffolding around that use case, whether it's enabling you to select the right servers, setting the conditions that will get you the data you need, putting a lot of security and performance safeguards that are going to ensure you can use this technology very safely in production. Because once we allow you to change the application, then that's where risks come in. And that's where actually a lot of the stuff we're skipping, such as unit tests, make a lot of sense because you're making a change and testing it can be hard. But we guarantee that the changes you make with Rookout are not going to impact your application at all. They're not going to change the logic. They're not going to change the correctness. They're not going to change the performance or the availability. So we kind of take away all of those concerns for you. We take care of them, and you can just enjoy getting the data you want from any line of code.

(Joel Beasley at 00:11:24) That's really interesting. Well, okay. So I've got a lot of questions because I'm excited about this. So the first question I have is when you're talking to CTOs or technology team leads, what do you list as, like, what's valuable to them? Like, why would they want Rookout?

(Liran at 00:11:47) So, actually, I've written quite a bit about it over the last few weeks. At the end of the day, software is man's creation. We can make it do almost anything we want with the exception of a few problems such as the halting problem. But within boundaries, we can do literally anything we want. The trick is that the software becomes more complex because we get more requirements, because the team scales, the software scales. It becomes more complex and becomes harder to understand. And so quite often, we are limited in our ability to deliver high-quality software fast by how well do we understand our own system. How do we understand what we've built, or how do we understand what the people who came before us built? Especially in larger organizations, software gets handed off, and somebody five years ago, ten years ago wrote a piece of code. Now you get to maintain it. You have to update it and improve it, and you might not understand it as well. And that's what's blocking most software teams in large organizations. How well do they understand, and how can they make the change—how do they know which changes to make to achieve their goals? How can they make those changes in a way that's not going to have a negative impact on software quality, on software performance? And Rookout takes away much of the pain in understanding because, traditionally, you understand by adding logs, by adding metrics, and that's a time-consuming process that comes with a lot of risk and a lot of effort. And so many organizations are kind of struggling. Do I fly slow? Do I fly blind? And neither choice is good. Rookout allows you to get the data you need when you need it, where you need it, from it, instantly.

(Joel Beasley at 00:13:30) I like it. And it's obviously attracting a lot of attention. I looked you guys up on Crunchbase, and you got Cisco Investments and some other really big names as initial investors.

(Liran at 00:13:41) Yeah. Cisco, as I'm sure you know, Cisco is shifting left. They are moving from hardware to a more software subscription-based licenses. They've acquired, two and a half years ago, AppDynamics, which is an APM company, one of the leading companies in that market. And there's a great synergy between where Cisco is going and what Rookout is offering. And so Cisco invested in us. AppDynamics have started reselling Rookout under their own brand to their customers. And we're seeing a lot of synergy with a lot of other players in the market as well. Data collection is critical to so many things everybody's doing, and Rookout is just making data collection so much easier for everybody.

(Joel Beasley at 00:14:31) That's exciting. Now you've got, like, in the market, you've got these tools that allow you to do diagnostics and metrics and monitoring. You know, you've got things like New Relic. You've got things that capture errors with session data so you can replay it. How do you fit in amongst all of these areas?

(Liran at 00:14:54) Most of those tools are about monitoring your software. It's about knowing the software is up, and it's about knowing when it's doing something unexpected. Now Rookout is different in a few ways. First and foremost, even though Rookout is production-grade and almost all of our customers deploy us and use us in production settings, they actually use us four or five times as much in non-production environments: development, staging, QA, whatnot. And the thing is, in a development environment, you don't expect the software to run properly. You expect the software to fail in a development environment because it's development. And so just knowing that software has failed is not as valuable in those environments. It's a lot more about knowing why the software has failed or why is it behaving the way it's behaving. And that's kind of the magic of Rookout. Most of those other tools focus on providing you with predefined data that's going to provide you with some insights into what's going on, but you don't have a lot of flexibility. They're going to give you what they give you. And either you have no control over it, or you can only control it by adding more code and redeploying. Rookout is the only tool out there that provides you with full flexibility over what you're going to collect in real time. And so you can collect additional data instantly.

(Joel Beasley at 00:16:15) I love it.

(Liran at 00:16:16) Besides that—thank you. Besides that, we're seeing that most of those tools are serving DevOps, SREs, ops. They are serving people who care: Is the system up? Is it running? Is everything working well? And you see that most software engineers who are developing software don't care about those questions as much. It's not their problem, so to speak. I mean, they do care. They wrote the product. It should work. But they are not the ones waking up in the middle of the night when things don't work. And often their tasks will rely on—they usually ask a different question every day. A software developer gets a new task every day, every week, and so they ask a different question. Instead of asking, is latency good? Is uptime good? Is everything working? They're asking about this component this day and then the next component the other day and the third component the day after that. And so the data they need keeps shifting, keeps changing. And Rookout enables those developers to shift the data they're collecting instantly as their needs change.

(Joel Beasley at 00:17:25) Let's give an example. Okay? Let's say, like, so we have a leadership software, and let's just pretend it's written in a language that yours supports because it's written in Ruby. But it does have a JavaScript front end. But so let's say that it's all written in one of the languages that you support.

(Joel Beasley at 00:17:47) And can you give me a specific scenario that would happen where I would need to go use the tool?

(Liron at 00:17:55) Sure. You're editing a piece of code. You're adding a feature, and the function you're writing accept two arguments, x and y. What are the types for x and y? What are the values for x and y?

(Liron at 00:18:08) And if you wrote the code, especially if you wrote it last week, then you probably know the answer to that question. But if you wrote the code two years ago or if the founder of this venture you were in and got acquired by Microsoft wrote that code, then you might not know the answer to that question. And that's gonna be a struggle for you. I mean, how do you change a function when you're not sure? It can be a minor thing.

(Liron at 00:18:34) I'm expecting to get a number. But is that number in string format or numeric format? Is it a float or an int? The whole bunch of questions. Even in Java, it's a polymorphic class.

(Liron at 00:18:47) What's the specific type of the class? What's the values of the class? Who is calling that function? And, I mean, as developers, we're tackling those kind of questions on a daily basis. And some of the customers we are working with are saying that it can take so long to add a log line to answer that question.

(Liron at 00:19:08) They're not gonna bother because it's too expensive. They're gonna take a guess or they're gonna try and make something that works with whatever case is gonna go. They're gonna do three times as much work because they just can't get the data.

(Joel Beasley at 00:19:24) That's true. Yeah. You know, it's interesting. Like, you imagine that all the companies out there are doing best practices. This is kind of off topic, but you imagine, like, all the companies are doing best practices and very patient with their code and better than you as an engineer. And then when I've gotten to go out and meet teams and explore, it's not the case.

(Joel Beasley at 00:19:53) It's like most of the developer teams are average. They try to implement the best that they can, but I definitely see the use for what you guys are doing.

(Liron at 00:20:04) You know, it's even more than that. I mean, when you think of the most commercial software out there, the software that's making money for people, the software that's making money for companies, that software wasn't written two years ago with ECMAScript 2018, and everything's fine. That software was written with Java Enterprise Edition. It was written on mainframes. It was written with PHP, and that stuff still has to run.

(Liron at 00:20:29) I mean, when I was a junior engineer, I joined a project which was written by people. I only got a glimpse of them. They left the company long before I joined. And the people who were my seniors and left shortly after I joined said that some of the people wrote that project were the brightest people they ever met. And in what little I met them, I definitely agree.

(Liron at 00:20:54) And yet, ten years after they wrote that piece of code, nobody understood it. It was complex. It got layered over time after time. And we could barely understand that piece of code even though it was written by some of the brightest people I know. And that's the nature of software.

(Liron at 00:21:12) It grows. It becomes complex. It becomes layered over time after time. It gets misused or reused. And at the same time, that's the software that's actually making money for the world, actually bringing value.

(Liron at 00:21:25) You can't just ditch it because we want to develop in fancy new JavaScript or whatever. And that fancy new JavaScript you're writing right now, if it's gonna make money, somebody fifteen years from now is gonna be maintaining that and complaining about your code.

(Joel Beasley at 00:21:41) That is true. That's true. I love it. I like this concept. It's actually something I feel because a lot of the projects I've done in life were takeover projects.

(Joel Beasley at 00:21:54) You know? It's like a company, you know, it needed to scale or it wasn't just wasn't good, and they knew it wouldn't scale, so it'd have to be rewritten or whatever it may be. Your developers just left, like, entire companies went out of business and we inherited their code and had to improve it. And this concept that you're speaking to, I'm trying to wrap my mind around your product because we talk about debugging, but there's this concept of debugging and then there's this concept of understandability, and I can see both. I completely see the junior engineer who got a project that the senior engineer is working on the new thing, and they're like, alright.

(Joel Beasley at 00:22:31) We just need a small bug fix over here on this old legacy project. Just give it to one of the junior engineers. Let them spend twenty hours trying to figure out one thing that needs to change. And so that process of understandability is not something I've heard a whole lot discussed as far as, like, I've heard it discussed in, you know, best practices or if you're reading a Martin Fowler, if you're reading some engineering people. I hear understandability talked about there in reference to writing code. But in reference to, and that's usually in reference to writing new code or the code you're currently working on.

(Joel Beasley at 00:23:05) But when the conversation switches to understanding older code, understanding legacy code, that's something that I don't think there's a lot of products built around.

(Liron at 00:23:15) That's true because by nature, most software tools out there were not meant to be adopted for all projects. I mean, everybody is speaking of Kubernetes and Kubernetes is hot, but most projects aren't being migrated to Kubernetes. And you hear of legacy projects. They are usually migrated through lift and shift. And down the line, some of them may get rewritten in more of microservice architecture or whatnot.

(Liron at 00:23:43) Refactoring in architecture is a huge undertaking. In fact, you mentioned Martin Fowler. He gave this amazing talk a few years ago. I watched it on YouTube about the meaning of the word architecture and what it means in software engineering. And the word architecture literally means how to change.

(Liron at 00:24:00) That's the literal meaning. And so when you're speaking of changing the architecture of your softwares, changing the architecture of your application, you know, by definition undertaking a big task, an expensive task that may not repay for itself. And most tools out there, I mean, shifting an application from a SQL database to a NoSQL database, shifting from a monolith to a 12-factor application, those are expensive tasks, and they might benefit some application, but they can't always be justified. And quite often, we have to make more with what we have without pipe dreaming about what we're gonna do someday.

(Liron at 00:24:43) And there is definitely room to improve there. Software engineers are also always trying to rush for the next big things, whether it's rebuilding the application from scratch and using new technologies. And nobody likes old code. Nobody likes maintaining. And yet that's where the value is.

(Liron at 00:25:02) Because if you're writing a new application, there's a big chance no one is ever gonna see it. But if you change a line of code in an existing application, maybe a million people are gonna see it tomorrow.

(Joel Beasley at 00:25:14) That's true. That's interesting. You know, it reminds me of this conversation I had. Some CTOs were asking me when I was visiting their offices, how do they keep their engineers excited, engineers that are working on old code? Like, how do they keep them excited? Now I have an answer.

(Joel Beasley at 00:25:32) I'd be like, buy Rookout.

(Liron at 00:25:34) Actually, that's funny, but it's true. I mean, we had quite a few corporates. When you're in corporates, then you are obviously often maintaining old code. And as I mentioned, most cool new software out there can't easily be adopted. I mean, you can't just change the database. You can't just change the architecture.

(Liron at 00:25:55) But giving them new toys to play with is definitely an option. Whether those toys have real business value or not, I like to believe Rookout does have real business value. And so we're actually seeing some corporate customers that are really excited about being able to get a new shiny tool that's gonna make their lives better without having to rework the entire architecture, without having to wait a decade for the new technology to make its way to the enterprise. Because installing Rookout is so easy. You can do it in twenty or thirty minutes no matter what architecture you're running on, no matter if you are running on the cloud or on prem.

(Liron at 00:26:36) And so it's fun.

(Joel Beasley at 00:26:38) So when you met, I wanna take it back a little bit. When you met your cofounder, you have a cofounder, correct?

(Liron at 00:26:44) Yeah.

(Joel Beasley at 00:26:45) Yeah. So you described earlier that you spent, you left your job, you spent a couple months, six, seven months exploring ideas and meeting people and things like that. What was the day like that you met your cofounder?

(Liron at 00:27:01) I actually met my cofounder a long time ago in the army basic training. He was one of our instructors in a cybersecurity training. But fast forward ten years later, I was actually at the gym. I had a very, very bad day at work, and I was thinking of quitting. Actually the day before, I was sitting with my brother, who was my roommate at the time, watching TV.

(Liron at 00:27:26) And we were like, I'm not sure how to get started on job hunt. And then I met him at the gym. He asked how I'm doing. I said, I'm thinking of getting a new job. And so we went for a beer a few days after and started discussing it, looking for jobs, building companies.

(Liron at 00:27:45) He was working on a different project, which he canceled a few months after that, and then we started, after being in touch for a few months around various projects we considered, we started working together.

(Joel Beasley at 00:27:58) That's pretty cool. And then how did you narrow it down to building this product?

(Liron at 00:28:02) So we met a lot of software engineers and, as I mentioned, tech leaders. We had about 20 or 30 of those over two or three months. And in the beginning, we had virtually no idea. It was kind of very market discovery in startup style. We know we were thinking of the DevOps space because we felt we're somewhat familiar with it and it seemed like a good space to raise funds and build a company.

(Liron at 00:28:30) And we started asking people what's DevOps for you, what's your pain. And during those first meetings, we came up with five different ideas every day, and then we threw them out the window the next day. And we kind of narrowed it down to a handful of ideas. One of them was cost reduction, which we felt wasn't that interesting, and we were wrong. I mean, at the time, Spot Instances were already pretty big, and we weren't sure there was room for anybody else.

(Liron at 00:28:59) Now I know there's plenty of room in cloud cost optimization, and they've done really well for themselves. And the other thing was the problem I mentioned to you. How hard it is to get a piece of data, how hard it is to push just a single log line to production. And as we drove deeper into that problem, we kept feeling there is something the world is missing, that we have a solution to this problem. We know how to do something that for some reason nobody else is doing.

(Joel Beasley at 00:29:31) I love it. So you met with these people. You met twenty, thirty people, developers, exploring the DevOps space. You come up with a bunch of ideas after every conversation that you're having, and then you notice that there was this trend with how hard it is. Like, that trend kept coming up in all your conversations about how hard it is to get a single line into production.

(Liron at 00:29:52) I would say that the thing is when you're doing market discovery, in general, when you're trying to learn, early on in the process, you're mostly asking questions and you learn a lot every meeting. But then later on, hopefully, as you start to narrow things down, you can actually predict how those meetings are going to go. You can actually expect the person to fall into one or two or three or four categories and give you the spiel you already know. So we came to expect what's gonna happen, and then we got to the point where we could convince about half the people we met in the validity of the idea. And that's without having any proof of concept, without having any mock ups.

(Liron at 00:30:38) We're just asking them if you could push a single log line into production without going through CICD instantly. Would that help you? And the answer was yes for over half the people we met. And that's huge. I'm not sure how many in the audience have tried to pitch an idea to somebody, but getting people to buy in to an idea without having anything to show for it, I mean, that's big.

(Joel Beasley at 00:31:05) But it's useful because when you figure that out, that line or that sentence, when you figure out what that value is, then it makes it really clear how to begin building the product.

(Liron at 00:31:18) Exactly. Once you know what people are looking for, that's when you should start building. Because if you're building something you don't know how to sell, then there isn't much point in building it, at least not yet.

(Joel Beasley at 00:31:32) So what does your team look like today? How many people do you have on your team?

(Liron at 00:31:37) So Rookout is almost 30 people. We're about half and half between tech and business. Business is comprised of a marketing team, a sales team, a lot of solution engineers, working with our customers hand in hand, guiding them, learning from their experience and occasionally helping them. I was surprised by how hard it is for customers to understand, even to keep track of their own environments, how hard it is to be proficient. I mean, you have a cloud and you have orchestration and Kubernetes and CICD and Jenkins.

(Liron at 00:32:14) Everything adds up. And for many companies, just keeping on top of all those tools is quite a challenge. And so having our solution engineers who are proficient with all those concepts and technologies is a huge boon working with customers. And we have our tech team with engineers, both, a lot of engineers working on our SaaS offering, delivering the user experience and the platform, the enterprise readiness, and we have a small team working on the SDKs, the agents that get installed on customers. We have a very strong DevOps team.

(Liron at 00:32:56) We are delivering software on daily basis multiple times a day. And we have the product and the UX team. So a little bit of everything.

(Joel Beasley at 00:33:04) Nice. What are you really excited about?

(Liron at 00:33:08) So it's amazing seeing this idea come to life. It's amazing seeing a team so talented and dedicated to working on it and pushing it forward. And it's always amazing seeing new customers deploy the product and seeing them benefit from it. And yet something I think one of the things I like the most is those first day meetings with customers. The very first meeting when they just see the product for the first time, and they're like, that can't be so.

(Liron at 00:33:44) Why didn't anybody tell me before that it was possible? That can't be possible. And I've seen so many jaws drop literally. It's so fun just seeing the impacts the product can make and seeing how much of pain each and every one of us has gone through understanding code, debugging during our careers, and how much such a tool can save for so many people.

(Joel Beasley at 00:34:13) Well, I'm a fan. Thank you. Do you, you said you read some Martin Fowler. He often is, you know, very, like, one of the greatest writers in software engineering alive, right?

(Joel Beasley at 00:34:28) Now, I'm curious. Do you follow anybody for like leadership content, like the human side of leadership?

(Liron at 00:34:35) So I read a book, and look, I don't remember the author. I think it's called The Manager's Path. I had to admit I don't remember who wrote it. I think it was a woman. Yeah, her name. And I'm sorry, man. That's an awesome book. And one of the things I read about it, I read that book when I was at the point of my career when I was a manager of managers, which is fairly late as careers go. And nice thing about it, she starts off with you as a junior software engineer.

(Liron at 00:35:12) What are your roles, and what should you do to manage yourself, to manage your relationships, to manage your boss as you grow from a junior engineer to a senior engineer to a manager to a manager of managers and then up to leading engineering and the agnostic title of CTO, which I currently hold, which doesn't mean much and yet means everything at the same time. And it was really interesting reading it, thinking back of my days earlier in my career as well as trying to predict forward and learn how to be better.

(Joel Beasley at 00:35:54) Do you recommend that book to your team?

(Liron at 00:35:58) So books are somewhat controversial these days. I find that most people aren't as appreciative of reading books as I am. So I'm not often recommending books, but it's definitely something I would recommend to anybody who likes reading books. And I did recommend it to a few folks who were asking about either career progression or what do I do as a manager in tech? So it's definitely an amazing book. And obviously, the other book which I'm a big fan of is The Phoenix Project.

(Joel Beasley at 00:36:30) Oh yeah, that's a good book.

(Liron at 00:36:32) Yeah. Besides having a somewhat better storyline than The Goal, which was wholly boring, though very useful by itself, it really brings to life—and one of the things I like the most about it is that you can bring it to non-technical people, and they get a grasp of the DevOps movement and even some of the challenges Rookout is trying to change because we're essentially skipping many of those very hard to manage processes.

(Joel Beasley at 00:37:01) And so what do you do with growing your team?

(Liron at 00:37:05) Oh, that's a good question. So actually, these days, I brought on a VP of Engineering, VP of Research and Development who's managing tech on a day-to-day basis. And to be fair, he's probably a much better manager than I am. I hope he's listening to this. We were actually team leaders side by side, and he grew and kept going his career and managed more and more people and got more experience in it. While I went down another path, I founded the company, did some more hands-on work, found myself taking on more tasks in marketing and speaking, even in sales occasionally. And he was focusing much more on managing people. And I think that as a CTO, especially as a founder, at some point—as I mentioned, CTO is a very broad and all-meaning title—and at some point, you often have to let go of managing people because you might not be the best person to do it. So he's the one who's doing most of the managing day to day of the engineers. And both for him and for me, it's very important to develop people, allow them to express themselves, allow them to learn, to grow, to learn from each other, but he's the one managing it day to day.

(Joel Beasley at 00:38:34) Nice. I'm a big fan of hiring people who are better than you and then letting them do something that they're really great at. Because at the end of the day, I mean, we're trying to build big companies and be very useful, and you're going to need a lot of great people on your team that can do all of these different things. And then you're also going to need a lot of self-awareness on what you're good at and what you enjoy.

(Liron at 00:39:00) Yeah, definitely. And I would have to say that as an engineer, as a manager, as a big engineer, hiring people who are better than you is one of the most challenging things, but it's also one of the most important things as a manager. It's very hard from an ego perspective often, but it's the right thing to do. Find people who are better than you. You can't be the best at everything. And in fact, you don't have to be the best at anything if you just hire very good people.

(Joel Beasley at 00:39:29) Yeah. If you think of yourself like the coach of the company, you just want the best players on your team. Right? You just need to collect the greatest people and ensure that their objectives and alignment in life is in line with what you can offer them so that everybody's driving towards the same goal. And then when you have that, you get this nice momentum being built and, you know, you raise money from Cisco and then you take over the world.

(Liron at 00:39:58) Yeah. At some point, we'll be building Skynet, but that's in the future.

(Joel Beasley at 00:40:03) I think Elon Musk is a little bit ahead, but he might use Rookout to debug Skynet.

(Liron at 00:40:10) It's a race I'm willing to go for.

(Joel Beasley at 00:40:13) Yes. Oh, I like you now. You're on my team. I like to read the books, the life stories of billionaires so I can figure out how they think and so that I can have an edge up on competition with them.

(Liron at 00:40:25) Yeah, let's see who gets the biggest kind first.

(Joel Beasley at 00:40:29) Right. I like it. I really like the way you think. I like your style, my friend.

(Liron at 00:40:35) Thank you. I like you too.

(Joel Beasley at 00:40:37) What do you do for fun? How do you relax?

(Liron at 00:40:40) Oh, a few years ago, it probably would have been a lot of scuba diving, which I haven't been doing lately, and trekking. These days, it's working from home, reading, some computer games occasionally, which is interesting because actually today, with COVID-19 breaking out, some of our best customers are gaming companies, which is a bit of a dream come true. And I mean, so many of those companies are growing like crazy. I mean, online play is going through the roof. Everybody's stuck at home. And so many of those companies are trying to scale up their infrastructure. They're trying to deliver new features. They're trying to make the most of what they have. And every small bug they can fix is costing them money. Every new feature they can deliver is making them money. And so we're seeing a lot of success working with those companies and enabling them to do more and deliver more value. And it's a bit of a dream come true. You know, as a kid, I always dreamed of developing computer games, and I never got around to it. And yet, working with those companies and providing them tools, bit of closure.

(Joel Beasley at 00:41:54) Yeah. It's nice to be able to be in the area of your dreams. Right?

(Joel Beasley at 00:42:01) It's interesting. My daughter is three years old, and we gave her an iPad thing. It's not an iPad, like the Amazon Fire tablet or whatever. And there's a kids app, and you go into the kids app, and it kind of freezes the screen a little bit so that the kids only stay in that app. And she—there's games and kids YouTube and all this different stuff she can do in there. And I was watching over her shoulder the other day, and I mean, this girl isn't even completing full sentences, and she's navigating, playing a game, playing one of those games where you press a square and it'll show you an image and there's nine squares and you have to find the two images, you know. And she's playing this game and then she wins it. She goes into another game, plays that for a little bit, closes it out and goes and starts watching one of her baby videos that she likes. And I'm like, what is this? This is unbelievable. She's turning three in September. You know?

(Liron at 00:43:03) Yeah. Yeah. You know how you teach machine learning by incentivizing and letting the machine know what's good and what's bad? So it's the same with people.

(Joel Beasley at 00:43:11) Yes.

(Liron at 00:43:12) So they figure out how to get more of them.

(Joel Beasley at 00:43:16) Do you have kids yet?

(Liron at 00:43:17) Not yet. I have a dog.

(Joel Beasley at 00:43:19) You have a dog. Yes. The kids are definitely, like, as a technologist, it's fascinating to watch because it's like textbook AI, organic algorithm inside of a human. It's just unbelievable. Like, when you watch them actually learn over three days how to stand up or how to get food in their mouth correctly. You can just see the trial, the failure, and then the success, and then repetition, and then they get it. It just happens so fast. It is like machine learning right in front of you. It's unbelievable.

(Liron at 00:43:54) Yeah. It's crazy. I mean, in general, the fact that people can move in so many ways, often so fast for better and for worse. I mean, it's crazy. Kids especially.

(Joel Beasley at 00:44:08) Yeah. I think, like, when talking about kids to dogs, I think one of the big differences is, other than the species, I think one of the biggest differences is the kids have this drive to figure things out and to understand. So they're just constantly, especially when they can walk, they just move from one thing exploring to another thing exploring. Whereas our dog will just kind of hang out and be happy and eat. But they're not constantly driven to explore and understand.

(Liron at 00:44:38) Yeah. Dogs are so much easier to make happy than people. So much easier to satisfy. I mean, give them some food or take them out. They'll be wagging their tails and happy all over the place. People are much harder.

(Joel Beasley at 00:44:53) People are very hard because they're very complex. Like, I thought it was interesting. The other day, I accomplished some goals that I've been working towards a long time, and I was actually a little bit sad about it because it's like, okay, well, now I've got to—you know, I achieved it. The journey is so much fun. Right? And it's important to have goals set up along the way so that you don't run out of goals.

(Liron at 00:45:20) So many people don't understand, but if you're suffering just to get some goal, then you're probably doing it wrong. I mean, not many goals are worth suffering for. And often when you actually achieve that goal, it's a very bittersweet moment.

(Joel Beasley at 00:45:34) Yes. And then it also teaches you a lot about time because there's—you know, we've all wanted something in a short period of time and suffered for it greatly. And then I guess one of the big changes in my life was when I found this author, James Clear. He has this book called Atomic Habits, and the concept is just look at your habits and extend those out, and that's what you'll get more of. And so by structuring your habits over the course of a day, week, or a month, understanding what those yield, then you can actually achieve really large things without intense suffering.

(Liron at 00:46:18) I think, generally, as you get older, you try to manipulate your own behavior much more. I mean, when you're young, you're just trying to do your thing and maybe manipulate the environment. As you grow older, you understand that what you achieve, how happy you can be is so much more about manipulating yourself than it is about manipulating others. And you can achieve quite a lot, and you can be very happy if you just point yourself in the right direction.

(Joel Beasley at 00:46:48) Yeah. I've been learning a lot, and I think you're right too. I haven't heard someone say it like that. But as I've gotten older, I've gotten much more interested in my behavior, the results, success. It's partly, you know, maybe because of time. Right? You just realize, like, okay, you can start to understand. I think it's a weird moment when you start to—when you get around, you know?

(Liron at 00:47:33) Yeah. I found for myself it's a lot about acceptance. I mean, I've always accepted myself, but in some ways, I was always trying to improve and change myself. And at some point, you understand that brute-forcing your way into a better self, into a better life is not necessarily the approach. It's not just "I want to be better." It's much easier, much more constructive to manipulate yourself and get yourself doing the better things. Get yourself, put yourself in the position where it would be easy for you to do what you want to achieve in the first place, rather than put yourself in a hard spot and then hope you would be able to still do what it is you're trying to do, if you get my point.

(Joel Beasley at 00:48:20) Yeah. Yeah. It's almost like one's more self-destructive. Like, I'm going to put myself in a hard position to watch myself get out of it. And another way of achieving it is I'm going to create an environment where the thing I want has a high probability of success. Like, if I put myself in this—for me, if I put my running outfit out next to my bed, I have a much higher chance of running that morning than if I don't.

(Liron at 00:48:51) Exactly. So you can go and say, "I want to run every morning," or you can spend two minutes before you go to bed to increase the chances that come morning, you'll go out running. And it's much more productive doing it the second way.

(Joel Beasley at 00:49:05) Yes. It is. And then it's weird because it brings up this whole area of life about how important the environment is, your environment around you. And it's like, you know, you put good food in your fridge and you don't buy bad food, then you're going to choose from your available option. You're going to eat better. Right?

(Liron at 00:49:26) Exactly. And the same goes for your work. Choose a good boss. Choose a good tech. Choose a good company with a good work-life balance. You're going to have a good work-life balance. Choose a company with a bad work-life balance and try to fight through it. You're probably not going to succeed. And even if you do, it's going to be a struggle every step of the way. Figure out what's important for you and put yourself on track to get it.

(Joel Beasley at 00:49:53) So for you and your co-founders and this company, what are some of the things that are really important that you like to see in new hires on your team?

(Liron at 00:50:02) So we like to see learning both in oneself, being able to teach oneself and facing challenges and learning through them, as well as learning from the team, knowing that I'm probably not the best in everything I'm doing. And there are people out there who can teach me. And even if I'm the best at something, there is still more to learn. Maybe even somebody who's not that good at something still knows something I don't. And just the same, we want them to be passionate about teaching those around them. And I think in a way, teaching brings camaraderie. There is nothing that brings people close as teaching each other and going through challenges and showing the knowledge and learning. And so, I mean, it's really, especially in a startup, but in every company, it's all about learning. In every society, it's all about learning.

(Joel Beasley at 00:50:57) I like it. Yes. Man, it sounds like you're going to have a really big company soon. It's going to go right to the top. You're building something that's very useful. You've got the right partners in the business. You found the product, did your market discovery. You're building with the correct culture. I'm real excited for you in the future.

(Liron at 00:51:22) Come join us sometime. Yeah.

(Joel Beasley at 00:51:26) You know, when all the lockdown stuff's over, I really do have quite a few people in Tel Aviv I need to go visit. And I haven't gotten to go there yet, like, ever. So I think it'd be a good trip out there.

(Liron at 00:51:38) It has some of the best bar and food scenes in the world. So you're the chef.

(Joel Beasley at 00:51:44) Is it different styles of food, or what type of food is it?

(Liron at 00:51:49) So there's quite a bit of everything. I think that the thing I appreciate the most about food is that you can always get it. And even from what I found, especially in Europe, you can only get food up until a certain hour at night. And after that, it's kind of—food is out of the window. And also, you don't have—it's either—there are places you eat and there are places you drink. And in Tel Aviv, you can do everything at the same place, and you can—some of the best places are open up until midnight, and you have some of the bars that serve awesome food. And there's just everything. There is craft beer. There is great wine, locally imported. There is awesome cocktails. There's a whole bunch of stiffer drinks, food from all over the world, and a lot of local stuff. So it's just fun.

(Joel Beasley at 00:52:41) I live in a retirement town. So I live in Florida in a beach city. And so the most amazing thing to me is when I get to go to New York or San Francisco or Boulder, and I go in the grocery stores, and it's just a bunch of, like, 30s, 40s, and 50s. And then when I come back home, I go to the grocery store.

(Joel Beasley at 00:53:08) I feel like it's a nursing home.

(Liron at 00:53:11) So we also have a beach in Tel Aviv. We don't have that many nursing homes.

(Joel Beasley at 00:53:17) So it's a good average age? There's some nice middle-aged people there?

(Liron at 00:53:22) Yeah. It's mostly people in their twenties. It's somewhat of a college town, somewhat of an army town, somewhat of a lot of young couples, a lot of young families.

(Joel Beasley at 00:53:32) Nice. Sounds like a blast. I look forward to it. When I go out there, I'll let you know, and maybe you could show me some places to eat or drink.

(Liron at 00:53:40) Definitely.

(Joel Beasley at 00:53:41) Now as we start to wrap up, were there any points that we didn't discuss? I know you have a free trial version of Rookout.

(Liron at 00:53:50) Yeah. So Rookout, we have a free trial. It's actually free for a single person. So you can always go online and sign up and use it for free on your weekend project or your garage next big thing. We have very flexible pricing plans for small teams up to very large enterprises.

(Liron at 00:54:10) And so reach out to us, to me, to the team online, and we'd be happy to assist you.

(Joel Beasley at 00:54:17) Nice. I like your brand too, because I was looking at your LinkedIn stuff that you've shared. You've got some good content. You write a lot. You're actually a very good writer.

(Joel Beasley at 00:54:29) And then there's also, like, some funny memes and stuff about, like, I was like, yes, I like these people. This is so cool.

(Liron at 00:54:37) We'll send you a sticker pack, then you'll truly appreciate us.

(Joel Beasley at 00:54:40) Yes. I will use the sticker pack. Yes. Alright. Thank you so much, my friend. I really appreciate it, and we'll talk soon. Okay?

(Liron at 00:54:49) Thank you.

(Joel Beasley at 00:54:52) 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.