Episode 428 ·

Kubernetes-Native Troubleshooting with Itiel Shwartz, Co-Founder and CTO at Komodor

Today we’re talking to Itiel Shwartz, Co-Founder and CTO at Komodor. And we discuss how Komodor tracks changes across the entire Kubernetes stack. How to surround yourself with people more talented than you, and how to facilitate open and transparent communication in your teams. 

All of this right here, right now, on the ModernCTO Podcast!

To learn more about Komodor, check them out at https://komodor.com

About Itiel Shwartz:

CTO and co-founder of Komodor, a startup building the next-gen troubleshooting platform for Kubernetes. Worked at eBay, Forter, and Rookout@first developer. Backend & Infra developer turned 'DevOps', an avid public speaker who loves talking about infrastructure, Kubernetes, Python observability, and the evolution of R&D culture.

About Komodor:

Today's microservices systems are complex, distributed and they are constantly changing. Keeping track of so many moving parts in so many places often seems impossible.

That’s where Komodor steps in. Komodor is the missing piece in your DevOps toolchain, a Kubernetes-native troubleshooting platform that tracks all changes across your entire K8s stack analyzes their ripple effect, and provides you with the actionable context you need to troubleshoot efficiently and independently.

Transcript

(Intro Narrator at 00:00:03) Hello, my friends. Today, Joel is talking to Itiel, co-founder and CTO at Komodor, and they discuss how Komodor tracks changes across the entire Kubernetes stack, how to surround yourself with people more talented than you, and how to facilitate open and transparent communication in your teams. All of this right here, right now, on the Modern CTO Podcast.

(Joel Beasley at 00:00:31) Here we go. This is the Modern CTO Podcast. What was the problem that you saw where you thought, "I need to make Komodor"?

(Itiel at 00:00:48) Yeah. So, you know, Rookout, they help to troubleshoot or debug at a very macro level problem. You have a problem with your application, you want to deep dive in the exact same moment and to better understand what is happening inside my code. And in order to use Rookout, you needed to know what version is currently deployed to my production—simply the SHA or the tag or something.

(Itiel at 00:01:19) And back then I did the job of solution engineer as well as being the first developer and product and everything. So, you know, I saw so many companies just struggling to understand what is happening inside the production environment. What are all those issues? What are the problems? How do I fix them? They were lacking the high-level visibility on what is happening.

(Itiel at 00:01:41) So Komodor obviously tries to solve this thing that I felt both personally and with the customers I met, which is what is happening in my Kubernetes in terms of what services are currently running, what services are unhealthy, when did they change, in this recent change what happened, what commits were added, what pull requests were added, what feature flag was just turned on or off. A lot of the questions people ask themselves when they troubleshoot. But till Komodor, they simply couldn't get an easy answer. You can go to Jenkins and GitHub and Datadog and try to correlate everything in your head. But with Komodor, you have a simple timeline that tells you the story of both the entire cluster and a specific service. And this timeline includes all of the interesting information you can think of.

(Joel Beasley at 00:02:35) That's super cool.

(Itiel at 00:02:36) This was the root of Komodor. Since then we added a lot of making our own Kubernetes experience into the product and we help users identify issues before they escalate. We know to track certain kinds of resources such as PVC, load balancer, ingress. We know when those kinds of resources are having issues, and we automate the best practices checks or the best practices of how do I troubleshoot the Kubernetes issue into our product.

(Itiel at 00:03:11) So we know how to help them to find the root cause given a specific issue or a problem. So we have both the visibility part of Komodor, the history part telling you what happened inside the cluster and the correlation with other resources such as GitHub, PagerDuty, Datadog, and so on. And we also have the new capability of automating the troubleshooting flow for you where we built a very comprehensive list of workflows on what's the best way to troubleshoot an issue, and we run all of those checks for our users. So for example, you have a problem with one of your services, one of the pods are unhealthy, Komodor checks to see if the node is okay. And if the node is currently not healthy, don't be surprised that the service is not healthy.

(Itiel at 00:04:02) It probably impacted more services, so go and figure out what happened in the node. Or if you're currently having a PVC problem and you got an API issue with AWS, go check AWS. We'll give you the logs from AWS. You don't need to jump over hoops to understand the root cause of your issues. So Komodor tries to give a comprehensive troubleshooting experience for our users.

(Joel Beasley at 00:04:29) That's pretty cool. Now I'm curious. When we were in the prep meeting for this, my audio engineers were asking me what Kubernetes is and to explain Kubernetes. And I said, let's let Itiel give the simple explanation. So to someone who's proficient on a computer, good with editing audio, knows a lot—how would you explain to them what Kubernetes is?

(Itiel at 00:04:52) Yeah. So I think if you never created an application or have zero experience, I think the best way to think about it is maybe a little bit like Google Chrome or something like that. You have a lot of tabs, but every time you want to open a new tab or something like that, you just tell Chrome, "Do you mind opening me a new tab?" And behind the scenes, or when you ask for a specific internet connection, behind the scenes Chrome is doing a lot of things. He's doing TCP requests, he's downloading the data, he knows how to show it to you. But as a user, I know that I have this thing called Google Chrome. I know that it can open a lot of different tabs for me, and I don't need to think about anything else. You know, have fun.

(Itiel at 00:05:42) So Kubernetes took the way of taking the ugly part out of developing applications, and it's a very nice tool that you can request and tell him, "Do you mind adding me another application? Do you mind opening me another tab?" And behind the scenes, he tries his best to accommodate that particular request. Sometimes, sadly, he fails.

(Itiel at 00:06:11) And Chrome doesn't really fail most of the time, but Kubernetes is much more complex than Google Chrome, so it is much more tricky. But he tries his best. So I think you can think about this—it's a very high-level thing that you can ask things for and it tries its best to accommodate it, but sometimes, sadly, it fails.

(Joel Beasley at 00:06:36) All right, I want to go deeper.

(Itiel at 00:06:37) That's the best.

(Joel Beasley at 00:06:38) Yeah. So now imagine that you've got a junior developer who, you know, on the weekends deploys their own apps to Heroku and things of that nature. How do you explain Kubernetes to them?

(Itiel at 00:06:52) So if I have a junior developer, I think the best way is, you know, you're a junior developer. What do you know? What is an application—a local application, Express, Flask, something like that? So you just build your application. You're happy because, you know, everything is good on your mind up.

(Itiel at 00:07:11) But now you want me to use it or someone outside of your own local computer to use it. So you use Docker. So you need to understand Docker. Docker basically allows you to take your very nice application and to wrap it in a very nice, unified format. It is easy, it is nice. It's taking your application into a very small box and basically wrap it so it would be easier to deliver to your customers. Once you have Docker and you understand the Docker concept, you can tell them about Kubernetes as a cargo ship where you just put those very nice Docker containers, basically, and you put it on the ship. So Kubernetes allows you to bring your application once wrapped, and Kubernetes promises to do his best to run this application for you. He allows you to run those very nice Docker images without you needing to think about a lot of things such as network, load balancer to an extent, replicas, and so on.

(Itiel at 00:08:18) So I think, yeah, I think this is a nice, I hope, example.

(Joel Beasley at 00:08:23) Yeah. So help me understand. My background is mostly software as a service developer, seventeen years, most recently, past seven, eight years, Ruby on Rails type person.

(Itiel at 00:08:37) Mm-hmm.

(Joel Beasley at 00:08:37) So, and right as Kubernetes started to get popular is when the podcast was getting popular. And so I wasn't actively, you know, nerding out twenty-four seven. So I kind of missed the train to be able to really deeply understand it. Do you use Kubernetes for SaaS-based applications? Like I have an application deployed currently to Heroku right now. It gets a small amount of traffic.

(Joel Beasley at 00:08:59) But, you know, people are paying for it. But how—why would I use Kubernetes? Is it only for local applications, like legacy things where I have an internal desktop application and I need to deploy it to other people, or can software as a service companies use it?

(Itiel at 00:09:20) Yeah. So Kubernetes—you know, for you, go keep using Heroku. You really don't want to make things more complicated, basically. So don't try to do it. My best suggestion for you is stay with what you have. Kubernetes is designed for more complex situations where you have multiple apps and multiple replicas, and you care about how fast is your deploy cycle, about building the different communication between the applications.

(Itiel at 00:09:53) So my suggestion for someone who is hosting his own blog, cool down. You don't need Kubernetes. Also, for a very small startup that is not very techy, Kubernetes helps to solve a lot of problems that most small companies don't really have. So it's the wrong answer for a lot of people. And a lot of people still choose to use it even though it's the wrong answer.

(Itiel at 00:10:19) But it allows you to scale your system very fast. It allows you to get a lot of things out of the box because Kubernetes has a really big community. So I would say it's an expert tool or a medium-plus size company tool that allows the company to stay in control while they are deploying their application.

(Joel Beasley at 00:10:45) Okay. So it's for problems that arise at a mid-size level company. Yeah. Yeah. I think that helps clear a lot of stuff up because, you know, I hear so many people that are like, "You know, you've got to move to Kubernetes day one."

(Itiel at 00:11:01) You know, I think a lot of people, I don't know, I don't know. I won't say they love Kubernetes. So Kubernetes is a great technology, but every cool technology becomes abused a little bit. So it's the new kid on the block. If you're not on Kubernetes, then you're all empathetic or I don't know.

(Itiel at 00:11:30) So it's the default, right? It's a little bit like—I don't want to say Go is complicated. But to choose a technology, it's like starting to develop your web application in Rust or something like that. Maybe it's the right way to go, but probably use JavaScript and Express and do it as fast as possible if you want to get to a very fast outcome. But Kubernetes now is so popular that it's not really the case.

(Joel Beasley at 00:12:03) Thank you for helping me sort of wrap my mind around it. The name Komodor, I Googled it to look up what it is. It's a dog with dreadlocks.

(Itiel at 00:12:13) It's Komondor. You're the dog. It's a common misconception. Komodor is more of the admiral in the navy. So it's a commander. It's like the computer also. So we benefit both from the—Kubernetes is very C-based names. So we have the name and I love the dog and the K for Kubernetes. So everything just—everything just—all the stars, basically, are aligned.

(Joel Beasley at 00:12:50) Did you do technology-related stuff in your service, or were you interested in it before?

(Itiel at 00:12:52) Really, really, I was really far from all of these things, sadly for me. But I was quite—it was really not my area. But, you know, I studied computer science and psychology. I really got into computers.

(Itiel at 00:13:11) I started working for eBay, which was great, and I did a lot of infrastructure there. Then I joined a small Israeli startup named Forter. They were really high—they were really good people and very, very strong team. So I learned a lot. Then I became the first developer in Rookout, which turned out to be a very nice opening to the dev tools space.

(Itiel at 00:13:37) And then, you know, I started Komodor with my friend, Ben Ofiri. We met in the university. He was in Google all of this time while I was jumping between companies. He was doing infrastructure in Google. So, you know, Borg, not necessarily Kubernetes, but, you know, it is close enough. So, yeah, it was quite fun.

(Joel Beasley at 00:14:03) That's pretty cool. So you primarily focus on Kubernetes-related troubleshooting? Yep. Nice. Nice.

(Joel Beasley at 00:14:11) What's something that you're working on right now that you're super excited about?

(Itiel at 00:14:16) The workflows. It's the most ambitious thing that I think we've done in Komodor. Basically, to take troubleshooting and to automate it. So it is a lot harder than you might expect, or maybe you do already expect that it will be quite hard, so it's not that surprising.

(Itiel at 00:14:37) But it is quite challenging both doing the research, understanding different failure scenarios, and then taking all of those different failure scenarios and codifying it. You got out of memory because the application changed, because the node changed, because the node has pressure. So many different reasons. It's a podcast, right, but they can share with you.

(Joel Beasley at 00:15:03) Yeah. We can share. That's crazy.

(Itiel at 00:15:06) Yeah. So this is a very small part of the research we are doing. So what you can see here is a crazy graph which has, I think, hundreds of different nodes. And we are taking—each node starts with, the graph starts with a failure scenario. The PVC is not working. My ingress is empty. My load balancer is not loading traffic. And we built a lot of different steps. Now we should describe the pod, describe the PVC, describe the SSL certificate. I don't know.

(Itiel at 00:15:40) And now what we're doing is doing the research and then automating it via code. We're using Temporal IO, if you know them. I'm not sure if they also interviewed in your podcast, but they are quite a cool company.

(Joel Beasley at 00:15:53) And what do they do?

(Itiel at 00:15:55) Temporal IO? Yeah. They are a workflow engine.

(Joel Beasley at 00:15:59) Oh, cool.

(Itiel at 00:16:00) Yeah.

(Joel Beasley at 00:16:03) So you sketch out these rules and then you can use Temporal to help with them?

(Itiel at 00:16:07) Yeah. Exactly. Exactly. So this is the craziest thing I think I've done. And it is super interesting, challenging, fun, you know.

(Joel Beasley at 00:16:18) Can Temporal ingest the output of that draw.io or whatever you made?

(Itiel at 00:16:23) No. No. No. We wrote a lot of wrappers and this is the normal research and we have the codifying it into something concrete.

(Joel Beasley at 00:16:36) So, so let's say an issue happens that your workflow recognizes, like this pattern, can it self-heal? Does it give me an option to be like running?

(Itiel at 00:16:46) So yes and no. It will self-heal in the future. But for now, we are more focused around automating the finding the root cause. Because a lot of the time, the automation of the remediation part is super tricky. Should I fix my application? Should I roll back? Should I increase the memory? It is tricky, and what we're currently trying to do best is to detect issues before they arise, mainly around parts that are not that well monitored, such as load balancer, ingress, PVC, spot instances, and so on. And also to help you investigate and understand the root cause behind all of those issues. At a later stage, we will probably add some remediation.

(Itiel at 00:17:30) Maybe it will be something you can run like a script. Maybe it will be automated. We need to better understand it with our customers basically.

(Joel Beasley at 00:17:39) Yeah. It's like, you know, talking about mind control from Neuralink. Step one is get the implant in the people and start getting data. No, it's exciting though, because you can instantly—it's very clear, even me just learning about the product right now to see that this workflow is the foundation that could ultimately end up in either presenting me with a button that says, "We think it's this problem, run this cure," or it just doing it automatically.

(Itiel at 00:18:07) Yeah. Yeah. No, it is very, very interesting and challenging.

(Joel Beasley at 00:18:13) Have you told your customers when workflows are going to come out?

(Itiel at 00:18:16) Yeah. We talked to our customers. I won't say some of them just keep on asking us on a weekly basis, and in two weeks it's going to be launched.

(Itiel at 00:18:26) So that's it. And we're starting our team small and then growing it much bigger. It's like closed beta at the moment. So I can tell you that a lot of people are waiting for it, and it will be super exciting once it's out.

(Joel Beasley at 00:18:38) Nice. So you're like two weeks from today?

(Itiel at 00:18:41) Yeah, hopefully. That's, let's see, right? Let's see.

(Joel Beasley at 00:18:47) No, it'll be great. Everybody, when you're providing, when you have customers and they want something and you're working on it, they're super happy. If it takes two more weeks, I mean, look at the people who, to bring it back to Elon Musk, who ordered the Model 2020 Roadster and it's still not out.

(Itiel at 00:19:05) When you do something which is truly hard, you know, it is simply, how can I say it? It is hard to do. Then you just automatically get the user trust. And I don't know, they know that once workflow is going to be, their troubleshooting is going to look completely different than how it looked till today. So another week or two are not really going to change it.

(Joel Beasley at 00:19:38) I like that you mentioned that. So you're a founder. You mentioned about doing hard things, which I love doing. I'm always going through this cycle of I hit a comfort zone, I hit a plateau, and then I have to pick new things. And then there's that time, like six to twelve months, where you're getting used to the new thing, and then you have to realize you're in it again.

(Joel Beasley at 00:20:00) What sort of difficult things are you doing now or have you done recently?

(Itiel at 00:20:05) In terms of?

(Joel Beasley at 00:20:07) Like your personal life, like growing yourself as a human.

(Itiel at 00:20:10) You know, building a startup. We grew much faster than we anticipated because the market response was so positive. So we are now 35 people, I think, in one and a half years. And it is hard and challenging, building there in the organization, building the product team, having customers, having customers complain, having customers happy. It is very challenging. And at the same time, I became a father two months into the startup.

(Joel Beasley at 00:20:45) Yeah.

(Itiel at 00:20:46) At the end of COVID. So yeah, it was a hell of a ride so far. But, you know, I enjoy it. It's much better than everything else I've done, so I'm quite pleased.

(Joel Beasley at 00:20:59) That's exciting. Do you have a boy or a girl?

(Itiel at 00:21:01) I have a girl, Ella.

(Joel Beasley at 00:21:03) Oh, dude, that's awesome. I have a girl, Aria. Dude, it's the best. Yeah, that's super exciting.

(Joel Beasley at 00:21:10) I feel connected to you because when I started this whole podcast journey four years ago, I started it the same month that my daughter was born. And I was like, it's so hard because you don't have steady income coming in. I had savings and stuff, but to be putting cash out and to start something new right when you have, my first child coming in, you have to take care of them. It's a tough leap to take.

(Itiel at 00:21:35) No, I completely agree. So yeah, that was quite challenging and interesting basically.

(Joel Beasley at 00:21:44) So what's the sales process like? Do people just call you up and say, we heard this through our friends, it's awesome, we need it now? Or how does it go?

(Itiel at 00:21:53) I don't know. Some people, yeah, it's super awesome, give it to me now. We do a lot of content. We try to publish a lot of helping materials, how to troubleshoot issues in Kubernetes. Container is restarting, your node is not healthy. We create beneficial stuff. It's, you know, it is marketing, but it's not Komodor specific. It's how do I operate Kubernetes. And I will say the cool thing about Komodor or the space is Kubernetes is becoming the de facto standard, the new Linux. Everyone is going to Kubernetes, and they don't really understand how much Kubernetes is complex. And when they do understand it, it's too late a lot of the time because they are in day-two operations trying to run everything and make sure everything works as expected. So I would say, you know, as we publish ourselves, it's not a question: is troubleshooting in Kubernetes difficult? It is difficult. No one thinks otherwise. It's a question of the work maturity, the specific problems, and is Komodor fitting. It's not everyone we meet just wants to use Komodor out of the box, even though it happens quite a lot. But everyone is suffering, which is bad for the universe, but quite nice for a company that tries to help make their life easier, because no one is telling us, oh no, I have no issues. Troubleshooting is easy. No one.

(Joel Beasley at 00:23:26) Yeah, I know. Do you have competitors in this space yet, or are you guys still super early?

(Itiel at 00:23:34) No, not real competitors in the space. I would say that the biggest competitor is how much value can we bring on top of their existing monitoring stack, because I don't try to replace Datadog or any other tools. We integrate with those tools. So this is the biggest obstacle we have. But in the end of the day, and we see it more and more, Datadog is a really great product. We use it internally to understand that you have a problem. But once you have a problem, Datadog doesn't really tell you the full story of why you are having the issues that you are having. And luckily for us, you know, we have to solve that exact problem. Why are you seeing what you are seeing? Why is your service not healthy? But I would say this is the biggest obstacle that we're facing, and we are overcoming it quite good. Most of our customers, if not all of them, are using Datadog and New Relic, AppDynamics, you name it, they are using. But still, things are hard.

(Joel Beasley at 00:24:42) As your company is growing quickly and expanding, you as a founder and your partner, what are you learning? What's one of the things that keeps coming up over and over that you've learned during this expansion and growth period?

(Itiel at 00:24:59) What have we learned during this? It's a good question. I'm trying to think, what's the number one thing that we're—

(Joel Beasley at 00:25:09) A billion things. Whatever pops in your mind is fine.

(Itiel at 00:25:12) Oh, it's a good question. What's, I don't know. Move fast. Listen to our customers, move fast. I think that's pretty much it. And hire good people. That's the most important thing. I don't believe that we could move so fast without a very strong team that, you know, is with us. And that might be sales, might be marketing, it's R&D, it's product. Surround yourself with people that are much more talented than you are. So I think, yeah, that's the gist of things.

(Joel Beasley at 00:25:52) Yes. I love that, surrounding yourself with good people. I was having a conversation earlier today and they were asking me, how do I stay up to date with industry stuff? And I was like, well, other than having hundreds of people come through the podcast that are experts in their field and telling me, they were saying, you know, do you read industry trade publications? Do you have a favorite blogger that you follow? And I said, no, I really just have some really great people around me and they sort of act as a filter. And so they're out there learning and then I'm engaging with them. And so I'm sort of getting this knowledge from my group because the most important things tend to propagate or bubble up.

(Itiel at 00:26:31) I think that's the key, that's the key here.

(Joel Beasley at 00:26:35) So have you gotten to hire any of the authors that you've read or anything like that?

(Itiel at 00:26:43) Not yet. It could be great, but not yet. We had a webinar with Kostis Kapelonis from Codefresh. Not sure if you know him. I read a lot of the blog pieces he wrote. He's an amazing writer. He writes about CI/CD mainly, Kubernetes, everything. And he wrote a piece about Komodor, which was amazing because he's so into details. And to see him write about Komodor and being excited about Komodor, it was really, really good. I read a lot of what he wrote about other tools during the years, so it was quite nice.

(Joel Beasley at 00:27:18) Nice. Yeah. I think it's so cool to, when I first started going out and being less introverted to conferences, getting to meet authors of books that I enjoyed and then, you know, figuring out that they often do consulting and you can actually work with them. I was like, this is something I did not know and I thought it was very valuable. Culture. Can we talk about culture for a minute?

(Itiel at 00:27:42) Yeah, we can.

(Joel Beasley at 00:27:43) Yeah. So obviously culture is something that a lot of people talk about, and it's hard and it's difficult, especially when rapidly expanding. Do you set time aside with your founder to talk about it? Do you, just in the process of moving fast, that's just the culture right now, move fast? Or how do you think about culture?

(Itiel at 00:28:01) We are talking about it. Currently, we sit mainly on what kind of people we want to hire. Will this person be the right fit for the current culture? He has excellent skills. He's a nice person I will enjoy working with. Can he move fast? Will he break under pressure? We are a startup. We need people that are not afraid of taking chances, that can take the leaps, you know, building something from scratch no one ever, ever seen. So I think it goes down to should we hire this person? Those are the biggest impact on your culture. And luckily for us, me or Ben were involved in all of the hires. I think 100% of the hires, me or Ben were there. So this is where you can, you know, make sure the culture stays good. In the end of the day, going forward, we can't hire everyone, right? And we want to be part of the process, but we hope we brought enough people that understand us and the culture to make sure it works.

(Joel Beasley at 00:29:18) Yes. I tend to, I have several friends that run technology companies that are from Israel and I always enjoy having them on the show. TravelBank is one, is a big one. Their company got really big. And then of course, Rollout and a couple others. But one of the things I enjoy a whole lot when I get to work with entrepreneurs from Israel is that they're very direct and it's so easy to interact with them. And then that goes in their culture too.

(Itiel at 00:29:45) We are very direct as well. So yeah, that's not an issue.

(Joel Beasley at 00:29:54) Have you just made a decision between hiring remote or in-person or hybrid?

(Itiel at 00:30:07) Inside the company, we don't have remote workers. I guess it will happen. I'm not really against it. But if we can somehow hire everyone and have them in the same room, I do believe it is very powerful for a small startup. So we're not 100% against it, but we do prefer people who can come to the office and meet everyone. So so far, we were lucky enough to find good people that match those criteria.

(Joel Beasley at 00:30:35) I'm not a fan of talking about COVID, but I am curious, in your town where you are, because you're in Israel, correct? Yeah. Okay. So in your town, are people going to the office? Are they going to work? What's it like?

(Itiel at 00:30:49) Yeah. In Israel, we are vaccinated, luckily for me. And, you know, everyone is acting quite normally.

(Joel Beasley at 00:31:00) That's cool. So that way your in-person office, it works.

(Itiel at 00:31:03) Yeah, yeah. Most of them, you know, we have people who can't come because they were abroad or they are home. How do you say it? When you are first—quarantine?

(Joel Beasley at 00:31:15) Quarantine.

(Itiel at 00:31:15) Yeah, quarantine. Sorry. So yeah. But other than that, yeah, we don't feel it too much. Luckily for me, for us.

(Joel Beasley at 00:31:25) I've got some leadership questions if you're cool with that.

(Itiel at 00:31:29) No, I can try, right? I can do it.

(Joel Beasley at 00:31:33) We could try. These are just random questions people have written in and asked. How hard is it for leaders to ask for help?

(Itiel at 00:31:42) Ask from who? From people in the company? From outside the—I don't know. But I don't have the ego. I, we know both me and Ben, we do feel comfortable asking from someone from within the team. Sure. That's why we hire the team of great people. Very comfortable. I think that, you know, understanding that we can use other people that had those kind of experiences is something that we had from the get-go, but we didn't really, at least I didn't really realize how important it is to have a very good advisor that you talk with on a weekly or biweekly basis. It's not that I feel uncomfortable, but I didn't really realize how helpful it can be. And once having those conversations, it was really something that helped me.

(Joel Beasley at 00:32:43) Yes. I have found I'm typically a personality that's very independent, but I have found that getting perspective from someone else who's independent, who I respect and trust, getting their perspective on my situation is very valuable.

(Itiel at 00:33:00) Yeah.

(Joel Beasley at 00:33:02) Alright. Next, we got another one here. If you could design the perfect leadership training program for your direct reports, what is the most important thing that'd be in it?

(Itiel at 00:33:13) Communication. That's the key to everything. Specifically with working remote and, you know, open communication and transparency, I think it can solve most issues or most problems. And every time we see that we had an issue, it is usually related to miscommunication. Bob said this and Henry heard that and that caused an explosion or something like that. It is usually problems with communication. We don't have Bob or Henry.

(Joel Beasley at 00:33:49) I was looking at your background. I didn't notice. It says "This Week on Showing Off R&D." What's that about?

(Itiel at 00:33:57) It's a background that was created personally by our designer, designer Maya. We had a showcase of cool things we've done in the R&D. So everyone showed what they done over the last couple of weeks. It was a super fun activity to brag and to show what you were working on. And yeah, behind me, there is tea because I really like tea. So she designed it specifically for each one of the team members. It was a couple of months ago, I think.

(Joel Beasley at 00:34:26) That's pretty cool. Yeah. I like loose leaf tea as well. Yeah. I, right when I saw that, I was like, oh, I've got a couple of those at home. Communication, we were talking a little bit about it. I like what you said. Transparency, a lot of issues can be solved, you know, through good communication. How do you teach it, though? Is it teachable?

(Itiel at 00:34:48) I'm not sure. I think some part of it, obviously, but it is hard. You said I can do the perfect training. So I don't know. We need to figure it out. What's the best way to improve communication? But, you know, I read a couple of books. I talk with people. Radical Candor is very interesting in terms of—

(Joel Beasley at 00:35:07) I love that book. Kim Scott.

(Itiel at 00:35:09) So, you know, it's not easy to implement, but it has, like, the best practices or how to do it. So it is teachable, but you need to pay special attention to make sure it really works. So yeah.

(Joel Beasley at 00:35:29) Some things require really tight experience cycles. Like, learn just a very little bit, go try it out so it becomes personal to you. That's why I like when Kim did her book. She did, I think, like the first 60 or 80% of the book was like story or explanation, and then in the back of the book, she had a bunch of exercises or very applicable things.

(Itiel at 00:35:50) It's a great book, right? It is a great book.

(Joel Beasley at 00:35:55) What's the most impactful leadership lesson that you've learned ever, not just at this company, in your entire career?

(Itiel at 00:36:02) Like, I had a really good boss on my previous job at Elbingogen, which is an amazing R&D, and I learned a lot from him. Like, in the end of the day, the high level of it all is making sure that the organization goal and employee motivation are really aligned, and that he can see why when he's doing well, the organization is doing well and vice versa. And making sure that those two tracks are aligned is the key to a happy and successful employee. The motivation alignment. And again, it is a very valuable lesson that I learned. In real time, I didn't really think about it because, you know, I was an employee. It just makes sense to me that if I'm going to be good, then the organization is going to see it, and it's going to be good for me, good for my company, and so on. But making sure every employee in the organization understands why if he's going to be good, he's going to improve himself and the organization at the same time, it is really a key thing to make sure everyone is aligned. Not sure if it made sense.

(Joel Beasley at 00:37:22) Yeah. Yeah. Did you say you used to work with Oren?

(Itiel at 00:37:26) Yeah. Did you also interview Oren?

(Joel Beasley at 00:37:28) No. Well, I have not interviewed him yet, but I should. It just reminded me. I mean, he did the Snowflakes book, and then he does the newsletter, the Software Lead newsletter. Right?

(Itiel at 00:37:37) Indeed. This is Oren. Yeah.

(Joel Beasley at 00:37:39) Dude, that's so cool that you got to work with him.

(Itiel at 00:37:42) Yeah. Yeah. Oren is amazing, and I completely agree. It is very cool that I got to work with him.

(Joel Beasley at 00:37:49) Yeah. You know, he does some consulting stuff on culture and leadership training.

(Itiel at 00:37:54) Yeah. Yeah. I have everything we do on this Sunday.

(Joel Beasley at 00:37:57) There you go, man. I'm gonna wrap up with this question. You've got engineers, you've got 35 people plus, you're growing really quickly. What's a piece of advice that you would give to an engineer that is looking to take on more management responsibilities?

(Itiel at 00:38:13) I think it's a question of, you know, first of all, finding someone you can learn from. It can be inside the company, but maybe outside the company. Because without proper guidance, I think it is very, very challenging. So I think that's the first thing. And the second thing is, you know, don't panic. I think in the—and we talked about Critical Candor, but I also really like The Making of a Manager. Sorry. Which is like, the best book about management that I read by Julie Zhuo. I may have mispronounced it.

(Joel Beasley at 00:38:56) It's okay. I mispronounce everything.

(Itiel at 00:38:58) But this book is great and she talks about everything and it's very well written. So, you know, reading materials and getting help, I think that's my best advice.

(Joel Beasley at 00:39:10) Yeah. I love it. I like that we have found similar content, like, you know, I know The Manager's Path. I've just been learning about The Making of a Manager, but I knew about Radical Candor and then Rands in Repose. Michael Lopp, he writes some really great stuff too.

(Itiel at 00:39:26) No, books are great. Benjamin Newman is also amazing if you read it. Like, so yeah. Well, you have to practice it, right? Like, or you have to have someone to give you the feedback. It's really hard just reading books and then becoming a great manager. Maybe if you are naturally talented, but if not, find someone who can help you.

(Joel Beasley at 00:39:51) Alright, dude, I love it. I think that's great advice. Was there anything that we left out that we want to make sure to get out there? Like, can people download a free demo? Are you hiring? Do you have a hiring page?

(Itiel at 00:40:03) I think, like, indeed today, if you're in Israel and you like Kubernetes, come work for us, and you can find us quite easily. And if you're running Kubernetes but feel like it is much harder than it needs to be, also ping us. Like, I think that's the main—the two main important things. And if you want good management advice, feel free to ask me. But also, read Oren's newsletter and read the books because they are amazing.

(Joel Beasley at 00:40:33) I love it. And can you tell me what the website is for your product?

(Itiel at 00:40:36) Komodor.com, basically.

(Joel Beasley at 00:40:38) Excellent. So it's komodor.com. Yep. 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.