Barak Schoster - Co-Founder & CTO at Bridgecrew

(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to Barak, the co-founder and CTO at Bridgecrew. And we discussed the concept of shifting cloud security left, how companies can implement Bridgecrew's tools to make their engineers more independent, and how cloud automation gives engineers superpowers. All of this right here, right now on the Modern CTO Podcast.

(Barak at 00:00:25) Here we go.

(Joel Beasley at 00:00:26) This is the Modern CTO Podcast. Where are you calling in from?

(Barak at 00:00:38) I'm calling from Tel Aviv.

(Joel Beasley at 00:00:41) What's it like over there?

(Barak at 00:00:43) Pretty nice. Half of the population already got the two vaccines, so things are getting back to normal.

(Joel Beasley at 00:00:50) Nice. That's exciting. I can't wait for things to get back to normal, right?

(Barak at 00:00:54) Yeah. Restaurants are open again. Pubs are open. People are having fun.

(Joel Beasley at 00:00:59) Have you gotten to go out yet?

(Barak at 00:01:01) Yeah, yeah. Sure. First thing I did once they announced that everything is going back to normal.

(Joel Beasley at 00:01:08) Did you get the vaccine yet?

(Barak at 00:01:09) Yeah. Yep.

(Joel Beasley at 00:01:10) So you're a beta tester. How did it go?

(Barak at 00:01:15) No tails, no 5G reception. So things are back to normal. Where are you calling from?

(Joel Beasley at 00:01:27) I live in Florida in the USA.

(Barak at 00:01:29) Right. So everything was normal all over, like the whole thing. You just kept everything normal, right?

(Joel Beasley at 00:01:37) Florida's crazy. So dude, how did you first get into technology?

(Barak at 00:01:46) Well, it was a while ago. I know that I look young, but I started at the age of 14. I started programming at 14, did my first degree then, and then got into the Israeli Defense Force to some technological unit. Spent five years there leading some big data engineering teams. And after being exposed for, by that point, nine years to programming and software engineering, I started my first role at a small startup called Fortscale, which was around security analytics. Did some large scale big data based on, back then it was Hadoop, was still cool.

(Barak at 00:02:32) And some algorithms on top of data when the word data science just began. And after a few years then, the company got acquired by RSA. Started to work with AWS and the cloud, and then got into Bridgecrew that is now part of Palo Alto. So it was kind of a journey between startups up until now, and now part of a big corporate.

(Joel Beasley at 00:02:58) What's it like now? What's the difference from being startup versus being part of this larger corporation?

(Barak at 00:03:05) Well, it's my second week, so it's still early. But it's super fun so far. So as a startup, everything was, we learned in a crazy pace everything that needs to get done. We thought that a large scale is having relatively a lot of customers very fast, but when you get into a large enterprise, you get to know what a lot of customers means, and it's much more grasping all of that knowledge nowadays. So fun.

(Joel Beasley at 00:03:41) How did you meet your co-founder when you started Bridgecrew?

(Barak at 00:03:44) So I met them at our previous startup, which was Fortscale. And I got into that startup by a joint friend. So everybody kind of had a one person jump, one person hop between one another when we first met. And after that, we had some time to work together for three years back at Fortscale, and we decided to found Bridgecrew together after the RSA acquisition when we saw how hard it is to develop cloud infrastructure in a large enterprise. So we were tasked with migrating this big data pipeline to AWS.

(Barak at 00:04:31) And it's not just a lift and shift when you migrate from Hadoop to cloud technologies. And we saw the different challenges that you have when you're working with a larger scale team to apply security best practices that you would like to take with you when migrating an on-prem infrastructure to the cloud. And we realized that there must be a better way to do that, so we started a new startup.

(Joel Beasley at 00:04:59) That's awesome. The design looks really good. The brand is beautiful.

(Barak at 00:05:04) Thank you. Yeah. We have some Star Trek fans in the team, so this is why we named our team Bridgecrew. So yeah, thank you.

(Joel Beasley at 00:05:14) So how did you come up with the name?

(Barak at 00:05:17) So Bridgecrew is actually the team of officers in Star Trek that is responsible for the entire fleet. And also it's the bridge between the two crews, security and DevOps, which is the crews that we work with in Bridgecrew.

(Joel Beasley at 00:05:34) That's actually a really intelligent name.

(Barak at 00:05:37) Thank you.

(Joel Beasley at 00:05:38) So can you help me understand something? So my background, seventeen years writing software, building applications, some consumer applications, but mostly business to business type applications. And I'm curious, I kept reading about the company and you mentioned security as code. And I was hoping you'd be able to explain that to me a little bit better.

(Barak at 00:06:00) Yes, sure. So Bridgecrew is acting in a similar space to B2B. It's called B2D, business to developer, where your primary persona that is using the platform is actually a developer. So you're not selling top down to the business, directly to the CIO. Bridgecrew is a company that is setting bottom up.

(Barak at 00:06:22) We have an open source offering and then a freemium offering and a self-service module, where engineers that would like to develop cloud infrastructure usually write in infrastructure as code manifests like Terraform, CloudFormation, Kubernetes, and other configuration as code languages. In a regular world before Bridgecrew, you would write that infrastructure, apply that to the cloud, and have another security team inspect their cloud infrastructure and then open a set of Jira tickets for stuff they should enhance in their cloud infrastructure. And when you go through that process, you realize that there is a lot of human intervention, a lot of communication to be done when you want to do a configuration change. And you are not really independent creating your cloud infrastructure. So in order to have a complete infrastructure as code vision where you have a predictable deployment, version-controlled infrastructure that can be peer reviewed, you also want with that peer review to have unit tests and security tests as part of your code.

(Barak at 00:07:39) So security as code is the ability to define policies or best practices or unit tests on top of your cloud infrastructure in a way that either while you code or on each pull request or commit, you have an automated way to understand that you have done what you meant to do. So let's take an example. Let's say that you're creating a new S3 bucket in the AWS cloud, and you want to know that you're following best practices, like having backup and recovery, logging and auditing, encryption in place. All of those are policies on top of your S3 bucket configuration, and those can be defined in code.

(Joel Beasley at 00:08:19) That's pretty neat. And so you help automate this process for the businesses?

(Barak at 00:08:24) Yes. So we created an open source about a year and a half ago called Checkov. Not actually only we, but other open source contributors contribute a ton of policies, more than 500 already, of best practices that they know or that are common in the industry from common benchmarks like the AWS Foundations, the CIS, the Azure best practices, et cetera. So a lot of people are writing those policies of best practices, contributing them back to the Checkov repository, and then the entire Checkov community enjoys from their code being reviewed by other people that wrote all of those policies. It's a community effort there.

(Joel Beasley at 00:09:10) And so what type of struggles did you have getting this thing started?

(Barak at 00:09:18) I think that the thing that we started with is understanding the need. So as engineers, we knew that it's hard to move fast in large enterprise doing a digital transformation. And what we did is we asked everybody how they handle this process. And the first common thing that people in fast-moving companies have told us, hey, if we're managing everything in infrastructure as code, the security team knows how to review it.

(Barak at 00:09:50) So we have a process, which is a pull request where security team can review the code, the infrastructure changes, but then the security team is the bottleneck of each and every change. And we would like to automate that. So some of the people that we've met wrote a bunch of scripts. So we learned from them, and we created a framework. And once we created a framework that was very easy for people to contribute more and more policies for, the entire process was much simpler for them and they saw the value and then it started to pick up in a pretty crazy pace.

(Barak at 00:10:28) And Checkov as a framework had more than 1 million downloads at its first year and more and more contributors came and joined. So from that moment, it was just we have a good open source, and we started to have a SaaS, a good SaaS offering, and it was building a better SaaS offering around that open source. So as an open core company, we'll have a way to take all of that traction under the freemium model of open source and successfully converting that into traction under a paid commercial offering. So those were the challenges.

(Joel Beasley at 00:11:04) So people know how to interact with Checkov. They know how to use your software.

(Barak at 00:11:09) Exactly.

(Joel Beasley at 00:11:10) That's pretty neat. It's like they're being educated through the open source project.

(Barak at 00:11:14) Yeah. So they can either use the project as is or embed it in a larger product that they build. They can contribute, or they can transition to a paid version where we have more feature-rich offering. So the challenge was understanding what would make a good open source and what would make a good product around it and how should the user journey look like in a way that will really solve each one of those personas a real problem in the world.

(Joel Beasley at 00:11:45) What's one of the premium features that you like the most, one that would cause me to want to upgrade?

(Barak at 00:11:52) So usually those would be either things in the user experience. So as an engineer, your day to day, if you are working alone, you can use the open source and say, all right, I want to check my own code. But if you want to collaborate and have automated code reviews and pull request comments and our GitHub bot to suggest automated fixes to your code, that's more of a premium feature. Also, if you'd like to see the compliance status of your code, that's more of a premium feature that you will use.

(Barak at 00:12:25) So it's more like, if you're a single person, you can use the open source. If you are a big team, you'll probably need the SaaS offering to scale.

(Joel Beasley at 00:12:34) As a business owner, when you were coming up with these ideas of which features to make premium for a paid product, what was that process like for you?

(Barak at 00:12:45) Wow. So before writing the first real line of code that is not a POC script, we had more than 120 or 180 conversations with DevOps and cloud security practitioners to ask them about their day to day. And after we mapped that process of who is each person talking with on their day to day basis doing cloud and DevOps actions, we created first draft of our product and then a SaaS offering. So the process was a lot of interviews and mainly listening and then getting an MVP out and then iterating over feedback.

(Joel Beasley at 00:13:26) How did you get those interviews?

(Barak at 00:13:29) So luckily, my partner had an amazing network of amazing people in cool companies like Netflix, Airbnb, Amazon, HashiCorp. And we just asked them how they automate those processes. And they told us about their processes, and they got us to know other people. And at some point, when we had a good open source, a lot of those conversations and interviews came inbound. What do I mean?

(Barak at 00:14:03) Let's say that someone has created a new issue for our open source project. We told them, all right, this issue makes sense. This can be an enhancement. Let's have a short chat on it, and we'll develop that open source feature if it makes sense. So during those conversations where we start to talk about a new enhancement to our open source offering, we ask the person that requested that feature, what else is he solving? What other issues does he or she have when developing in the cloud?

(Barak at 00:14:30) And we wrote all of their issues, whether it was related to our open source or not. And some of them became features in the open source, and some of them became features in the paid offering.

(Joel Beasley at 00:14:46) Very cool. And then so you grow the company, it starts to get lots of users. You have over a million people on the open source version. I saw that you had some really big logos, some big customers. I saw you had Brex. I was like, oh, I wonder if he knows Kosman over at Brex. But tell me a little bit about why you decided to sell or to merge.

(Barak at 00:15:07) So I believe that Palo Alto is one of the best security companies out there. It's obviously the largest one in the market. And there is an amazing opportunity to have a joint offering where our bottom-up go-to-market with the Palo Alto scale can really help us as entrepreneurs touch more and more engineers and help more and more engineers with our offering. So it really made sense to scale in that way.

(Joel Beasley at 00:15:38) Nice. That's a smart move. That's one of the available options, right? If you have a great product, you're gaining traction, and you want to turbocharge it, you go to somebody that already has the distribution problem solved and then just plug your product right in the pipeline.

(Barak at 00:15:52) Correct. So it's also connecting to different distribution models. So where Bridgecrew comes with a bottom-up distribution model and an open source go-to-market, and that's a shift that Palo Alto wants to do. And Palo Alto with their amazing scale as a very mature security company, that really makes sense.

(Joel Beasley at 00:16:13) That's interesting. Can people try your tools? Can they use it right now? How do they do that?

(Barak at 00:16:19) Yes. So if you want to use our open source tools, just look in GitHub or bridgecrew.io. There is a bunch of tools that you would probably want to start with. One of them is Terragoat, an open source, vulnerable by design infrastructure as code written in Terraform. There is a sister, two sister projects, CFNGoat for CloudFormation, vulnerable by design, and CDKGoat by the same idea, but just for CDK.

(Barak at 00:16:43) So all of those will give you a training landing zone where you can have a vulnerable infrastructure. Don't deploy it in production. And you have Checkov, our static code analysis tool, where you can scan that infrastructure before provisioning it and find and identify issues while you're writing code. It has a complimentary project, open source project called Checkov VS Code, which is a VS Code extension which will give you annotations while you code your infrastructure within VS Code. It will tell you, hey, you have this community-contributed policy saying you really need to fix that IAM policy or encrypt that bucket as you code. And it also has an API key integration which will use the Bridgecrew APIs for automated fixes.

(Barak at 00:17:36) And we have another open source project, Cloudsplaining, for IAM least privileges. If you want to automate that process and have the right fine-grained controls around AWS IAM, we actually have another open source tool that is coming in two months from now. So you should probably follow the entire GitHub organization.

(Joel Beasley at 00:17:58) Done. Following the GitHub organization. I love it, man. This is great. I like seeing you. You seem to be really passionate about this. What area would you say that you're the strongest in? Where do you spend the most time?

(Barak at 00:18:12) So probably doing DevOps tasks. So I'm spending a lot of time, obviously, provisioning cloud infrastructure using infrastructure as code. And also Python programming. Python and Go is the two languages where our open source projects are written at. So those are my three main areas.

(Joel Beasley at 00:18:34) And what's the most interesting thing happening in the first area, in the infrastructure as code? What's the coolest thing happening right now? If you got 20 people together who were all like you in the sense that they have the same day-to-day task, what's the most interesting thing happening there?

(Barak at 00:18:54) So I think there are two, maybe three transitions that infrastructure as code enables. So obviously it automates a lot of the processes in the cloud, and policy as code is one of those transitions that really gives you a testing framework for your cloud infrastructure so you can test things very early on, also known as shift left, because you're doing security QA before provisioning the code into production. Another cool thing is the rise of imperative languages like Pulumi and CDK. So it's lowering the barrier for a lot of engineers that don't want to learn a new infrastructure as code DSL. They can just type in Python or TypeScript their cloud infrastructure into safe state, which is exciting.

(Barak at 00:19:48) And I think that the third thing that is exciting to me is to see how different companies use those infrastructure as code frameworks to solve other problems for which it's not automation, but governance. So one of—I know it's not that exciting, but for me it is, so it might sound strange—tagging. Everybody is tagging resources in the cloud. It seems like a tedious task, but there are some amazing patterns of how people are using tags to govern their cloud resources at scale, from cost-related tags to security-related to ownership-related tags, and they're automating those processes using infrastructure as code.

(Barak at 00:20:35) And also some observability tags that are there. So, for example, if you want to track which specific code led to provisioning a specific resource, you can do that using tags. And when you combine that with the two other things, which is imperative languages and policy as code, you can create really cool stuff around it. For example, don't let the dev team create instances that will cost you more than $500 a day. That's a cool policy to have, and it's a very easy and scalable way to automate governance in your organization.

(Barak at 00:21:13) And you can make teams very independent if you give them those boundaries very early on while they're developing. So you'll just have a unit test that will fail if you try to provision a resource that is too expensive for you.

(Joel Beasley at 00:21:26) That's pretty neat. And you can do that with your software or no?

(Barak at 00:21:30) Yeah, yeah, you could. We're enhancing more and more those experiences every day, but those are some of the cool stuff that I've seen people doing.

(Joel Beasley at 00:21:40) That's exciting. That's exciting. When will—this is a question about the future—when will code be able to just write itself?

(Barak at 00:21:49) I guess I'll have to find a new job then. So for some cases, it's already happening. So a few years ago, we had to write rules in if-else conditions, and then decision trees became popular, and then random forest for machine learning. So a lot of the if-else conditions are now automated in a manner of machine learning algorithms, only for specific use cases.

(Barak at 00:22:22) So you know how to automate the process of creating conditions or condition trees, and you already have some deep learning algorithms that know how to harvest code from GitHub and recommend to you how to write a new type of script for a specific purpose. So I guess—

(Joel Beasley at 00:22:41) Really? That exists already?

(Barak at 00:22:43) Yeah, for specific, very simplistic tasks like calculator, et cetera.

(Joel Beasley at 00:22:48) So it's not like watching my code editor or IDE and giving me—it's like looking to see what I'm writing, and then it's giving me suggestions based off of the aggregate knowledge of GitHub. It's not that sophisticated yet.

(Barak at 00:23:00) Yeah, and it would be interesting to see if code would be able to write itself one day.

(Joel Beasley at 00:23:06) Just very advanced. Like, you know, when you're typing a Google email now, they predict, you know, several words in advance. I don't know if you use Gmail, but they do that now. I would like my code to do that. I would like it to predict a thousand lines in advance from my first line of code.

(Barak at 00:23:24) Yeah, I think that the thing that I'm most waiting for is code spaces, like just having the IDE over web. That's the thing that I'm waiting for. And then autocomplete, that would be the next great thing, I guess.

(Joel Beasley at 00:23:39) We'll just get Elon Musk to give us one of those Neuralink embeds into our brain, and then we can just think the code into existence.

(Barak at 00:23:46) That would be amazing.

(Joel Beasley at 00:23:48) Yeah, it'd be faster than having to use our fingers.

(Barak at 00:23:51) Yeah, probably I'll have most of the code written while I'm sleeping that way.

(Joel Beasley at 00:23:55) That happens to me the most. Yeah, yeah. We definitely—or you would talk to some sort of AI consultant. So for example, I would be the consultant. You—we'd be on a Zoom call. Unless I told you, you wouldn't even really know I'm an AI consultant, or you might. But I would seem very human, and I'm just taking information and asking you questions and then ultimately output an application at the end of the call.

(Barak at 00:24:22) Where do I buy it?

(Joel Beasley at 00:24:26) I'm taking investment now. I got a new company called Century Returns, so it's gonna be a hundred years before you get any money back.

(Barak at 00:24:34) Well, I'll go for the subscription model for now.

(Joel Beasley at 00:24:41) Yeah, just wait for the open source version, right?

(Barak at 00:24:43) Right.

(Joel Beasley at 00:24:45) All right. So when people are trying to understand cloud security, right, they see you as an expert. You're in there, you're creating businesses, you're cloud security, right? What are some common blind spots that exist in cloud security?

(Barak at 00:25:00) That's an interesting question. So I think that about a year ago, we did a research scanning 2,000 random GitHub repositories that had together more than 23 million downloads. And we found out that almost one in every two infrastructure as code repositories had a misconfiguration. Some of them opinionated, some of them not. And I think that the most common one was not having logging in place, so auditing does not come turned on by default.

(Barak at 00:25:33) But then some other best practices like backup and recovery, encryption, and networking issues were the issues that are not configured well by default. So it is common to use an open source module and to not have those turned on. The thing that I would suggest when using those: run Checkov, the open source tool, on top of them, or a product, and validate that you configure those modules in a way that is good for your business.

(Joel Beasley at 00:26:03) Interesting. Okay. And then at what point in the process do I do it? Do I do this way before? Like, do I take a dependency I want and scan it before I even start to integrate it, or do I run this on all my existing code?

(Barak at 00:26:19) So both. Usually a module will take a set of defaults that you can play with, so you can scan the module directly, but you can also embed it in your code and use the different variables that you already have in your Terraform, for example, and see how they combine when you combine two modules. If you are doing that while developing, that's great. You can fix that as you code. If you want to get visibility of what's happening in production, also to other teams, you should probably monitor your runtime environment too.

(Barak at 00:26:55) So if you're, let's say, a team of two running infrastructure as code and you don't want to break each other's infrastructure, you probably both of you would like to run infrastructure as code scanning as you code, and also during the CI/CD pipeline. So when you merge into a single branch, you'll see that you are in a good state. And also scanning your runtime environment for misconfigurations in case that someone is doing a change manually through the console to see that it is still consistent with best practices.

(Joel Beasley at 00:27:29) And can you explain this concept of shifting cloud security to the left?

(Barak at 00:27:34) Yes. So the farthest left that you can go is in the IDE. In the IDE, you have the code. You are working usually on a specific file, and you can fix a misconfiguration as you're writing the code. The second phase would probably be the pre-commit, where you can have a code scanner scanning before your commit and telling you, "Hey, you shouldn't commit that into a common repository." The later stage would be during a code review to have an automated process that is annotating your code for misconfigurations. The next phase would be continuous deployment, where you already have variables that are representing a real environment and you have a plan of a real environment. You can scan the plan and scan the changes that are about to apply and stop a build and stop a deployment if it does not adhere to the specific policies that you think are important. And the last stage would be on runtime, just to make sure that no changes are being applied directly to runtime without having those best practices in place. Each step in the way, the farthest left that you would go, that's more productivity because it takes only seconds to acknowledge a change.

(Barak at 00:29:00) And the context of it is just you, the individual engineer. And as you go right to the code review, it becomes a team problem because a whole team needs to review that pull request, this code change. And as it goes to deployment, that might be a whole department. And when it's going to production, that might be a whole company. But in the right, you have the most context of how a real environment is being provisioned and how it looks like.

(Barak at 00:29:29) So the farthest right that you will go, you will have more context, but less individual control and less independence. And the farthest left that you will go, you will be more independent and have faster feedback. Does that make sense?

(Joel Beasley at 00:29:44) Yeah. How do you take the context from the right and pipe it over to the left?

(Barak at 00:29:49) That's a great question. So there are a few ways of doing that. One is having the same policy being checked across the entire pipeline from the right to left and from left to right. So, for example, making sure you have encryption on the resource under the same attribute and the same values all across the different steps. And the second thing would be to maintain some kind of database keeping the state of both the code status and the production status and the ability to correlate those two into a single picture that will tell you, "Hey, this is your current posture in code and in cloud, and those are the actions that you need to take to fix that."

(Joel Beasley at 00:30:35) How far left do you go?

(Barak at 00:30:38) On our product, we go up to the code in the IDE on each of those stages. So from VS Code to GitHub Actions, GitHub application, Terraform Cloud for deployment, and AWS, GCP, Azure for production. And the same goes for other version control systems and CI/CD pipelines and clouds.

(Joel Beasley at 00:31:03) So there's a plugin inside of VS Code that will actually be running while I'm writing code?

(Barak at 00:31:07) Yep, yeah.

(Joel Beasley at 00:31:09) That's so cool. That's really neat.

(Barak at 00:31:11) Yeah, it's pretty fun to use.

(Joel Beasley at 00:31:15) I think Palo Alto Networks would buy this.

(Barak at 00:31:20) Yeah, they just might.

(Joel Beasley at 00:31:24) How do you manage burnout? All right, so you're building this company, you're doing this new, difficult thing, you're interviewing hundreds of people in DevOps, you're mapping these spaces, coming up with these tools, solving these problems. It's a lot of work. You have a family, I'm assuming. Like, how do you get to spend some time with them? How do you keep yourself excited?

(Barak at 00:31:46) So you hire very good people. I'm lucky to have amazing partners, amazing investors, and an amazing team. So they're obviously doing a lot of their work. And you need to choose where to focus. So I know that I mentioned 120 conversations. We chose only a portion of those and said, "All right, those would be the design partners for the first idea." So you focus on a specific issue, and then you get a lot of the noise out. And to be honest, from there, it's really a lot of hard work. It is being an entrepreneur. You can't prevent burnout. You can try to optimize. You might have sometimes when you work harder than others. You need to find the time to rest and to spend time with your family, and you need your family to support you doing that. So I have an amazing wife that is supporting a lot on what we're doing. And you need to love what you do.

(Joel Beasley at 00:32:49) Yeah. Do you go to the beach a lot?

(Barak at 00:32:51) I love going to the beach. I'm trying to go every weekend when COVID is not on. So yeah, we have an endless summer here in Israel. So almost every Friday, we'll go to the beach.

(Joel Beasley at 00:33:05) Yeah. I live in Florida, and we're known—the town I live in is a number one beach in the United States sometimes. You know, every year they give the award out. It's like we get it sometimes. But yeah, it's always summer here.

(Barak at 00:33:20) Yeah, so it's fun.

(Joel Beasley at 00:33:22) So what would be the hardest—you mentioned, you know, your wife. Right? I remember I actually sat down my wife and told her we were having our first child. At the same time, I was starting a business. And I had started a business previously and sold it, so I knew what it would take. And I said, "This is going to be a very difficult couple years, but if we can get through this, what's gonna be on the other side is we're gonna be able to give our kids a life that we want to give them." And so even though we had that conversation and we were both in agreement, it still was a difficult path. And we're just barely—like, you know, we're at the point where what we're doing right now is we're just hiring more salespeople. Like, we know what works. We figured it out. Now we're just scaling it. And so we're kind of like, "All right, we're out of the woods of figuring out, do we have something?" We know we have something and it's growing. But it's not easy in a relationship. And so like, do you have any tips or any advice for founders interacting with their spouses?

(Barak at 00:34:29) Wow. That's a tough one. I started by telling my wife probably the same thing. It's going to take a couple years, and then we're going to get a better life. And her answer was, "That's what you told me a couple of years ago." So it was an honest conversation and an honest call. And she was really helping me making my dream come true. So I don't know what convinced her, but I'll have to ask her today. My tip is try to listen when you're needed and required at home. And when you are, clean all the rest and put it aside and be at home when you're needed.

(Barak at 00:35:21) Pay attention to your kids. I have two. And when they need you, put the work aside for a couple of hours. The way that I try to build my day is I'm working up until I need to pick up my kids from kindergarten, then I have a few hours with them, and then when they go to sleep, I continue to work. So basically, my solution is just to sleep less.

(Joel Beasley at 00:35:46) That's funny. When you have kids, the answer to everything is sleep less, you know.

(Barak at 00:35:51) Exactly.

(Joel Beasley at 00:35:55) I was sitting around asking my wife, I was like, "Am I supposed to be this tired?" Like, my brother and my stepmom are both doctors, right? And so I was asking them, you know, is this normal? Is this amount of tiredness normal? And they're like, "Well, you know, you're raising two kids." I have two kids that are young, like under the age of five. And they're like, "You're raising two kids and you're working." They're like, "It's normal to be tired after eight to ten hours of work and raising kids." And I was like, "Okay, good."

(Barak at 00:36:26) Yeah, mine are probably the same age.

(Joel Beasley at 00:36:29) Yeah. Oh, man. So what inspired you to become an entrepreneur instead of just working at a job?

(Barak at 00:36:36) So I always wanted to. I really like to create stuff, so I always build stuff, from building stuff at home like cabinets—I'm a hobbyist carpenter—but also creating software is something that I really like. And I felt like I just might have some good ideas that need some implementation. So with a little push and help, it just started.

(Joel Beasley at 00:37:05) Are you still getting time on the weekend to do some of the carpentry?

(Barak at 00:37:10) Well, we just moved into an apartment, so it's been a few months where I had some chances to do stuff at home, working on some new cabinets. But if we would have not moved a few months ago, I probably wouldn't have touched any of my tools.

(Joel Beasley at 00:37:28) Did you move because of the acquisition?

(Barak at 00:37:31) No. We moved much before, just to a larger place because we had two kids being born, and we needed a larger apartment.

(Joel Beasley at 00:37:42) Yes. Yes. My wife and I, we've been all over the United States. We've been looking in Texas and Georgia and Florida because we're like, we need more space for the kids. As they get bigger, they get more stuff, they need more space.

(Joel Beasley at 00:37:57) And what you have, you know, when we moved in together, it was me and her. And that was enough space for two people. But for four people, we need more space.

(Barak at 00:38:07) Yeah. Exactly.

(Joel Beasley at 00:38:09) So were you able to take any of the leadership lessons that you learned in the Israeli Defense Force? And how did that impact, you know, Bridgecrew?

(Barak at 00:38:20) Some of the things that really helped is that I knew most of the engineers before suggesting them a job. So when you work as a team of engineers at the Israeli Defense Force for a few years, you get to know so many other engineers from so many projects that you know who you can work with really well and who would have the right spirit and the right culture for a startup. So it was relatively easy to recruit and relatively easy to work together because we are used to working together. And one of the things that, at least in my unit, was very fun is every engineer was very independent on what they're doing. And the management skill was being an enabler manager, or a servant manager, also called in the Spotify terminology, where as a manager, you are here to help your engineers to succeed, and you nurture that messaging all the time.

(Barak at 00:39:29) And if an engineer really wants to learn a new technology and believes that it will benefit the product, you advise them how to do that or ask them how can I be the best resource or what other resource can assist you? And this is one of the things that we tried here in Bridgecrew to have as a culture. And this is one of the things that assisted my unit in the Israeli Defense Force. And I was lucky to have that experience.

(Joel Beasley at 00:39:56) So you don't make your guys do push-ups if they break the code or anything?

(Barak at 00:40:02) No, no, we don't have that. In our engineering unit, it wasn't like that. It was like, if you broke the build, you should probably fix that by the end of the day.

(Joel Beasley at 00:40:14) That's much more reasonable and effective.

(Barak at 00:40:18) Yep.

(Joel Beasley at 00:40:19) Oh man, this is great. What else do we need to get out there into the world? We're going to tell people to go to Bridgecrew and to sign up and check it out, right? But what other sort of value or conversations do we want to put out there?

(Barak at 00:40:32) So I think that one of the things that we need to discuss is how to encourage more engineers to be independent on the work that they're doing. Because when you really want to be in the zone while you're writing code, you want to have less friction, meaning less communication with people that you usually don't work with, when you want to create a new application. So we want to enable productivity. We want to enable creativity, and there are a few ways to do that. So test-driven development, in my opinion, focuses people on creativity and productivity because you know what you're going to write, and you know that you're going to write it well and in a maintainable manner.

(Barak at 00:41:21) And then you can move on to the next interesting task. And when you have—if you agree with that methodology of creating infrastructure that can enable each and every engineer's superpowers, and I believe that cloud automation enables engineer superpowers and to be more productive—you should really think as an architect or a leading senior engineer, how you can enable more and more of those processes. Policy as code might be one of them, but there might be other processes, like GitOps or other kind of similar pipelines that could really encourage each and every engineer to be more productive when creating a new application.

(Joel Beasley at 00:42:10) Engineering productivity. It's something that people have talked about forever.

(Barak at 00:42:16) And developers are the new kings. So productivity of kings is important.

(Joel Beasley at 00:42:23) Have you played around with any of the productivity tools for developers?

(Barak at 00:42:28) So I like to think of ourselves as a productivity tool, and I had a chance to play a lot with observability tools. So a lot of our production monitoring is—we are using a lot of tools to automate a lot of those processes. Obviously, there is PagerDuty for incidents and response, but one of the tools that I really like is Epsagon, which is a very cool OpenTracing-style tool where you can just track your topology of serverless functions, containers, Kubernetes clusters, and really understand how a trace of an event in the system looks like. And for us, it's a productivity tool because if we get a PagerDuty of something is broken, instead of taking hours to investigate all the different logs, we have this trace map where we see an event coming from one service to another microservice to another microservice, understanding what caused a specific issue. And then we have PagerDuty distributing that to the right team using the right governance tags that we talked about at the beginning of this talk.

(Barak at 00:43:37) So when we are designing today a new application, at least inside Bridgecrew, we have a set of tags and tools being attached to those. So each time an alert is happening in production, we'll have an automated way to distribute the alert to the right owner in the team and in a way to automate the process that that owner will get all of the different context of the trace of an alert that have happened in production. So that way, the productivity of a production alert is super, super high, and the context that it has is super, super high. And then the time to resolve is usually minutes or seconds of creating a new commit and pushing to production. So we have those kinds of pipelines that help us to make everything more easy to observe and fix, and catch in real time.

(Joel Beasley at 00:44:37) That's super neat. And I'm curious, have you ever experimented with developer efficiency tools? So tools that are going to basically track developers, the code they're writing, and then somehow determine their efficiency or their abilities?

(Barak at 00:44:57) No. So I think that I'm not measuring efficiency of, like, are you writing code that is not repeatable, or are you writing a lot or not bugs? But that's not the way that I'm measuring the engineering teams. I'm just trying to measure whether—I'm really asking the team, are you feeling like you're doing the same task over and over again? Are you getting bored?

(Barak at 00:45:19) Are you getting burned out from production issues, from bugs, from Jira tickets? And then we're trying to think together. Right? You have this bug one or two times. How do we create an automation that will prevent that from happening again?

(Barak at 00:45:34) Or it took you so long to investigate the root cause. How do we create an automation that will give you more context so the next time you have to investigate? It will be like just snap and you have it. So the way that we try to encourage engineering productivity is doing the retro. We're asking what issues did we have?

(Barak at 00:45:55) Are they repeating? How can we prevent them from happening again in a larger scale? Does it make sense?

(Joel Beasley at 00:46:03) Oh, yeah. No. That totally makes sense. I'm going to send you over a couple. There's Pinpoint, GitClear, and GitPrime.

(Joel Beasley at 00:46:11) So these are three different companies that I know, and they're all pushing forward in interesting, unique ways. Each of them has their own interesting way of how they're helping better understand developers and the code that they're writing. And I know all of them. And they all started as engineers. Like, they're all engineers and they have engineering teams.

(Joel Beasley at 00:46:31) And they wanted to help make their engineering teams more efficient. And so they created these tools and, something in the back of my mind, I was just like, you know what? You should check some of these tools out because it's a whole category. And I think, you know, because my background is software engineering for seventeen years. You've done it for a long time.

(Joel Beasley at 00:46:50) I think you would find them interesting to say the least.

(Barak at 00:46:54) Yeah. I've seen LinearB from the same, I think, category of tools.

(Joel Beasley at 00:46:59) Oh, I haven't heard of that one. What's it called?

(Barak at 00:47:01) LinearB.

(Joel Beasley at 00:47:03) I'm going to check that out. I love how they—because as a developer, it's really hard to quantify your efficiency or however you want to do it. So when I saw this category of software emerging, I was just fascinated by how they're trying to solve this problem.

(Barak at 00:47:19) Yeah. It's almost like Jira should have been. Right?

(Joel Beasley at 00:47:23) Yeah. Yeah. Dude, this is great. What are you learning right now as a leader?

(Barak at 00:47:30) Currently, I'm trying to learn how to scale. So currently, I'm leading a portion of the engineering team and also our developer advocacy. So as an open source company, we have developer advocates, and we're trying to learn, one, how to do developer advocacy better in our space. It's not an area that exists so many years. I think that people are doing evangelism for only five years, officially, something like that.

(Barak at 00:48:01) So I'm trying to understand how to do that better. And the second thing is how to scale my current organization from, let's say, 40 people to double than that, and how to use larger enterprise resources to double down our pace.

(Joel Beasley at 00:48:20) Are you a part of any groups of like, other founders or chief technology officers that are having these problems right now too?

(Barak at 00:48:28) Yeah. So we have a few local groups here in Israel. Product-led growth group. We're CTOs of product-led growth company that are building developer tools are trying to help each other, and also some tech unit alumni groups. There are some other great publicly accessible groups with great material that I would recommend.

(Barak at 00:48:56) There is the Heavybit Guild that I really recommend to follow. If you're about developer tools, they have some great content. And also there is a great set of groups around cloud security. There is also cloud security leaders there that I really recommend to join into, which is the Cloud Security Forum. It's a Slack group, which has some great material if you really want to either lead a project in cloud security or join one.

(Joel Beasley at 00:49:25) And what was the first one? You said Heavybit Guild?

(Barak at 00:49:29) Yeah. So Heavybit is originally a VC for dev-focused companies, and they have a library of great blogs, podcasts, and videos that I really recommend.

(Joel Beasley at 00:49:46) Excellent. That's what we do. We find great information and we help push it forward. I love it. Thank you so much for listening.

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