Strengthening security culture: the CISO-CTO dream team

Steve Touw: we needed the security to be there so that we could change our release cadence, the shift left. and our architecture changed quite a bit too. most of our customers are SaaS now, used to be self managed on prem type solution. And we've really tried to push the SaaS solution because it, it helps us with releasing faster, getting features in our customers hands faster, but also allows us to deploy security fixes more quickly as well. So, that forcing function of having to deliver more quickly, of providing it or making us do the shift left to be able to do that. it kind of like flipped it on its head and also allows us to fix problems more quickly as well. 

Andy Schneider: Hello, and welcome to Code to Cloud. I'm your host, Andy Schneider, Field CTO at Lacework. And we have a really special episode today because it's the first time that we have two guests on the show. I have the pleasure of talking with the CTO at Immuta, Mike Scott, and Immuta's CTO, Steve Tao. Immuta is a leader in data security whose platform is trusted by Fortune 500 companies and government agencies around the world. In my conversation with Mike and Steve today, We'll be able to talk about the working relationship between CTO, and how they strengthen the security culture at Immuta by working together. Mike and Steve, welcome to the show.

Mike Scott: Thanks for having us.

Steve Touw: Happy to be here.

Andy Schneider: Wonderful. So it's really special. We usually only have like one guest. So this time we have two guests in here. And I'm super excited because sometimes we talk to CTOs, sometimes we talk to CISOs, but we usually don't talk to them in one show. And that's something very typical what happens also in companies. You talk to a CISO or to a CTO and you might get different perspectives on that. time when we talked, I was really impressed How you have that focus on a shift left culture. Maybe, let's start with you, Mike. What does shift left mean for you? And what does culture mean for you?

Mike Scott: Well, you know, I think from the industry side, shifting left is clearly moving security as far left, you know, in the software supply chain as possible. I guess I would say culture is a big dependence on that because a lot of times you're asking developers, either to change how they do something or at least slightly modify it at a new process.and so I think there's, there could be a lot of angst in the beginning, right? Of you're going to delay my release. You're going to do these things. so I think, you know, just as you look at, you know, where efficiency is gained, you know, that to me has been kind of what I've used to sell, you know, that, that mindset, right? Of, hey, you know, security is inevitable. And we can all look back and see. where it's delayed us, you know, when security was brought in at the end of the game. Versus if we can move our mindset to really thinking from ideation all the way through creation to delivery of software, we're going to meet a lot of those challenges early. And then what we've seen, I think the outcome is, more timely release and less of security being a roadblock and more just like a small speed bump along the way.

Andy Schneider: I really like that. Steve, from your perspective, if you look at, especially that timely releases, the roadblockers and bumpers from security, how does it look like for you?

Steve Touw: Yeah, so I think, you know, Mike nailed it on the head, but shifting left may feel like more work in the short term, but it actually means less work in the long term. I believe that also in terms of culture, It's very hard to force culture on people. I think that really starts in your hiring process and, you know, Immuta being a security company that, Fortune 500 companies, buy us for our security product or data security products. So. People that want to work at Immuta care about security, right? Like they wouldn't take the job if they weren't excited about what we're doing. So I think we're lucky from the perspective of that our employees are already of the security mindset, I would argue, especially our engineers. And they're also the mindset of, they don't want to waste time on things. They don't want to waste time on. So they understand the value in shifting left and not having to deal with fires if you have to deal with it further to the right, so to speak.

Mike Scott: definitely I think we have the advantage, right? We work for a security company, so clearly the mindset is there, but I would say even in other organizations like Ben, once you can convince developers that secure coding is a tool in their toolbox, and that it's valuable, and companies pay for that tool, you know, it doesn't take long to sell them that, hey, security is important. And then after that, it's really looking at, you know, how can you make this work in their day to day job versus reinventing how they do things. And once you can come to that consensus of, hey, this is what needs to happen and why, the developers tend to kind of pick up and run with it. it's actually one of those exciting things as a CISO to see, right? To see when your engineers start leading the charge on security and actually forcing you to catch up to them.

Andy Schneider: I like that. Mike, you, you more or less said like you have to, you know, I wouldn't say have to, but you sell it to developers and engineers so that they understand what's in it for them. and Steve, you also said that it shortens it on the long term. So it's like, might be more, tasks, more intensive, at the short term view, but long term you benefit from it. Is that measurable? Yes. Thank you.

Steve Touw: probably there's a way to measure it, but we don't measure that I think the way it's measured is By the way, we used to do things the way to do them now and seeing the pain that's gone away you know, we used to have You talking back in the very very early days of immutable We've been around for eight years now, but like back when we were, you know, 10 person company We didn't have the full, everything shifted left, obviously. So sometimes a customer would take our software and say, Oh, well, this didn't pass the vulnerability scans. And so then we'd have to do a fire drill. And, and so like this, this fire drills are minimized if you're able to shift left. And so I think the team understands that they would prefer to. Work within the confines of how we find these problems early and have to deal with emergencies and get distracted. So at the end of the day, the worst thing for an engineer is , to have to, you know, lose focus on what they're doing to go jump to another task. I think you guys have probably seen those studies where just by context switching can cost an engineer hours. and so the less context switching we can have the team do the better, which really comes down to focus. And so , if they know the policy, they know how to, how to run through our processes and make things work. They know they can continue to focus on that context switch. And at the end of the day, that's like a huge win for them, but also off us, obviously, because they're getting more work done.

Andy Schneider: Mike, from your perspective, is there something measurable in it?

Mike Scott: you know, absolutely. And I think even before that, I think , what I saw was, you know, we went from, I can't remember if it was monthly, every two month releases to we have releases every two weeks now. And if I think back to when I started over three years ago, the idea of being able to have criticals and highs patched in a two week timeframe. , that was just not on our radar. Now, we were an on prem software and those type things, but Because we built the process to scale and really focused on how to get better over time What we saw was, you know, when we got to this two week release cycle is we weren't having to change that You know, the security reviews are still happening So I think there's that so the business clearly can move at scale But when we look at vulnerabilities, you know, we're container, Kubernetes, so if you've worked with Kubernetes and in that space, it's not uncommon to have thousands of vulnerabilities in a container, and maybe only a few are exploitable, but just having that situational awareness at any given time, it was a huge gain for us, but also because we went from that shift left and started looking at you. You know, what OS are we running on? What containers are we deploying? What are our customers supporting? We really narrowed that scope to where now you can have, you know, we're looking at maybe a hundred vulnerabilities across a container, and most of those are informational on Lowe's. It really changes the conversation with customers, but it's also a clear, demonstrable way to show we've gotten very good at what we do, and a lot of it is from that shift left. And I think it's also allowed. Our teams to understand the security impact sooner. And so when a critical vulnerability comes out, it's, the engineering team has already decided, are we vulnerable? What's the fix going to be, you know, within hours of getting that notification versus responding to a customer's inquiry before. So, yeah, I think, you know, I can show metrics, but I think also if we really went back and looked at how we've evolved, how we've evolved. It's great to see that the program that was built collaboratively has not slowed the team down. 

Steve Touw: you brought up a good point on, the release cadence too. obviously we didn't change our release cadence just for security, but we needed the security to be there so that we could change our release cadence, the shift left. and our architecture changed quite a bit too. most of our customers are SaaS now, used to be self managed on prem type solution. And we've really tried to push the SaaS solution because it, it helps us with releasing faster, getting features in our customers hands faster, but also allows us to deploy security fixes more quickly as well. So, that forcing function of having to deliver more quickly, of providing it or making us do the shift left to be able to do that. it kind of like flipped it on its head and also allows us to fix problems more quickly as well.

Andy Schneider: you could almost say that, the release cycles became, More reliable, thanks to shift left, 

Steve Touw: Absolutely. Absolutely.

Andy Schneider: what I feel if I, if I listen to both of you is that you work more closely together than maybe in other companies, CTOs and CISOs work together. Sometimes CISOs are considered the enemy of, of the rest of the tech organization. So, how does that work for you? How do you become not an enemy as a CISO and the same from your CTO perspective, but Mike, how do you do that so that you become a friend of this, of the CTO?

Mike Scott: You know, for me, I think it's a handful of things, but first is, you know, working to establish trust and understanding. You know, at the end of the day, Steve and his team have a job to do. They have goals and priorities. We have customers that have expectations and It's foolish of me to think that I can write a policy or expect a procedure to be done if I don't understand that into some depth. So I would say for me, I invested a considerable amount of time up front, really trying to understand what we were doing and trying to draw the team in. And I think what was awesome through that moment was with Steve and some of the other leaders on the team support. I had a couple of champions who jumped in early. And so if you look like our SDLC today was written by engineering, you know, it was under my guidance. But when you can actually look at a policy that was written by the team, that's also living under it, things start to flow and they start to work organically. And out of that, you know, I think you see also as that team feels heard. You know, is one thing, but also I really try hard to recognize the team because as a CISO, it's great to say that, you know, we've done SOC 2 and we've done ISO certifications, but, you know, my team couldn't do that without Steve's team and without a lot of the business really pitching in and doing a lot of lion's share of the work and also adapting the way they work to these new procedures.but giving that credit back, you know, I'm constantly reminding our governance committee, Hey, you know, we put a lot of stuff on this team to meet ISO requirements and slot 3 requirements. and for me, that's defending my partner, Steve, right? It's saying, Hey, this is taking extra time. This is taking away from his ability to deliver product. And so when they're hearing Steve say it, and they're hearing Mike say it, and they're hearing other parts of the business say it, It's also helping get that justification for resources or at least changing prioritization. But for me, it is, I got to know what's important to Steve and I got to help Steve accomplish his goals, but I've also got to make sure he understands what I need and why I need it. and I think the last part, especially for new and emerging CISOs or security leaders is being able to be honest with what do you need today? Like it's one thing to talk about the end goal and like, Hey, here's where we want to be. You know, fully ISO certified in the next many years. It's another thing to come to a reasonable, let's go get this done, and let me help you get there and help lead the way. So I think it's a lot of time investment and it's a lot of collaboration and a lot of listening.

Steve Touw: Mike said it well. I've got a simple answer, which is Mike is a realist. So he knows that we're not going to be a hundred percent perfect on everything he dreams up that we need to do from a security perspective, he's going to get it. Do a phased approach. and like you said, you know, it's have realistic timelines and he's not going to always work directly with me. I mean, frankly, I would argue he works more closely with my VP of engineering than myself in a lot of cases on implementing some of these things. so I think part of it is that Mike and his team are going, you know, down into the engineering organization, which I'm like, that makes me happy, right? I don't have to be the gatekeeper for everything that they need to do. So that builds some rapport with the engineering team as well. I think we've just done a really good job of, setting expectations with each other and being realistic.

Andy Schneider: So, I heard being realistic, being honest, trust was something that, Mike, you mentioned. Trust is like the foundation of everything for me. It's almost like a cultural glue. Trust must be there.And being heard. I heard it from both of you, like if you go to your engineering department and talk to two engineers or developers, everyone wants to be heard. So how do you do that, Mike? So If you talk to developers. How do you make them listening to you?

Mike Scott: I don't know if I could make a developer listen to me, but I think it's, trying to identify who those champions are early. cause every organization's got some folks,I'll mention first names, hopefully it's okay. But, you know, there's a few folks that stood out early in our team. Little shout out to like Cody and, and Barry on Steve's team. Matt, Alan, just, you find those people who are really excited about what you're doing. And you bring them into meetings and you get them involved, you know, in discussions, like when we were looking to really ramp up our AppSec program and go from, you know, some commercial tools, some open source tools, different tools for different groups, we brought in those champions from every level, you know, so individual contributors all the way through and, and we talked about the problem we were solving as a problem versus me dictating, Hey, I really love X, Y, Z as a tool. and at the end, you know, in that particular instance, the decision was we went with the tool that engineering liked the best. and I think some of that as a CISO is understanding that while it's harder for me to understand our current AppSec providers interface and the way they work, the engineers understand it perfectly, you know, and so a lot of those gains we got was from being somewhat a little bit selfless and going, you know what, I need the product to be more mature and our ability to respond to vulnerabilities to be quicker. How we get there does not define by the CISO. How we get there is defined by the team. And we put a lot of effort and I would say, you know, for me, I definitely put more effort in the beginning of demonstrating why what I wanted mattered, why it needed to happen, and if it needed to be a certain way explaining that. But as I did that and really was transparent with the team, you really saw that those champions started wearing off on other members of the team. And then Steve's point we started seeing is, you know, I was no longer in the middle of releases. Like I'm kind of like a checkbox at the end, which is perfect. It's where I want to be. Like all the security stuff's already built into the release and I'm just agreeing to the messaging at the end. It's a beautiful thing for both sides because now the development team is fully in charge of their delivery and they're able to know up front whether they're going to have an issue. So I think the more that they saw that and just the more we kept going back and I'm not, I've made mistakes. I mean, I'm sure Steve could point out a few. we all do, but it's, it's not about pointing out the mistakes. It's about taking a step, discussing what happened and readjusting. And I think the critical part there has been the buy in between You know, really all of Immuta, but especially from an engineering team to be able to do that and say, hey, you know, we tried this, it didn't work. Let's all take a step back, regroup, and let's fix it, in a very, non adversarial way. What it's led to now is most of the stuff Steve's team's doing is automated. So, yeah, I think it is just a lot of continuing to show that you deserve the trust and continuing to earn it every step of the way.

Andy Schneider: a follow up question to that. So you mentioned those guys that like were the first champions. I would call them first champions. it's a typical thing that in DevSecOps, you build these with Ambassador. Programs are champions. Steve, a question for you. Those who did that initially, did you expect that or did that just happen that they were the ones being, let's say, more security savvy?

Steve Touw: you know, as I mentioned, we have an expectation to a certain extent that everyone has some security blood in them, right, so to speak. but yeah, I don't think we expected, them to really take the charge like they did, but we latched onto it. so what are the things. That we did is we used to have our SRE team as a separate kind of org, if you will, outside of engineering, and we moved that team under engineering. so it was almost like, you know, I say this jokingly, but we had Mike Scott's plants as part of engineering. And, you know, they're in there with, with the rest of the team and they're engineers just like anyone else. So the team that's building the features is sitting right next to the team that's, you know, You know, helping them shift left and provide the containers that we use for development and, you know, monitoring our SaaS infrastructure. And they're all together in one mission. So it's easy for them to adopt change and, and understand why we're doing things. So, I think that's helped too. It's just, it's really embracing the people that embraced the security culture.

Mike Scott: it's funny because Steve, you mentioned the collapsing, putting the SRE team under engineering, you know, as a old school defined by the gray in my beard security professional, I had to admit I was a little apprehensive in the beginning of the idea of the developers and the people that run the platform that's running the code being on the same team, because you know, there's always that risk, right, of, of security kind of gets lost. And there's not a real focus on it. but because we're a modern cloud organization, it's really to my, I mean, I don't think say surprise, but I've been really happy to see that the real, bi directional feedback there, you know, because at the end of the day, the SRE team is also a customer of the engineering team. And so if their customers are asking about vulnerabilities or about, Hey, you know, why do you support this library? They now have not only a direct line of communication. But in a lot of ways they have influence over those decisions from the beginning. And so what is really created is by the time something gets to the platform, it's something that everyone feels comfortable with. I would put my data in this platform. And I think that to me has been the really refreshing thing at Immuta is yes, we hire security oriented people. But when the guiding principles, you know, to do right by data was, you know, kind of way back when I joined tagline. You really saw that, where people that ran the product, that developed the product, that run the platform, wanted to feel comfortable that if their data was in there, they could sleep at night. And so, when you take that and you start from the beginning with that mindset, you build towards something. By the time we got to our ISO certification, you know, we talked before about, you know, we went from, for sure we're going to do ISO, to being ISO certified in about six months. You don't do that starting from zero. You do that because you've started fundamentally different, and you've been building things, and the team has been passionate about doing it in a way that quite frankly is what you and I are looking for, Andy, right? Mature, automated. It's selfish for the engineering team to want things to be automated. It's, I don't want to spend time on what Mike needs, so let's automate it to death, make him happy, and move on. And I think that just creates that super healthy ecosystem, right? Where you have all these people who are passionate. And I have seen certain folks rise to the top. And I think we all have them that are not only carrying that message into their day to day job, but outside, but they're also contributing things that my team reuses. And we have, like our exception management process internally for all security exceptions was built. by a gentleman by the name of Chuck on the team, because he had responsibility for that in his role. So he engineered it, created the JIRA workflow, all the checks, all the balances. And when my analyst took a look at it, he was like, let me just copy that and paste that into our JIRA. That's our exception management. I mean, that's a really beautiful thing as a CISO.

Andy Schneider: Steve, Mike mentioned automation a couple of times. I know that it's like a very important thing from an engineering perspective. maybe you could just give some insights, why is automation so essential?

Steve Touw: Yeah. I mean, this goes back to the release cycle conversation that we were having. To go from a quarterly self managed release to bi weekly deployments to SaaS, you've got to have automation. There's just no way to do that without it. so, it took us a while to get there. I don't want to make it sound like that was an overnight thing. We had to change how we thought about releases. We had to change how we thought about building features. and making them, you know, smaller bite sized chunks that we could push out, and get feedback more quickly and iterate on them, we had to almost, we're forced into a waterfall model with, when you're thinking about the self managed releases and such a big gap in time when you push those. So, yeah. I'm trying to remember exactly what the process was before we really automated all this, but I want to say we had like a month long checklist process to get a release out the door. and now it's just like basically almost a click of a button, where, you know, our VP of engineering, our platform lead and our release manager have pretty much completely automated this. as part of the CI build and the scans that we run, and even automation on why our engineering managers think certain vulnerabilities don't, like, why they're not actually a risk to us and explaining that as part of like the automation of the build process. So it's pretty cool. Like we've automated this to the point where I would argue if we could write features faster, we could even do it faster than every two weeks. But, we just haven't, haven't gotten that part of it, down yet. But yeah, that was the driving force for us is like, how do we get more iterative with the features that we deliver and get them in customers hands faster on SaaS? And like, that was really the driving force for all of this, I would say.

Andy Schneider: That's really, super cool because I've, there a couple of times when I had conversations with CTOs that it was very, I would say, Feature and delivery driven. So you want to deliver more and quicker and automation helps there. And Mike, you mentioned that, you have to break down your big goal, like the ISO certification into smaller bytes. So smaller pieces. How do you do that? if we go back to that ISO certification, did you also like break that down into those smaller elements? How did you do that?

Mike Scott: I think, you know, in the very beginning, First and foremost was looking at what's the company's objectives, right? As a security professional, if you can tie what you're doing to what the business is trying to accomplish, that's an easy win.then taking and kind of looking, you know, surveying the business of what are they looking for? Like the first compliance committee meeting that we had, There was like a list of like seven or eight different compliance things we were going to go do. We were going to go get HITRUST and we were going to get FedRAMP and we were going to get, and we were going to get, and, and so it was just listening to everyone's demands and what they would like to do. And then we had a meeting about, okay, here's, here's what these look like, here's how much it costs, here's the resourcing. And the executive team very quickly whittled that list down and we started looking at like, what's really going to move the market for us, you know? As a solution provider, one of the goals of my program is, is to secure the data that we handle, but it's also to make it easier for our sales team to sell the product. Easier for my peer on the other side to look at Immuta and go, you know what, I trust what they're doing and I'm okay with enabling the business to make this decision. and so just looking comprehensively across that and going, okay, you know, like SOC 2 was a baby step. if you've done a SOC 2 audit before, I would say it's probably the lighter out of, out of my experience having done, you know, PCI and ISO as well. In a little HIPAA work, SOC 2 was, kind of like foundational. And so we went SOC 2 first. As we were building out our SOC 2 program, though, we were focused on NIST and ISO from the beginning. You know, drawing from standards and building our program in a way that we knew would resonate with our customer base. and what we saw was immediately when we launched our SaaS platform with SOC 2 compliance, you know, we saw a lot of acceptance there. And since that point, it's just been kind of a rinse and repeat on that, right? It's like going back and saying, okay, we decided that international was a big market for us. And It's been a fantastic market for us. and ISO resonates well, you know, and so through this interactive feedback with Steve's team and with marketing and with sales, you know, I've always been really aware of, you know, this is what we want to accomplish as a company. These are the things that Steve's team needs to do. This is what sales needs. And then, you know, those just all kind of work together. Ultimately, the drive of the team is what supported that, right? Because we weren't just building enough. Not a checkbox for let's make it just enough to be SOC 2 compliant. It was always focused on if we're going to tackle, you know, software vulnerability management was our first big project, right? That's the one where we spent the most time in. Well, that made sense. We're a software company, so let's, break it down and figure out what that looks like. And through working with, Steve and Barry and lots of folks internally, we were even able to break down in our strategy of a product at what point do these jumps make sense, you know, we're going to make a change in our underlying OS strategy. Well, that's the perfect time to do this leap. so it has been a lot of collaboration, but. You know, for me, it is a risk based approach. at the end of the day, you know, if what really is going to, help us be successful. And I think what we've seen is the strategy has worked. And because we report back to the governance committee quarterly, and what's probably a very boring meeting, but continually showing, Hey, we're, we're meeting our compliance objectives where the team's continuing to grow. But it's also keeps a healthy conversation back with the business of, Hey, you remember, ISO is still a lot of work, you know, this didn't go away whenever we got certified in February, this is still last year. This is still an ongoing effort. and so I think it does continue to keep the business also aware of what's being done, but also allows me to stay in tune with what's coming up next from, from a strategy perspective. What objections? I think that's the other thing we look at is what objections do our customers have?the thing I also appreciate is our engineers have their own objections to the platform. give you an example. Our SRE team took a project on without direction from my team or coming up and, any risk assessment, but putting micro segmentation in at the node level of our Kubernetes clusters is something that normally a CISO would have to go, you know, just kick and scream and beat. The door down to get Steve to do it. Instead, I've got the team coming to me saying, Hey, we've got this great idea. We're going to do micro segmentation and do least privilege between the nodes. What do you think? It was like, Merry Christmas. I, so yeah, I think it just overall, it's just been finding those pieces that I knew would show value and then going back and proving the value was there, and then that gets us a little bit more leeway to do the next thing.

 you just mentioned objections. how does, does that happen that you. don't agree on it on something, both of you, that, that you have that, let's say conflict and how do you deal with conflicts in general?

Steve Touw: Yeah, I mean, it, it happens. Yeah. It like, you reminded me of the conversation about the access to, the logs in, in SaaS that we, you know, were having debate about too. so just like, if there's an issue, we just talk it out. I mean, it's not, it's not the end of the world, I don't think. Uh, you know, I'll raise it to Mike, and we'll find some compromise. Right. That makes sense. Using the considerations that Mike already elaborated on. I mean, it's, you know, what's our security stance on this? What is our value to the business stance on this?and we weigh those factors and we make a decision. And I think we're both willing to compromise or we need to compromise. And sometimes it's not a compromise. Sometimes it might just be a misunderstanding. And, uh, we figure it out, but, uh, I think obviously it's just like making sure those communication channels are open and it's not just an edict coming from either direction is, I mean, it sounds silly saying that, but I think that's like, that's the easy answer to it.

Mike Scott: you know, it's funny, I have a recent example. we rolled out a control on everyone's laptops a few weeks ago. and the intentions were right from the IT team, but, you know, it just created some downhill issues for the engineering team. you know, developers do all kinds of crazy stuff on their laptops, right? Mm hmm. Security tools don't always account for that. and so we were able to have a quick conversation between my team and security and compliance, the engineering team and IT, and quickly disable that and go into more of a learning mode. And I think it's funny because not a lot of organizations can move that swiftly, but a lot of that is also going back and saying, okay, you know, We turned a control on a Monday that we didn't have last Friday. It's not going to be the end of the world if we turn it off and wait a few more weeks and we iron this issue out and not taking that as a, as a personal loss. You know, it's, you're moving fast and you're trying to get things accomplished and it didn't work out. And what I love is at the end of the day, and I think this is why our team conflict is not a huge issue as we have it. But we all want the same thing in the end. We all want the company to succeed. we want security to be easy and for it to work. We want it to be there. And so when we have these disagreements, you know, it is like Steve said, it's a conversation and it's what needs to happen. And being honest about, I don't need perfection. You know, ISO does not demand perfection. The idea of risk management is there and so, you know, maybe I put something in the risk register and say, you know, Hey, we've decided not to do this for a period of time. That's okay. Like I know that's going to be acceptable It's that customer service aspect. I think that some folks miss which is at the end of the day, you know Our developers are our customers, you know security team is an IT team You know, and we've got to make them successful and do it in the best way we can. other conflicts, I would say, AI is coming up, right? AI is every part of the business has an AI use case. what I learned early in my career is if you're saying no too many times, people stop listening. And, When I say no, it's usually taken surprisingly to me as a hard set. No, that doesn't happen a lot of places, but it's also because like when we start talking about using co pilot with GitHub, it's like, well, let's do a risk assessment on it, you know, and let's be honest that we're an emerging technology company and if we're not using AI, we're probably falling behind. But also there's employee satisfaction aspects, you know, our developers want to be using. AI, and it was very, you know, it was a week long process to do a risk assessment to come up with duh, you know, of course we should be doing this. and so I think, you know, when those things come up, it's for me, it's also looking at how can I enable you versus why am I telling you no? Yeah,

Steve Touw: take a customer service type approach to all this. And that's why we're able to have those conversations. So think about that. IT change to the laptops, you know, that, conversation started by me just walking up to him at our sales kickoff. I think we were actually like having a beer at that point at the end, but, and just saying, Hey Mike, we got to do something about this. Like the natives are getting restless and he did something about it. Like,so I think that door is always open on his side. So I commend him for it.

Andy Schneider: these are really wonderful examples. So don't be an A sayer, I can second that really, no one likes them and people stop listening. And the second thing is you can raise kids, you can fly to Mars, but putting a security tool on a developers. client is a very dangerous thing. So you'll have to really be strong to do that, but there are some tools that are really working, but it's always a surprise that in my career, every developer used tools differently, and we only had surprises that we never would have imagined. Never expected. That's like mastering security if you can. Love that. So there's a funny thing. When we, when we last talked, you mentioned that you classify your employees under a disk and you have that thing with the bird. So. can you explain what you do there and why you do that?

Steve Touw: So, there's this thing called DISC, D I S C, and we don't force everyone to take it, you know, obviously you don't have to, but, we encourage everyone to take this DISC assessment, and it categorizes you into four different categories. So, eagles are very, like, they're very strong opinion, make their decisions quickly, they make their decisions quickly, They get annoyed when they're, like, people aren't getting to the point and then you have owls which are very thorough and they want everything written down and they want to read things. And parrots are, they like to talk and they're sloppier and doves are very caring. They have a customer success teams full of doves, for example. And so our engineering team is full of owls, as you would expect. I mean, there's some eagles in there and like a sprinkle of parrots here and there, but by and large they're owls because they're engineers, right? So. The reason why this, DISC classification is helpful is your communication style changes based on what bird you're talking to. So I'm an eagle and you're talking to me, you just get to the point and let's, talk it out and come to a decision quickly. And like, I don't need the 16 page document or the other, the flip side of it is the engineer wants that document. They want to sit down and read it. They're an owl. They want to understand why we're making this change. and so I think Mike has adopted, I mean, I'm putting words in Mike's mouth, but I think. He's adopted like these communication styles to the birds and, you know, importantly to our engineering team to really write out and explain like why we're doing something and be thorough about it. so that the team can digest that information in the way that their disk personality, feels it's best to digest it. So I actually think beyond this conversation, the other reason the disk categorization is important. It makes it easier to make fun of people for their dis stereotypes. And that, I know that sounds ridiculous, but it's really helpful if someone's like being really overly owly or overly eagle. You can be like, relax, you're over owling this. and that's like a good way to, like reset the conversation. Everyone has a little chuckle and then we start over. Like, it, it's really helpful for, We're communicating that way. so anyway, that's kind of my plug for the disk styles, but I think it just helps when Mike has to communicate with the engineering team on why we're doing things.

Andy Schneider: That's wonderful. Mike, does it, help from a CISO's perspective if you have like, I'm talking to an owl or an eagle?

Mike Scott: absolutely. it's really any place where you're communicating with lots of different people.I laugh cause like we have these little coasters that, that have the birds on them and they have the different things on the back and I think it, for me, it does, I'm an Eagle and I can immediately recognize all my Eagle ness. Like I like bullets. I don't need a long sentence, just break it down and get it to me fast, let's make a decision and move on.if you're trying to work in a room full of OWLs with that mentality, you just keep getting stopped because there's, you know, why are we doing it that way? And what about this? And how about if we do it this way? and so I think it's, it's great that the company is focused on communication and communication styles. I can't remember off the top of my head each one, but I do find if I'm having a difficult conversation with someone where I just can't seem to, to work with them, I'll go back and look. Okay. what's their bird? What are we doing here? so I think overall, just that focus on communication, being clear and understanding what each other needs to do. This just gives us a tool to do it. And like Steve said, I definitely, it reminds me that to be more verbose. Not only what are we doing, but why are we doing it? Why does it matter?and it goes a long way with the engineers, you know, when they really understand that. And then I think also the side effect is when they understand why we do something, they start trying to figure out better ways to do So there's, there's a, it was a double sided coin there, but, yeah, I think just that communication style and knowing, how to work with each other is super important.

Andy Schneider: I think every company should do a similar thing like categorizing people because it really can help you if there are even other things like there are the talkers and the listeners. So, other ways of doing that, but this can

Steve Touw: There's other things like vision. There's like a visionary scale too that we do, but that's lesser than the disk stuff. But yeah,

Andy Schneider: a completely different question. So, if you now reflect back on your complete career, both of you, what was like the biggest learning that you had? Let's start with you, Mike.

Mike Scott: for me, it was, you know, walking a mile in somebody's shoes and understanding what their job is like is so critical in the security realm, because, you know, we're adding work to their plate, no matter what we're doing, somehow we're adding work or changing work and, So really relationship building and really understanding what their lives are like is probably the biggest thing I learned. It's really enabled me to also gut check myself to make sure am I being fair? Am I asking for too much? so I think that really, I'd say probably the thing that's attributed to most of my success.

Steve Touw: I always struggle to define what the heck the CTO is really supposed to do. I think, you know, if you ask 10 CTOs what they do at their company, you probably get 10 pretty different answers. But, uh, in my career, I've been more focused on the, um, product management side of things, so my answer is going to be more on the product management side, which is I would say that it's okay to just do one thing really well. I think a lot of startups. die because the, I think there's some quote out there that like startups don't dive starvation, they dive indigestion. I forget who said that, but that's not my quote, but, you know, just trying to do too much for everybody, you're going to choke yourself out and having really good focus and a vision of like one problem that you're trying to solve and just running full speed at that is really, that helps you be more successful. That took me a long time to learn. we were trying to be a lot to everybody in the beginning, the early days. and then when we got focused, we really started to take off. So I think that's my biggest learning.

Andy Schneider: did you plan to become a CTO? 

Steve Touw: No, not at all. No, just, I mean, I don't know how to give you the whole history, but the short version is that, through various startups, it was just kind of what I fell into, and working with folks, and kind of deciding who was going to do what. but it wasn't like something that. I would argue hardly anyone is formally trained to do it. Again, because I think it ranges, the spectrum of what you actually do ranges so much as well.

Andy Schneider: Yeah. Mike, for you, did you plan to become a CISO or when did that happen?

Mike Scott: I think I've planned to get into security. has been, Probably 18 or so years ago, but I was in IT and kind of doing anything the startup I worked for wanted me to, including filling the Coke machine once a week. and I was, you know, coming out of the military, it was so exciting to be somewhere where, you know, I was getting to do some things with autonomy and things that the business saw as viable. And so when security started becoming something that. Customers are asking for, I just threw my hand up like, Oh, I want to do that. Cause that sounds fun. then as I got into security from, you know, an engineering standpoint, more than anything, I really liked the problem solving. And I think it just evolved into, rising up the career ladder and realizing that I didn't like solving the technical problems as much. And that I was more interested in the big problems, you know, and, and I think there's, I don't know, probably a little sadistic there, but the solving a problem that takes a day is one sense of satisfaction, solving one that takes months or a couple of years is, is very different. And once I really started recognizing how to measure that, which was tough in the beginning. You know, as an executive, how to say you're successful because you didn't close 10 tickets, you didn't do it. But once I recognize how to see my success and also how to enable others for success, that's what drew me in. And that's what drew me into the, the leadership side was beyond the problems was also the people aspect. and just recognizing where we sit in, you know, in people's work stream and that, people's skill side was really important. Because I like people, it just kind of started all making sense.

Andy Schneider: So we are almost at the end of this episode, but there are like two last questions. Mike, I'll start with you. What's the one tool you can't live without?

Mike Scott: one would be Slack, because I get a lot of my job done, uh, through there, but I'd say the tool that, that actually makes our job the easiest,is definitely our cloud security posture management tool. because for me, it was really getting that contextual awareness of where something is and how it's deployed and how it communicates in a cloud world is very difficult. And so while I'm not a Kubernetes expert, having something that kind of helps me understand how the data flows and how things move. has been super helpful, but the, you know, the skill thing is the communication piece. And so I joke about Slack, but I think communication at the end of the day is probably the best skill you can have.

Andy Schneider: Wonderful. Steve, for you.

Steve Touw: I mean, I hate to admit it, but it's probably Slack too. It does drive, like I have nightmares about the Slack noise at night, but the, I would also say that. Google Docs is, I just don't know how we live without it, if I'm being honest. Like collaborating with people on a doc or a spreadsheet. Like when someone sends me a Word document with tracking changes on it, I just want to lay down on a knife. It's just like, it doesn't make any sense to me. Why anyone would want to do that? so just Google Docs, I think is just incredible, an incredible product.

Andy Schneider: Cool. So if people want to reach out to you or connect with you, where's the best place to do that? Is it LinkedIn?

Steve Touw: that I would say, or just straight email. I'm happy to have people email me steve at Immuta com, or Twitter. I'm on Twitter. You can find me on Twitter too.

Mike Scott: yeah, I would definitely say LinkedIn. It's, Mike Scott, CISSP, all one word,

Andy Schneider: mike, Steve, it was really wonderful having you on the show. I hope you enjoyed it too, and the listeners as well. So if you have any questions, you can follow up with Mike and Steve directly.thanks so much for tuning in. If you have a second, please rate and review the podcast.

We'll see you next time on Code to Cloud.