Techstrong TV – October 26, 2023

Hello everyone, and welcome to Text Strong tv. I'm your host William Willis, and I hope y'all are having a wonderful day so far. In today's show, we're gonna bring you some fantastic interviews with incredible guests from around the world.

So without further ado, let's get the show started. Enjoy. This is Techstrong tv.

Hey, everyone. We're back here. Live in Las Vegas for the Digis Search Trust Summit.

We're at Resort World. Resort World, or Resorts World. You got it.

Resort World. Resort World here in, uh, on the strip. And, uh, man, it's good to be back in person at the DigiCert event.

We were here, you know, pre, pre covid, pre plague, then we, you know, it was digital a few years. Yep. And, uh, virtual, whatever you want to call it.

And, and we're back here in person again. And some things don't change, though. I'm not, like, I'm happy to have my friend Mike Nelson, who's VP or global VP of Digital Trust for DigiCert here with us talking this morning.

Mike is gonna be chairing a panel today and doing some other things. He has his hands in anything that's around digital trust and certificates. Mike Mike's involved in.

Mike, it's great to have you back here in person. Thank you. Hey, we love having you here.

It's, uh, We love having, we like being here. And I, It's always fun to catch up with you. You, Man.

So, Mike, excuse me. I mentioned that you're chairing a, a panel today. Yeah.

Not everyone watching this is at the event, obviously. Tell us about the panel and, and let's talk about it. Yeah, I'm, I'm excited for the discussion today.

I, I think it will be, it'll be a lively discussion. We've got, uh, Stacey Higginbotham, who, um, is an I has been an IOT podcaster. She's coming in to moderate the panel, and then the topic of the panel is matter.

So you and I have talked about Matter in the past. Right. Um, it's the, it's the new standard for interoperability and security for smart home devices.

Yep. We're a year in, so the first spec of Matter was released a year ago. I think I interviewed you.

You did. Right, right. At that time.

And so we're a year in, you know, millions of devices have been provisioned, um, in that ecosystem, and we're kind of getting an update. How are things working? We've got, I think, um, we've got Chris La Prey from the CSA who's gonna be joining, and then a handful of influential manufacturers who are producing the devices just to talk about how things are going.

So I, I guess, you know, look, just between us, how are things going? Yeah, I mean, I think, um, we're year in. Lots of devices are going.

And, you know, from our experience with our customers, it's been good. I think, um, I think there's good adoption. I think CSA has continued to see more of the members, the, the number of members in the ecosystem grow.

Um, I think we've seen more maturity globally. Also, we have customers now coming online in Japan and China, um, through India. And so it's neat to see the global growth as well.

And so, you know, I think that there, there are things that the CSA is still working on that need to be addressed, but I think for the most part it's being adopted. Um, and, and that's good. It's growing.

You know. If you don't mind, I'm gonna take us down a couple notches here because I realize not everyone watching this is gonna be up on all of these things. Yeah.

When we say CSA, what's CS A for? Yeah, thank you. Yeah.

So that's the Connectivity Standards Alliance. They're an industry standards body that helps develop standards. They're most, uh, people are familiar with like ZigBee.

Sure. Um, they were formerly known as the ZigBee Alliance rebranded a few years ago. And Matter was launched under the umbrella of the Connectivity Standards Alliance.

So they're organizing all of the working groups and things that are going on. So if you're a smart home manufacturer, you wanna get involved in matter. The Connectivity Standard Alliance is the place where you go.

Got it. And, and how do you spell matter? M-A-T-T-E-R?

'cause it matters. 'cause it matters. That's right.

And, and really what this is, again, for people who've never heard the term before, an unfamiliar, this is for all of your smart home products, whether it's your refrigerator, your air fryer, your lights, your doors, your cameras, whatever. If it's connected, and you would primarily use it, you know, at, at home, it provides a level of security so that these devices don't get hacked. That's right.

They get zombie. They used for mal. Yep.

For, for evil purposes. Um, and it sounds like no brainer. Duh.

We want, we want in on this every, you know, we should be building secure Yeah. Smart homes. Yeah.

'cause the road to tradition is, is lined with good intentions. Yeah. Paved with good intentions.

It, it's what, about a year now? Mm-Hmm. Got millions of devices.

Not, and I should mention not every manufacturer is on board yet. Yeah. And if I'm not mistaken, didn't some manufacturers now decide maybe to go a different route?

Or that this wasn't for them? Yeah. So, so a handful of things are going on.

I mean, I think they're always organizations who sit in the back can't please everyone. Like, they're like, Hey, we're gonna let them figure it out. Get through the messy part.

'cause when you, whenever you develop a standard like this in a collaborative way, it's messy. Yeah. And it takes time.

They Max VHS, Right? Yeah, exactly. They've, they've been working on the standard for, you know, three and a half, four years.

And so it's been a long time in coming. And there's still things that they're working on. I mean, they've been working on, um, the latest release for some improvements on the security components to do things like certificate revocation and make that a requirement instead of an optional thing.

That will be a great improvement Sure. To be able to manage security, you need to be able to do that. Um, there are other things that I think that they need to work on.

I mean, they still have, you know, like, um, DigiCert, we were the first certificate authority that was approved to distribute device attestation certificates. And it has, it comes from a trusted route. And in order to be a provider of that, we have to meet a handful of security requirements to demonstrate that we can be trusted.

Sure. Trust is important. Um, they've done some things around, you know, to help drive adoption where they allow some of the manufacturers to do self attestation of some of those requirements.

To me, that's, that's a little concerning, right? Yeah. Self attestation for security sets you up for, um, uh, for, for challenges in the security space.

You know, I, uh, I hear that, and I, and I, I, I'm, I get a deja vu, PCI Okay. Level four merchants, lower level merchants. So this isn't your big box retailers.

They were allowed to sell for test testify, you know, to their PCI compliance. And so you go ask a merchant, say, Hey, would you mind signing that your PCI compliant here? Or do you want me to bring an auditor in for 10 grand to take a Look?

Yeah, exactly. What are you gonna, what are you gonna do? I'll sign the line.

Where Do I sign? Yeah, exactly. And, and the PCI council was like, look, there's never been APCI compliant vendor who was breached.

If they were breached, they were defacto not PCI compliant. It's all these self attestations. Yeah.

But they never changed it because they knew that the level four merchant just couldn't swallow that. Yeah. Yeah.

So are We, are we opening Ourselves up at the same thing? So, so matter is built on the principle of trust. Mm-Hmm.

Right. Um, so the first thing it tries to do is establish interoperability between the devices so that when you're going, you can have, you can control your devices, uh, through, through a more seamless, uh, experience. Uh, but then the second layer is security.

And, and, you know, they have roots of trust, um, that are common amongst the group. And the way that you create interoperability between the devices by having common roots that are in the root store. And then when a device connects, it checks to make sure it has the right trust, trust chain.

And if it does, it authenticates. But the problem about operating a root is it's, it's an important business. I mean, DigiCert, that is our business.

Right? Right. We, we help not just with the creation, but the management of all that stuff.

But you need to do it the right way. And so, you know, we're working with the CSA and others are working to push for this. We're not the only ones who have that opinion.

But self attestation is a dangerous thing because someone could be running a route ca a on a laptop that gets stolen. And what do you do if that compromise occurs? Right.

You need to make sure you have the right checks and balances to ensure that compliance is, um, that you have checked the boxes of compliance, not just self attest to it. Yep. So, Um, I don't know.

It's a slippery slope, Man. Yeah. Yeah.

I think we'll get there. And, and I think we'll get there. And it may not, they're looking at some other things.

You know, I think that, um, there's a lot of good things in the matter spec that are raising the bar for security. And, um, you know, and that's one of the things that are being discussed. And I love the fact that they're mature enough to actually just say, Hey, let's, let's wrestle these out in the working groups.

Let's try to figure 'em out. Yeah. And hopefully we can get to a place where, uh, you know, we can get revocation included.

We can get some of that self attestation stuff, uh, improved, You know, to me. So I'm not, you know, sometimes you can't see the forest for the trees. You are clearly in the forest.

I'm not. Yeah. Excuse me.

And, but I know about matter, thanks to you matter for a, you know, since it first came outta your postcode, I'm surprised that I don't see more of it at the consumer awareness level. Yeah. So like for instance, when I go into Best Buy or wherever I'm buying Smart home Yep.

On Amazon or wherever, I don't mean to be Yep. Not, you know, saying where you should go shopping, but why aren't, why don't I see that matter? Trust Yeah.

Front and center. Yeah. So you will, and it's there.

So I, I took a stroll through Best Buy, when was it, a couple months ago. And there were a couple devices that, that had the matter mark. So any device that's compliant with Matter gets a little logo matter has a seal that once you demonstrate compliance or have attested to some of the compliant components, you get the matter mark.

And that is becoming more prominent. Uh, one of the manufacturers who will be on stage with me today have four products that are being sold in Best Buy today. And, um, and they have the mark.

And so it's coming. Um, you know, I got an update to my Apple device recently that said, uh, the update is enabling matter and your device is not compliant with the matter Saturn. And so it's coming.

You need to be aware of it. 'cause I, I'm trained to look for it. Right.

Um, but It's, so to me, that's what rubber rubber meets the road, though. Where rubber meets the road is when a consumer says, you know, I've got these two similar devices. One is matter, certified one's not, why should I care?

Yeah, exactly. And if I don't know enough to care one over the other, then it hasn't hit me yet. Yeah.

And I, I think that there's still work to do there. Uh, consumer enablement certainly is a key component. 'cause consumers are the one that are buying, turning these on, and they're the ones that had the frustration to say, look, I have 30 smart home devices and I have to use 30 different AppSec to control 'em.

Right. I mean, that's the pain point matters. Trying to, yeah.

No, I, I've been there address. I mean, to me, that was the whole thing with ZigBee too, though, right? Yeah.

Because I, I had three different buses or whatever they call it, hubs in my house, you know, one, one for appliances, one for lights, one for the ring. Yep. One for the net.

'cause I'm an, I'd have Ring and Nest it, it was plus the wifi. Yep. It was crazy.

Yeah. I do the same thing. Yeah.

Oh, it's just, it not just Me. It's not just you. You know?

So I was hoping to have a, a, a consolidation of that to one app for all my smart devices. Yeah. Um, you know, it's still a, it, it's still a Yeah.

That's, that's where matters. Trying to push it to, to create better interoperability Yep. So that you don't have to do that.

So we'll, we'll continue to follow the development and maturation of matter. And, and, yeah. I mean, sometimes you gotta break a few eggs to make an omelet.

Right? Totally. And, and so I, I think there'll be some growing pains.

This self attestation thing, I think it'll play itself out and we'll go from there. But, you know, it's not dissimilar to what we're seeing also in the whole software development life cycle. Oh, this is a good topic.

Right. Did you like that segue? Yeah.

I love that. Um, you know, we, last year at RSA, we, it was all about SBOs and software supply chain security. And of course, you know, the, the White House and the Fed federal government's involved in this pushing it.

And it, it's the same kind of thing. We want the consumers of software to be able to have a, a, you know, the mattress label Yeah. That you're not allowed to rip off Yep.

To show what are the dependencies in this software, this soft, you know, IIII can trust this Software. Yeah, exactly. And, you know, I think that's an even funnier issue than this matter thing.

Yeah. I mean, it's certainly an area that's getting a lot of attention. Um, I think you're right.

The White House, um, has brought, uh, a large focus on the security of software in connected devices. Um, the FDA recently, um, October 1st, uh, the Food and Drug Administration in the US got regulatory authority to actually deny the submission of medical devices that come in that do not demonstrate, um, strong security. And they have, uh, guidance language out there.

And one of the things that they specifically ask is signing of software and the creation of an SBO m software bill of materials. Yep. So that they can say, all right, what ingredients are on this device and what vulnerabilities are associated with that.

You know, in order to do security on devices, you have to have software. And if you have software on there, that software has to be secure. Yep.

Well see. But it, you know, it, it's not just the mattress label where it's 64% polyester and 40% this and whatever. Right.

The thing I think that gets hairy with software and SBOs is the dependencies. Because today that piece of software running on your watch or, or this microphone is not just software I wrote, but it, it, it's probably there's APIs there Yeah. That are calling out to third parties Yep.

Which themselves are calling out to third parties and so on and so on. And so when we talk about SOM and dependencies, it, it's, it, sometimes it's not even the code that's running on the device or on your machine. It's, what else is that Yeah.

Software calling to and depending on and interacting with. Yep. And so, you know, you don't want to be your brother's keeper, but you have to be three generations removed from where that API call is being made.

Totally. You have to have the chain, you have to, you have to be able to follow that and make sure that you have trust. And that's dynamic too.

Yeah, it is. And it's a, it's a challenging problem. And I think the other thing you point out, I mean, you know, a lot of devices are running, you know, when you're, when you're building software, you use open source software Sure.

Through party software. You, you develop software on your own. All of those can have vulnerabilities.

Some, some known, some unknown, but having scanning capabilities to be able to, you know, scan and say, all right, third party software, what are the known vulnerabilities from, you know, the, the lists that are out there. And then also to be able to do testing on it to identify new vulnerabilities is so important. And that's a trend.

I think we're seeing a lot more maturity, um, at least the discussions that we're having at DigiCert, we see a lot of organizations kind of migrating from old software signing practices and scanning and that type of stuff to trying to get more managed, um, approaches to it. Yep. Um, because, you know, signing is usually not the problem with code signing.

It's easy to take a code signing signature. They've made code signing easy. It's the processes around signing where people get in trouble.

SolarWinds is a good example of that. They used a valid code signing certificate to sign the software that was distributed to tens of thousands of their customers, and they had a big problem on their hand. Yeah.

But it was because they didn't, they didn't have the right scanning capabilities to detect the malware. They then signed it with the malware on it and distributed it. And so, you know, I I always say, good, good signing or software practice involves very thorough scanning, and then you need to mitigate those.

So if you identify vulnerabilities, you need to be able to mitigate those. And then having, signing along the process. So if you have different engineers developing that, you integrate signing services into your DevOps so that you can sign along the way to ensure the integrity of the build.

And then of course, deployment, you have to be able to deploy the software in a way that's secure. Um, and that often includes, we're seeing more and more, uh, a software bill of materials. Right.

Yeah. Well, no, I think, I think SBOs are gonna be standard. Yeah.

But here, here's to me, SBOs have to be living, breathing dynamic. Yeah. They are, Uh, instruments.

Because as you said before, every software has vulnerabilities. Some we know and some we don't know today. Yeah, totally.

But we may know tomorrow. Yep. And so I could scan to the cows, come home today, and then release the software tomorrow, and then next week we discover a vulnerability.

Yeah. Or some third party dependency, discovers a vulnerability. And how do I, how am I supposed to know?

It almost has to be that, that SBOs living and when it's, it sees something on, so this goes back to my neck days when I spoke the company that was very involved in neck, where, Hey, I've got my, I've got my stuff here. I've got my SBO m I've got all my, my bill of materials. I've got all my dependencies, I've got all my APIs.

And now instead of scanning that software again, because I just scanned it, but when anything on this SBO m triggers a, a new vulnerability found or something Yep. It like lights up green to red or whatever. Yeah.

Right? Yep. And, and now I know I gotta, I've gotta update this software.

I've gotta do something. Scanning alone's not going to get you there. Right.

Right. And I think that to me, for SBOs to be really kind of fulfill the promise. Yeah.

That's the kind of capability I'm looking For. Yeah. I love that.

And those, uh, I, I agree and good tools out there. I mean, DigiCert, um, you know, know we play in that space and we have some great partnerships with Reversing Labs. Mm-Hmm.

Who's one of the leading scanning and SBU m tools for Market. They're, they work with them in Techron. Yeah.

They're awesome. And, um, you know, the great thing, uh, you know, this is a little producty, but, um, you know, the great thing about our solution is I believe we're one of the first vendors to bring both the scanning, the signing, and then the creation of SBO m into one platform where you can do it all together and, and in the way that you're saying, right? So it's a dynamic and you're getting updates as things are Going.

That's, that's the key To it. And that's, yeah, it's critical. And, you know, and then with your, with your signing and just, uh, I, I, I always think it's important to emphasize this point because, you know, traditionally, uh, I always say, you know, USBs with signing tokens, you know, that's the way people used to do it.

And believe it or not, that's the way still a lot of people do it. But organizations are moving away from that to do things like rights management, access control. So, you know, who do you want signing?

When can they sign? What types of files can they sign? You have to have that type of control key rotation, you know, I mean, the days where you'd hand those out of times, the same key was used to sign, like everything in their stack.

Today, many organizations are doing more key rotation, even unique keys for each signing. You have to have a right strategy 'cause that helps protect you. Um, and those things are, are really important in finding, if you're looking for a solution, finding a solution that allows you to have that level of control, visibility.

Um, but also to make sure that you're protecting your stuff. There're things like key rotation, timestamping, all that stuff. Excellent, man.

I want to come back to Matter 'cause we're gonna end up here. Love it. So people out here, they heard it.

Now, if you haven't heard of it before, check it out. Next time you're in Best Buy or whatever, look for the matter, uh, you know, certificate, how can they stay on top? Is there like a matter website at CSA or something Like that?

Yeah, you can go to the Connectivity Standards Alliance website. Um, they do, yeah. There's a lot of information on their, on their site.

They also have social media pages that you can follow, um, when new updates and things are happening. Um, they release that. They also release when new members are joining.

So if you have, if you have products in your home and you're, that product's not on the list, you can get updates, uh, on that. But I, you know, I'm, uh, maybe we, I end on this, but, you know, I'm, I'm encouraged with the momentum that the CSA still has with Matter. The fact that they have members joining the fact that more devices are going to market.

I mean, it's, it's a good sign for the future of it. And so I'm, I'm really encouraged. And, and also the fact that they're dealing with some of the hard questions around some of the security stuff.

So it's good. Absolutely matter. It matters to you.

Alright. Hey, Mike Nelson, it's great to see you man in person. Again, Alan, always a pleasure, man.

Yeah. And it's a great, great show here. For those of you who, who can't make it, look into it for next year.

It's a, it's a really good stop if you're doing your, your conferences. Um, we're gonna take a break. We are live in Vegas at DigiCert Trust, and we'll be back in a moment.

Thanks, LAN. Thank you. I am Bonnie Schneider, sustainability contributor to the Techron Group.

I'm excited to introduce you to a groundbreaking new initiative from Techron Research, the sustainability pulse meter. The pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry. Position your company as a leader in the industry and differentiate from your competitors with the sustainability Pulse meter offered exclusively from Techstrong Research.

Hi everybody. Thanks for joining us for another episode of Techstrong Women, where we feature amazing women doing amazing things in tech. I'm Jodi Ashley, executive producer here at techron, and I'm here with my co-host, Tracy Ragan, creator, and CEO of Deploy Hub.

Before I introduce today's guest, I wanna give you a quick update about what's happening here at techron. ai, so be sure and go check it out. We all know AI is a hot topic these days, and we're excited to have this new platform and all this new content for you guys to check out.

We have a couple virtual events coming up you can check out. ai on December 12th. com and be sure to tune in every day to Techstrong TV for great shows and interviews.

Hey, Tracy, what's on your mind today? Ai, of course. Well actually, um, more than just ai but investments, uh, you know, I I I try to keep a kind of my, my thumb on the, the, the, the pulse of startups and investments.

And this article came that, it came across that talked about, um, kind of money drying up for startups, uh, even AI startups. So over the course of the last year of, there's been quite a, I mean, the investment money pool has sort of shrunk, uh, and that makes it even harder for startups, especially for women in, in this industry to raise money. But I did see something in that article that I thought was interesting.

And this article comes from cyber news, uh, and it's called Where Venture Money. Where has venture money gone, including for struggling AI startups in the article, even though the top kind of, I guess you would call them investments or unicorns, none of them are around, uh, cybersecurity. And in the article they talk about that the, the fact that cybersecurity is probably the most appropriate place to place ai, uh, because cybersecurity's hard to track.

So if you're out there doing cybersecurity and you're, you've got an AI of, of kind of angle to it, or even you've started some AI workflows, this may be an area you could get startup funding in. Maybe not so much other areas, but certainly application security I would think, uh, would be areas that these investors are looking to invest. Cybersecurity is al always a worthy investment in my mind.

And I think it's interesting that this particular ar article points out that cybersecurity is an area that, uh, investors are looking into, but they're not making big investments in other areas. Uh, so just a, just a thought, and I find it an interesting topic because in application security, as I say all the time, we don't have a big data lake for doing ai. We don't have a large language model.

We don't have a lot of data because we don't share it. Uh, so more to come on this topic because in cybersecurity and application development in general, we see things like chat, GPT, we could actually generate code. But on the other side of the coin, um, we're not doing a whole lot to protect the code that we are generating.

So that's my thoughts for today. Good ones. That's awesome.

Thanks, trace. All right, well, I would love to introduce today's guest, Smitha Murthy. I hope I said all that right?

Yes, you did. Smith, uh, tell us what you're up to and tell us a little bit about yourself. First of all, thank you both for having me on the show.

Uh, I really appreciate it. My name is Smitha Murthy. I'm the CEO of Beagle Security.

Um, I've been a career product person, so, um, done, uh, product management in a variety of companies, uh, large companies, small companies have grown both, um, products. My passion getting, solving customer problems is my passion. Um, and I think it led me naturally to this role.

Um, I've spent about 10 years in cybersecurity in previous roles, and, uh, when this opportunity came up for me to take the helm of Beagle security, um, it felt like the right thing for me to do. Um, so Beagle Security we're, um, vulnerability assessment and penetration testing SaaS platform using AI at the core. So Tracy, your article couldn't have been more aptt that you picked up because I have been at the New York Venture Summit the last couple of days, um, and have been talking to a lot of people.

We're doing our first capital raise. Um, so lots of interest in cybersecurity, lots of interest in ai. I'm happy to talk about that and what I learned, um, at the summit.

Um, so yes, um, I, I, I think, you know, just, just on the article about ai, I think hackers are using ai. So if the cybersecurity products that are supposed to protect us are not leveraging ai, then there's, there's a huge gap. Um, and thankfully our product, our platform, when we built it, it was built with an AI core.

And, um, that's how we believe we're differentiated and our customers are seeing that. Let's dive into that a little bit. This the concept of building a product on an AI core.

Um, describe that to our audience because I don't know if many of you know, we have, we have a pretty broad audience and not everybody is really understanding of what AI is and what the core, what an AI core is. Sure. So, um, so the way, um, I explain how we are leveraging AI at the core, um, in our product now platform is imagine you are a hacker and you're looking at a website or a web application.

You are essentially looking at what are all the different entry points through which I can get in and potentially with malicious intent, right? You and I are not doing that, uh, with malicious intent, but the hackers are. Um, so what we have done is we have leveraged ai, um, to essentially mimic what a hacker would do.

So we're leveraging image processing, natural language processing, using those models. Um, we have a supervised learning, uh, system in place that's learning from looking at all of these, uh, different websites, different, um, web applications and, and continuously improving. Um, and therefore being able to a figure out what's the tech stack on which a particular web app is built and what's the best way in which we can log in, um, uh, to, uh, with the different entry points that that web app may offer.

Um, and we also have protection for public facing APIs because as we know, that's the way in which information is getting exchanged, um, in today's world. So that's how we're, I think the, I think the API issue is, is broader than most people understand, especially, um, with access, getting access to data. I mean, I just saw, I just saw a, uh, I think it was, um, what is that company that has the golf where you can go play golf from a, like, you, you can drive, I can't think of the name of it.

This is Topgolf Top Golf. Thank you. Top Golf Topgolf.

I just saw like something that Topgolf, uh, had a security breach and it, uh, exposed a million names for Topgolf. So, you know, I don't know how that, that security breach occurred, but if it got to access to the names and emails of folks, more than likely it was through API. Well, and they also have, like, I hate Topgolf just saying there's one down the road drives us crazy, but they also have these, you know, monthly accounts you can sign up for a membership.

So who knows how much payment data got stolen in that breach as well. It Said that they didn't have payment data, but it was mainly, um, that's why it, so it, it, when you have AAPI ba when we're talking APIs, you can have an API that just goes out and gets a name and an email. You may have AAPI that goes out and gets, uh, financial information.

So the, when you build something that's more service oriented, it may be that they just got the emails and the names, but a million people is, that's a lot. For something like Topgolf, I, it surprises me. Um, but in terms of application security, I know there's a lot of discussion around protecting, um, and secure, uh, building more secure APIs.

Yeah. Yeah, abs absolutely. Uh, did you want me to talk about that a little bit?

Uh, Tracy, I think our, I think our audience would be very interested in that, if that's a, if that's a core place where people are getting in, you know, how do, how do application security tools work in this API, uh, security field? What are they, what are they actually doing? Um, so, so I think it just depends on where in the lifecycle a hacker's able to get in, right?

So, so if we think about AppSec overall, I think it's important to understand application security refers to like the umbrella term. It's been around for a long time. Um, anyone who's done software development, um, understands that you want to follow secure coding practices.

And if you're writing APIs, it has to be secure at that level before it gets to the point when it's a public facing API and someone's actually able to use it. Um, so, so I think AppSec as a, as a whole has multiple different pieces to it. Um, there's static analysis, which is at the code level.

That's not something that we do. There's plenty of very good players in the market that do static analysis. Then you have software composition analysis, which is talking about what are all the different pieces that went into building your software?

Are you using open source software and how secure is that? Um, and then, then you get to what we do mostly, which is from a third party perspective. So we're outside the firewall hitting it from the outside.

So it's black box, we don't have access to the code. Um, and, and essentially we're looking at what is exposed and how can we, how can we emulate what a hacker might do and therefore get access either through a web app, which is through a login mechanism or whatever you have, or through an API by using the API call to penetrate. So if the API is not built securely, then you have a potential vulnerability there that can be exploited.

And it's important to understand in this our new modern, what we like to call cloud native architecture. If you're building microservices and you've really decoupled your application, you literally ha you have literally thousands, you could potentially have thousands of, of APIs. Now we're getting to a point, we're talking about an application security, having a deco decoupled databases as well.

So if one, a API is exposed, it only can access the data of that particular API, which I think is an interesting concept. It's kind of like a, I saw, I saw a kind of a meme for this, and it showed, um, I think it was Warren Buffet and Bill Gates playing pinging pong. And one of 'em had this massive, massive pinging pong paddle, and one had a tiny one, which really described the, the pin where you can penetrate.

So if you penetrate at the ginormous, uh, pinging pong paddle, you can get into everything. Yes. If you have a tiny one, the penetration, uh, you know, the space of the, the, the surface of penetration is, is, is much smaller.

Uh, so, you know, in order for us to start building more secure applications, many things must happen. However, one thing that's important is understanding the use of microservices and why, and potentially decoupled databases and understanding how that actually improves security, even though it makes it very, a much more complex system to build. It makes it a, a harder one to, um, to break into A Absolutely.

But one comment on that is that's, that sounds like a great idea, but to your point, it's more complex to implement. And we know there's plenty of legacy software, uh, plenty of web AppSec that won't have that architecture, that won't have that ability to break the database into smaller pieces and APIs only being able to access what they need to access. Um, so I think the problem of API security still remains a fairly sizable one.

Um, and I think, I actually think that that could be a fantastic architecture if it could be implemented where you kind of break it down into little bite-sized pieces. So your exposure is limited versus this is like the whole thing. We're getting there, I think.

But to your point, the legacy applications are gonna be around for a long time. Think about the US government. Yeah.

They have massive legacy applications that's gonna take quite some time before they can get off of those systems and build new or modern systems. Um, and they need, uh, they need help. They really do.

They, you know, they're looking for it. In fact, I'm right now, um, busy responding to an, a request for information from the cybersecurity director, uh, just giving them information about what areas could be improved upon. And there are so many different areas that can be improved upon, and the US government, I think is pretty serious about it.

Um, and in your experience, I'm sure that government is a target for you, for, uh, for your, your new startup. But who else is out there really serious about securing? I mean, I beagle security must be looking for particular personas.

Who do you think is right now super interested in this problem? So, uh, thank you for that question. Actually.

This is, um, this is the heart of why we started Beagle Security. Um, you know, if you kind of go back about three years, when we started, um, AppSec was a known space. Uh, static analysis was well known.

Dynamic analysis was starting to pick up, um, because you wanted security at every stage of your product development lifecycle. Um, however, the AppSec tools catered to the large enterprises. The large enterprises were like, oh, we gotta do this, and it has to be, uh, a core part of secure coding and secure application deployment and all of that.

So they actually got hold of partners, um, and the partners, uh, looked for the best in class security solutions. So we're talking hundreds of and thousands of dollars, right, for each of these contracts. So what that essentially did is the small and mid-sized businesses who also have websites, who also have web applications, who also do data exchange with APIs, they were left with, oh my God, I can't afford that.

Right? So let me try and do, let me check a box once a year to meet my compliance or regulatory re requirements and run a pen test. And I say, why bother?

Right? If you're doing this once a year, you may as well not do it because the rest of the year you are exposed. So yeah.

So our mission was how do we, um, how do we educate and secure and make something like AppSec really affordable and accessible to all size businesses? That was our mission. Um, and when we, so, so when we built the product, we made it SaaS-based.

So it's subscription model. So if you're a smaller mid-size business, um, it can be, Hey, I'm gonna do monthly to manage my cost, right? You don't have to do a multi-year contract.

Uh, so we made it monthly, annual, what have you. There's a discount if you do it annually, but if you do it monthly, you manage your expenses a little better. Um, and our, the traction we have today in the market is with the small and mid-sized businesses because they love what, what they have got.

So it's not just a cost advantage. I, I try to, I try to tell the story of why we started, but I'm also trying to say it's not only because of cost, but people buy our product, they love our product. I can tell you the number of competitive displacement we've done over the past three years is astounding.

Um, a lot of, there's, there's very few SMB focused AppSec players. Most are large enterprise focused upmarket. Mm-Hmm.

And, and for the large upmarket competitors to come downstream, uh, to SMB is a challenge. A lot of them have been trying, not very successfully. Um, we, on the other hand, we started in SMB, uh, that's kind of our core focus.

Um, we do have a handful of large enterprise customers who have seen the value that we can bring to, to them. Uh, in fact, recently I was talking to a ciso, um, who has had the usual, uh, suspects in the large enterprise space. Um, he's gone through all of them and he's like, I don't know what the difference is between each of these vendors, right?

I don't know if I'm more protected or less protected. I just know I'm cutting a check off a very large sum every year. So I said, tell you what, I'm gonna give you my product for free.

Try it if you like it better, the con you can give, give me the contract. So, so it, it's, it's interesting, and I think the mindset has to change a little bit, um, in the enterprise space from SMBs have no option but to have self service because they have to run that business. But for enterprises, I think the product has to be 10 x superior, 10 x uh, more affordable to, for them to see that and say, oh, here's a better alternative.

And maybe that's when the shift will happen. Well, you point, you, you, you hit a point that I've always complaining about too, and the, it's the checkbox. Security has always been such a checkbox.

QA and testing in some way has been that way too. Um, and you know, there, there's this fuzzy area between getting a product ready to deploy out to production, uh, and having it sitting on of developer's machine, and it's running correctly and they wanna push it out quickly, then this, all the security and testing just becomes a checkbox. And it's, that's the case with software bill of material reports.

SBOs, okay, I generated an sbo, but it's sitting in a bill directory in a text file someplace. I did it, but I don't, I can't do anything with the data. So what's the point of me using it?

What, what's the point of me doing it? It's just a checkbox. And so much of security has become that over the course of time.

It's like, yeah, yeah, yeah, I did this, I did this, I did this. So somehow on the software factory floor, we have to build good habits of brushing our teeth from the beginning to the end. That's right.

That's right. That's absolutely right. Um, and it surprises me.

So as, as I mentioned, I've worked in very large companies, very large software companies, um, that, you know, I was actually, uh, fairly surprised when a recent, um, product release was getting ready to get out of the door and oops, we haven't done our penetration testing. I'm like, what? This can be real.

Um, so it, I, I think that education needs to happen throughout. Um, and, and to your point, the hygiene of making this a habit throughout the lifecycle is an important part. Um, It's just such a push and pull between get this out to the customer as fast as possible and making sure it's quality and secure.

It's always going to be a push and pull. And it's hard to, it's hard. It's a, it's definitely walking a tight, a tight rope.

And I think developers do the best they can, but sometimes people like us as users are like, but I want it now. I want it now. It's broken.

Please fix it. I gotta get this done. Yeah.

And I think that's where, sorry, just to do another little plug. Um, I think that's where the AI core helps from our product perspective, because we've seen, we're able to run, let's say about 3000 test cases very quickly. Like we did a comparison between h how, how much would, how long would it take to take the same code through a manual pen testing process, the number of test cases that could be run.

And the amount of time it took was, um, about two weeks or three weeks to do the manual testing. And the same thing was done in two or three days using our product. Yeah.

There's nothing that's left in the, I would say the DevOps pipeline that should not be automated. If we don't automate this stuff there, it's never gonna get done. It just does it, everything.

It has to be automated, you know, maybe co even coding's becoming more automated. Yes, automation is required because you cannot deliver fast with any manual steps. So the whole pipeline has to be, um, automated.

And that's another problem, um, which I'd love to chat about, but we're gonna run out of time, and I would really like to get a little bit of, uh, your history. How did you get back, how did you get into software? How did you end up where you're at?

I mean, you know, starting from, you know, a young college graduate to being ACEO of a startup, what, what does your journey look like? All right, let's, let's go back about, oh, I don't wanna say how many years. No, no one's asking you to give years.

So, uh, so my background is, so my undergraduate degree is in computer engineering, uh, computer science minor. So I started my early career as a software developer, did that for about six years. Um, and I realized like, what the thing that I enjoy most, uh, in that role was, this is way back when, when we used to have those beta calls, um, our software product would be getting ready to get out of the door.

So prior to that, we would have a beta period when customers would use your product, critique the product, um, give you feedback, find bugs, uh, things like that. And, and I really, really enjoyed, uh, being able to solve that customer problem and have them say, wow, that really works. And that really solved my problem.

So that kind of led me to, uh, going to B-School, uh, got my MBA, um, one of the, so the product that I was a software developer for, we happened to have a product management role opened for it. So I raised my hand, took it, not knowing what the heck I was doing. Um, and I've been a product manager since I've, um, worked in, like I said, very large companies.

Um, I've worked in places where product management was not an understood function, and I've had to establish the function and, and really build the processes around the discipline of product management. And, uh, so worked in a variety of domains. I actually pride myself in that because it, every domain teaches you something new and you bring that arsenal of learnings to your next role and hopefully add value in your next role.

Um, so I worked in, during, when we had Waterfall. Now Agile, I've been an agile champion in several of my previous roles. Um, whether I voluntarily became the Agile champion or not, there's a different, a different question, but I ended up there.

Um, so, but, but so large companies, small companies, different, um, development methodologies, um, different, um, different size companies. Um, but I've spent 10 years in cybersecurity, uh, in companies like McAfee, Juniper Networks, ca, ca technologies. Um, so it's, it's always been in, in my, um, in my headspace.

And, um, I was most recently, um, running a healthcare portfolio. Um, and my colleague, my ex-colleague from McAfee, he's the, he's an advisor to Beagle security, and he came and asked me, Hey, I think this would be perfect for you. And I was like, what?

It wasn't what I was thinking, but, um, I did my due diligence on Beagle, like I would as a product manager. Um, and I said, how big is this market? How big is it growing?

Who are the people who are, well, I like working with these people. Um, and all of those good things. People often tend to forget that it's so important, the people that you work with.

Um, really smart, really energetic, uh, set of folks, cybersecurity engineers, AI engineers, um, and who built a product, and it's something, one of my co-founders, he used to be a pen tester. So that's kind of how the whole idea was birthed. Um, and for me, um, this was, this is a little bit, um, non-traditional where the two co-founders founded the company, and I've joined them earlier this year.

So I'm sort of like a new person that's brought into the mix. Um, but I think, you know, they wanted me to, um, come in because they see we have, our customers are distributed all over the world, uh, with over 50% of our customer base here in North America. So we needed a North America presence.

Um, and that's why I'm here. You know, uh, we ask that question to most of the women we have on, if we, if we remember to get the sneak it in. And one thing that's usually, I'm dragging it out at the last minute.

Yes. And one thing that that's common is that every single woman we have spoken to, I, I don't think without, I, I, I think every single one has said that they started out as a programmer. And if we ask them if what if they, what they would, uh, suggest to a young college graduate, how they get started, they always say code, start with coding.

You need to be a programmer first, as you pointed out. You learn, you, you, when you start at the programming level, you learn many, many disciplines. Yes.

Which can then apply to, as you did product management. Yeah. Yeah.

Abs absolutely. And, and I think, um, having the technology background has served me well personally throughout my career. Um, because whether we like it or not, oftentimes we end up being the only, uh, females in a room, whatever your role might be.

Um, and, and then you need to be able to engage with the rest of the room at the level that they're engaging in. Yes. And in, in the case of, um, technology, it's technology, um, there, there are people in, in my past who would say, oh, I'm really intimidated to talk to this architect or whoever.

And for me, I, I kind of take that on as a challenge. I'm like, I will engage that person in a conversation and explain my perspective and listen to their perspective, and we're gonna have a happy marriage here. Um, it, so, so I, I really do believe having a strong technical background will serve any person well, and especially women in, in a, in a domain that is, uh, still traditionally more, uh, male dominated By far.

By far. Yeah. And what I try to tell women that I speak to that may reach out to me from a mentoring perspective is that it's okay not to know everything.

Um, yeah. We as women wanna have the answers. We wanna solve problems, we wanna, oftentimes we're very focused on, you know, helping.

And in order to help, you have to have knowledge. And I think it holds some women back. Um, I've never, I've always been, I, my curiosity has probably overridden my need to help somebody.

So I've always been the person who says, wait, wait, wait, back up. What does that acronym, I have no idea what you're talking about. You know?

Right. What does that mean? Because there's so much to learn and this, this tech field, you can't know it all only way you can.

Well, you're absolutely right. You're absolutely right, Tracy. I think so many times as women we're afraid to ask the questions because we're afraid someone will think we don't understand.

We don't have the knowledge, we don't belong in the room. And I think that's like across the world, right? And I was always, I was always taught, and I was very fortunate, um, my whole career to be like, if you don't, if you don't know something, ask, and if I can't, and that, that's the same approach I use with the staff I work with, was, if you don't know, ask me.

And if I don't have the answer, I'll find someone who does. And I think so many women especially are afraid to do that because of, you know, how it's perceived. But you got to, I think it's more important because then you, people understand you're trying to learn, and that you don't think you're the smartest person in the room, and you don't think that you know everything, and you're trying to gain, like some of the, your, the way you described how you approach it, it's like, tell me what you've got, you know, to contribute.

And here's what I have to say. It's a conversation. It's not a, you know, more, I know more situation.

It should be balanced. And I would say it's okay to say, I don't know. Right?

Let me get back to you. Let me find the answer out. Um, and I run into that all the time, uh, in, in this, uh, in these investor conversations.

Um, so we're doing our first capital raise. Um, I'm, I'm deliberately outside my comfort zone. I have absolutely, um, I have absolutely raised, um, well, I should say internal approvals and budgets for new product areas within the company.

So I'm used to writing business cases, um, pitching for it, making a case, getting approvals and deploying, building the product. I'm used to all of that. But this is, you are going externally.

Yeah. The intention is very clear. You're trying to raise money so that you can grow your business.

Um, and the investors you speak to, and there are different kinds of investors. Some are very knowledgeable about cybersecurity and some not so knowledgeable about cybersecurity. Um, and you have to meet them where they're at.

Um, and I happened to meet one investor who was so deep in AI that, um, you know, I was talking about the AI core in my product and the fact that we use large language models in our contextual reports and so on. And he's like, what do you use for large language models? And, and I said, well, it's, it's a proprietary model, but, you know, kind of like chat GPT.

I said, I didn't use chat GPT, but kind of like it. He's like, well, but that's open source, and then there's gotta be problems. You're a security company.

I said, it's our own model. So it's, it's very interesting the kind of conversations and curve balls, um, you get, uh, as part of this fundraising process. And, but that happens through your entire career, right?

Yes, Yes. Absolutely. And I think that, you know, I, and I see women don't necessarily, they, they don't always wanna walk on that razor's edge.

And it's important, it's an important skill to learn because it's the only way you can push yourself to the next level Yeah. To go beyond your comfort zone. And if it, women really need to be comfortable with going beyond their comfort zone.

Yeah. Whether it's learning a new language or pushing for a new job. Um, I, you know, I, I've, I've worked with, with both men and women on resumes, and I'm always kind of blown away by how much a man will put in his resume and how much a woman will hold back.

Yep. Yep. So we, we, there's, those are areas that I think that we have to understand that we don't have to feel that we are completely an expert in an area, uh, but we can sit down and learn.

Yes. That, and that's the beauty of this industry, right? You never, you never know everything.

So you can always learn. So if you're curious, that's a really good space for you to be, but to be, be okay with pushing yourself. Yeah.

And I'm glad that you're beyond your comfort zone. Yeah. Because that's what gets you to the next level.

Yeah. Yeah. And I, I love the, the, the comment you made Smith though was one part, in your point in your career, you just said, I just raised my hand.

I had no idea what I was getting into. Women don't do that as a rule, so I applaud that. You know, we we're like, we have to be prepared.

We have to know what we're doing. Oh, wait, I can't, and it just holds us back. I do it.

Yeah. Yeah. And I think it's amazing that you just went, Hey, I'll try it.

Let me dive in and see what, what's going on. So, and, And trust me, that was a time when product management as a function was not well understood. It was often mixed to be thought to be more marketing.

Product marketing has its own space, right? It's a complimentary, uh, field to product management. I have worked very closely with my product marketers, um, and it's, it's a beautiful relationship there.

But it, these are two distinct functions and Very, very distinct. Very distinct. Yeah.

One's, one's more technical, one's more developer outreach. And I think for, for women considering going into product management, um, it is a very interesting area. I always loved it.

Um, because you're working with end user end users. You're working with the roadmap. You're trying to keep the developer's ideas out of the way, because sometimes they'll be like, yeah, that would be really cool.

We should just add it to the product. And you're like, but the customers are asking for something else. It's a very interesting role to play.

Yeah. And I think for women, it's a very good place for them if they wanna leave the development world. Um, product management is a better space to get into, I believe, than project management.

Oh yeah. Yeah. I can't tell you how many times people have said, oh, Smitha does project management.

I said, well, well, yes, I do have to project manage what's going on. So my roadmap is actually honored. Yeah, Exactly.

But what I am doing is defining the product strategy and a roadmap on how we can achieve that strategy that will meet the market's needs and the customer's needs, and therefore we shall all make money. How's that? Right.

Well, and we're all project managers 'cause we're all exactly managing whatever goals we're trying to achieve, right? So, yeah. That's funny that, you know, just Tracy and I have had this conversation a ton with people that women get pushed into, well, why don't you be a project manager?

Well, no, I wanna write code, I wanna be technical, I wanna do it. Smith is doing, I don't wanna be a project manager, but we get put in those more administrative, solely administrative roles. And I have a funny story on this in a recent, uh, role a few roles ago, so nobody knows who, what I'm talking about.

Um, uh, I was, uh, I was the head of product, um, brought in new, uh, the announcements made. Um, and I was in the kitchen getting a cup of coffee or whatever. Um, and um, this person walked up to me, Hey, are you new?

I was like, yeah, I'm new. I, and he goes, immediately jumped to the assumption, are you marketing? Are you hr?

I said, no, I run product for this company. He's, wow, I'm so sorry. I'm like, don't be, don't be.

I'm really happy doing this. Yeah, that sums it up pretty well. Yeah, Tracy.

Yeah. Oh yeah. It doesn't ever, yeah.

You must be in HR or marketing or communications. Are you in the communications team? Right?

Yeah. I haven't gotten that. I haven't gotten that One.

I've worked for some really big companies, so, you know, well, I've, believe me, believe me, most of the time nobody can, nobody, they, people struggle stereotyping me into any particular role. You know, this blonde California girl working in tech. It just, I have no, I'm not expected.

So most people would probably not be able to, to pin, uh, kind of put me in a, in a, in a block of any kind. Um, they probably would think I was a visitor. I don't know what they would.

That's great. That's funny. Well, it just, it's really true.

Goes to show that we, uh, we gotta make sure that our role is clear and people know what we're up to and, and, uh, that we're good at it and that we're just part of the team. Right. And boy, we have had some women on this call that are really, really good at what they do.

And Smitha, you fit right into that. Absolutely. Into the club quite well.

Thank you. Thank you. This is a, this is a good place for me to wrap.

We're, uh, as usual, we can go on forever and ever and I would get yelled at, but we would do it anyway if we, if we could. Yeah, Tracy. Absolutely we would.

This Has been a wonderful conversation, Smitha. Um, thanks for reaching out to me and, um, having a conversation ahead of this. Um, it's been great spending time with you and learning about what you're doing.

Good luck in your endeavors and what you're up to right now. Um, we'll be, uh, looking forward to seeing what you, what what comes of, um, this opportunity that you've taken on. Thank you so much.

Thank You. I really appreciate, uh, both you and Tracy really enjoyed the conversation and hopefully I provided some insights into what I'm doing and, um, looking forward to that, uh, capital raise at this point. Yeah.

Alright, well Tracy, thanks for another great episode. Um, everyone, thanks for tuning into another episode of Techstrong Women. Look forward to seeing you next time and please tune in to Techstrong TV and watch a lot of great content.

Uh, we'll have another show coming up right after this. Thanks everybody. Thank you.

Thank you. This is Textron tv. Hey guys, thanks for the thrill.

We're here with Nick Kakolowski, who's senior research director for ions and they, along with uh, ANCO search, have come up with a survey on what's going on with salaries and CISO these days. Nick, welcome to the show. Great, thanks.

It's great to be here. Michael, From what I can see from the survey, salaries are up again, but maybe not as much as in previous years, but what do you think is going on in terms of demand for CISO? Because, well it is one of the most coveted jobs out there, but it's also, shall we say, somewhat stressful.

Yeah, and it was a a bit of an unusual year. We've seen compensation rates for CISO going up consistently over the past few years. And this year they continued to rise but by a smaller percentage than what we had seen in the past.

So we've often seen double digit compensation rises. And this year that rise was just about um, 11%, which is this pretty significant drop from 14% in 2022. Still eking out in that double digit rise but not nearly as high.

And a lot of what we're seeing, and some of this is a mix of anecdotal and actual data. So we saw about 12% of CISO changing employers in our respondent base compared to 21% last year. And when you think about it, you know, not many people are gonna be getting just an iterative 10% raise at their job.

They're probably looking at 3%, 5% cost of living raises. A lot of the big jumps in compensation come from CISO changing jobs, CISO getting retention incentives, those sorts of things. And with only 12% of CISO changing employers last year because of a more tepid hiring market, we saw the overarching compensation numbers drop a little bit.

Is it in your sense therefore that demand for CISO is steady about the same or slightly decreasing? What's kind of the drivers of the fluctuation? I put it up mostly to macroeconomic conditions.

We're not necessarily seeing demand for the role decrease. If anything, the CSO rules getting elevated in orgs as the new SEC rules and the general awareness of the cyber risks alignment with business risk along among businesses are leading to more CISO being thought of as executive roles part of the c-suite. What we're really seeing is businesses are just getting a little more conservative about their hiring, a little more tentative to, you know, reshuffle their programs and make major changes in the current economic climate.

And we expect that at some point that's gonna change and the market's gonna return pretty much to normal. What's your sense of the stress level that CISO are currently experiencing? Because, well, if you're gonna take that kind of compensation these days, there's a lot that goes into that.

And uh, I guess the question I'm asking you, is it worth it? Uh, you have to ask some CISO, but anecdotally is, we'll have some more research coming on this later this year. Well, I've seen in the past couple of years is around 60 to 70% of CISO considering job changes this year.

That figure jumped up to 75%, which is the jump from an eight percentage point jump from last year. And I'd say, you know, we typically see like an 18 to 24, maybe 36 month retention cycle on the CISO role, the job where folks tend to move pretty quickly and pretty often because it is so stressful, you get in, you achieve your initial goals of helping that program and then the stress adds up and you kind of move on and work your specialization somewhere else is a fairly common path for folks. And what we're seeing is now there is some pent up readiness for a job change in the market that isn't being satisfied by the amount of available positions.

And we expect when availability opens up that CISO are gonna be moving along just as they have been in the past. I Feel like a lot of the times these jobs are, shall we say unwinnable in the sense that there's always gonna be a breach and there's a tendency to blame the security people. And I frankly don't get why, because, um, if your house burns down, you don't blame the fire department.

So how come we're blaming the cybersecurity people every time there's a breach when generally speaking it wasn't their fault, they're just there to clean it up. Yeah, and I can empathize with a lot of CISO that are feeling that frustration and you know, our data doesn't speak to this exact issue, but we can see it in the marketplace. There is a tendency for, you know, mid-size firms with maybe less mature security programs where they don't necessarily view security as a partner in the business.

They view security as a regulatory checkbox to then blame the CISO when things go wrong. But then we also see the more mature orgs that are bringing the CISO into the C-suite into the boardroom regularly investing in their programs and recognizing the CISO as a partner. And that kind of shows up in our compensation data.

You know, our, so the median compensation figure for CISO this year was 388 K and the average was 550 K. And anytime we see such a big gulf between median average, that tells you that the market is stratified. And when we looked at that a little bit more closely, we saw that about 50% of CISO are making a total comp package of less than 400 K and another 30% are making a total comp package of around 600 K or more.

There aren't a lot of folks in the middle. And it tells us, you know, there are a lot of businesses who are still kind of figuring out how to uplevel and upcycle how the way they think about the csar role and the way they think about their security programs. But there's also a large contingent in the market that is starting to prioritize security and think of the CISO differently.

And I think in those kinds of businesses you're gonna see less and less of the CISO being looked at as a scapegoat and more and more of the CISO being part of the solution. We reach some level of saturation in terms of organizations that are willing to hire a ciso or do you think we'll see more organizations maybe smaller down in terms of volume and size starting to add this title? Yeah, I can't speak to that too much.

In our data, we tend to focus more on the wide swath of the market and not as much on the smaller orgs that are kind of emerging into the CISO role. I will say anecdotal, I shouldn't say anecdotally in terms of methodology and some of the work behind our data, there's a wide range from CISO who are regarded as directors to CISO who are regarded full on as C-level folks. And the compensation figures vary a lot based on those roles and how those folks are perceived in their org can vary a lot based on really where they are.

So even if they have a CISO title, they might be regarded more as a director within the business. Do you have any advice to folks that you've seen anecdotally about how to become a better candidate to become a CISO these days? Is there anything out there that you see in terms of soft skills maybe that are kind of a requirement We constantly see and talk about from our faculty and folks that are really working in the industry, that executive presence is just becoming a critical skill in the industry.

As CISO get brought into more board level conversations as they seek to really get a seat at the table with business issues and being made, being able to really belong among that executive suite is critical to kind of getting out of the back office tech stack and really being thought of as a partner in the business. So if you're someone who's aspiring to be a ciso, really investing in understanding how the businesses are functioning, where they get value, and then how you can contribute to that value and organize a program around that. And having a point of view that you can articulate in a concise way is really valuable.

And if you're a CISO looking to kind of grow, a lot of what we recommend is really investing in projects that extend beyond cyber. Whether it's EXCO assignments, whether it's, you know, working in risk, partnering with legal to kind of help solve some risk problems and governance problems. Really figuring out how you can contribute to the business's broader risk conversations, not just cyber conversations.

Is it worth going to get some business courses under your belt as if you wanna be a CISO these days so you can have those conversations. 'cause most business people, I know they're really good at talking about risk, but you know, you have to talk in the terms that they know A degree can be helpful. There are also plenty of cyber training programs that focus on business development skills and there's real world experience is valuable.

The key thing is to be able to have something that you can concisely show on your resume that displays that you've had exposure to business development skills, whether that's a degree that's great or whether it's I have worked on, you know, specific projects across lines of business that I can demonstrate on a resume to show that I've learned things here. It doesn't really necessarily matter as much as it's the ability to demonstrate that you've done it. Is there anything in the data that surprised you that kind of leapt out and said, wow, I didn't think that would be the case?

I think we were all a little bit struck by how much VC back firm compensation is pretty comparable to that of publicly listed companies. Like we kind of expected that VVC backed businesses would compensate their CISO fairly well because those orgs are very dependent on customer trust to be able to move forward. But we expected the cash compensation to be so low that it would be hard to catch up.

'cause we also know those orgs tend to have a harder time, tend to use equity as a way to attract folks into roles. And what we saw is VC back CISO, their cash compensation was around 369 K, but when you threw in equity, their comp, total compensation packages rose up to an average of 6 74 K, which was only 10 K below folks in publicly illicit companies. So if equity is ca helping them catch up a lot for VC back folks, Anecdotally, do you think CISO have to worry about liability more than they did in the past?

Should they all be investing in their own personal insurance policies or make sure that's covered through the companies they work for? Or is is that something, you know, we've heard people, you know, winding up being, uh, indicted for their roles. So what exactly should CISO be thinking about in that regard?

Oh, it's funny you bring this up. So this's something we're talking about a lot at our events, and I will frame this first by saying, you know, I'm not a lawyer, I am not a board member or an insurance person. I'm a lowly researcher who looks into a lot of this stuff and cares a lot of the content.

I would say there, it's understandable, very, very understandable that CISO have more concern here. They're seeing issues like the Sullivan case that are frankly frightening. It's worrying that you're gonna get scapegoated for a breach.

The business isn't gonna have your back and you're gonna end up becoming someone who ends up held liable for something. In practice, investing in your relationship with the executive team, documenting your processes, understanding exactly what your job role dictates you're supposed to be doing and are responsible for, and documenting when the executive team has you acting outside of that role. And if you do need to act outside of that role, making sure everyone is clear that that is the case and is behind it.

And again, that that gets documented is huge. And then, you know, whether you should be on the corporate DNO insurance has a lot to do with how the business is structured and where your title fits into the bylaws and overarching org structure. So look into that.

It's a great place where you can get some protections. If you can't get DNO insurance, start trying to negotiate for some indemnity so that if you aren't pulled into a court case, you have financial protections. And then personal insurance can also be useful.

Just lean in on really understanding your role in the business, what's being asked of you, and where you need to partner with other leaders as ultimately it's an executive group decision between the folks who own that risk around issues that might bring up liability, make sure you're not left making that decision in isolation and stuck in a situation where you then would be held, held liable. There's a lot that goes into being a successful ciso, whether it's your staff or your relationship with other business executives. Do you see anything that's trending that kind of is an intangible that would be your best advice to folks that who aspire to be CISO to focus on this particular thing?

Yeah, like I said earlier, the executive presence is there, and then within executive presence there's having a real network of partners within the business who you trust and can trust you. The relationship with sales leaders, relationship with risk leaders and other parts of the org can be vital when you get into sticky situations or when you're trying to rise up in the business. And you need sponsors who are gonna say yes, that person thinks in interesting ways about the business, not just thinks in interesting ways about security, but actually has ideas about what we're doing and how we can be better as an organization.

That then translates into the security program and adds value to everybody. And when you have folks in the org who recognize you as that kind of voice, it becomes incredibly valuable to rising up within the business. All right folks.

Well, you heard it here. To be a ciso, you gotta kind of be a business executive who understands it rather than just being an IT security expert. And those skills are hard to come by and generally speaking, they only come with experience.

So hang in there folks. Hey Nick, thanks for being on the show. Thanks for having me, Mike.

It was great. Alright, and back to you guys in the studio. Discover the cutting edge insights of our new show, AI Times, a series that explores the limitless potential of artificial intelligence sponsored by the AI Infrastructure Alliance.

The AI Times is at the forefront of the AI revolution, tackling the crucial questions of how we can leverage AI for the betterment of humanity. Stay ahead of the curve as this show delves into all things surrounding ai, including trends, pressing concerns, and the positive impact AI is making around the globe AI times. This Is Textron tv.

Hey guys, thanks for the throw. We're here with Andrew Davis, who's chief product officer for Auto Rabbit. And we're talking about, well, how do you maintain focus these days?

Because it's hard when you're confronted with all these tasks and I think a lot of us get sidetracked and forget to think about what matters here and maybe prioritize things better. But we'll see where we go. Andrew, welcome to the show.

Thank you so much, Mike. Great to be here. We have this issue in DevOps, but it probably affects everybody everywhere, but it's the same kind of thing.

It's like there's so much toil and so much scut work that maybe we forget to focus on the things that matter, but how do we kind of keep our eye on the ball? Uh, that is an excellent question. It's a, it's a perennial issue and I think it's, you know, uh, it's one of these mathematically unprovable challenges when you have unpredictable number of incoming requests and so forth, how to prioritize.

So, um, I would say it's a balance of, uh, there, there's two parts of our, of our mind that are always, uh, available to operate. The very focused part of the mind, the sort of very left-brained part of the mind that just, uh, zooms in on the task to be done. And then the, the broad awareness, the situational awareness that helps us to align with overall priorities and we need to be constantly moving between those.

Um, and in the sense of moving between focused tasks and then also stepping back and looking at the big picture. One of the best ways to do that, of course, is syncing with broader teams, teams out, you know, periodically syncing with broader teams within the organization, um, to hear what their concerns are and what they are seeing. And then also just to, uh, as development teams to get out and meet the customers and meet the people that you're actually serving, because that, that's always an important reality check.

And we wind up sometimes measuring the wrong things because we don't engage with the rest of the business enough. So we're highly focused on, uh, in the land of DevOps, shall we say, uh, you know, the speed in which a release is made, but the rest of the business is trying to focus on developer productivity. So do we need to kinda, um, gut check and realign with the rest of the business?

'cause sometimes we're not quite focused on what everybody else is focused on. Yeah. Um, I mean, developer productivity, these, there are these famous metrics in, um, in the DevOps space about speed and quality and, and obviously they, they are and will always remain, you know, important characteristics.

And they're, they're also, you know, integral to developer productivity, however we think about that. Um, but I think there's, uh, as, uh, I think as Peter Drucker said, there's nothing more unproductive than working hard on the wrong thing. And so of course you need to be constantly checking, you know, are we focused on the wrong metrics?

Probably, um, you know, and me metrics, metrics are always just a proxy to help get us a little bit closer, relatively closer to delivering valuable impact. But finally that's a qualitative assessment. Uh, it depends on measures that are not within the control of the development team, uh, directly.

So it necessarily requires interfacing with the broader business, seeing with the business priorities are how the team's being perceived, uh, but even also how the team is, um, uh, feeling, you know, is the, are are the, is the work feeling sustainable? Are they engaged? Are they interested?

Are they feeling like they're building their skills and so forth? So, um, it's hard to put out specific metrics that we should be focusing on because it's so situational. And typically whatever metric you focus on, it's always easy to over rotate on that metric.

And so you want to balance scorecard, so to speak, of metrics, you know, focusing on both speed and quality or focusing on, you know, the internal engineering metrics versus the revenue focused metrics, or typically there's different metrics will help orient the team in different directions. And do you wanna be looking at a balanced scorecard or metrics that, that apply some pressure on each other in opposite directions, uh, and then reassessing on a regular basis to see are you getting closer to the qualitative goals? We've been talking about the divide between business and IT now for, I don't know, four decades or more.

Um, are we getting better at this? Because it seems like it does come down to the fact that most IT, people don't really understand what it is that they are supposed to be working on and why it matters to the business. So it's hard to stay motivated And by, you know, by extension, most business people don't quite understand what the IT folks are doing.

And, and so I think there's no question, I mean, in detail the details of what they're doing. And so I think there's no question that there is a risk of getting that tunnel vision. I, I was gonna quip that we've been talking about the business IT divide since it appeared, uh, since the business presumably predated, uh, it, but um, is it getting better?

You know, it, it is a, these things are never ending challenges, right? Because you've got all these, you have junior people coming into the field all the time, and it's a lot just to try to get your head wrapped around your job. And development is by nature of very concentration intensive task, kind of takes most of your available mental resources to zone zoom in to understand what it is that you're doing.

And, um, you know, and so that necessarily, uh, tends to create a kind of tunnel vision. And that's that focused left brain thinking that I was referring to previously. That we do also need to be balancing that with right brain thinking, looking more broadly at why are we doing this?

What's the company, um, what's the company exist to do? And I would say that it's not that developers are intrinsically uninterested. Um, you know, naturally and understandably developers are people who chose to be interested in software development.

You know, IT professionals chose to be interested in that. So, you know, they find the problem solving aspect of their work fund. But, uh, I think there's a role for internally marketing what the company does to employees.

And that's something maybe for marketing departments and businesses more broadly to, to get better at telling the story internal to the company about what do we do? Who's our customer, what do we serve? You know, who are we serving?

Who are we trying to help? Um, and, um, if possible go out and actually meet the customer. I got a friend who works at, uh, DoorDash, um, as a Salesforce, um, development lead, but all DoorDash employees have to go deliver orders, you know, a couple times a year, including the CEO on a regular basis out delivering DoorDash.

So you never know when the DoorDash person shows up. It could be the CEO of the company, uh, depending on where you live. And so that's the kind of thing where you're, you're getting out of, um, you know, getting out from behind your computer, getting out from behind your desk, and, um, and actually going and, and either seeing the customers directly or doing other things.

There, there, uh, we've done a couple of things recently since I joined as the Chief product Officer here at Auto Rabbit. Um, uh, on my first week on the job I was in India with our team there. And, um, I was quite impressed with the staff of the hotel that, uh, we were saying that I was staying at.

So I began to engage them in conversation about how they think about creating a great, um, customer experience there at the hotel. And then ended up bringing the whole product team to the hotel for sort of a day offsite and getting briefed by the staff going touring behind the scenes, how they run the hotel, the operation center and so forth, so that we could see how businesses in real life function. 'cause I think there's a lot of confusion that, uh, is because everything we do in software is invisible.

And so even the messes in our code base are invisible. Uh, only very trained specialists can tell that there's a steaming big heap of manure in the middle of the code base, so to speak. You know, it's not something that's obvious, um, to most people.

So getting to know other industries, um, you know, we're gonna go and tour a carf uh, factory next week here in our office in Prague. And so getting to see how people do operations in other industries in real life is a good way of helping developers to understand, um, how, how you, how we can mature our process, which really is what DevOps is about, continuous learning and what is a fully operationalized mature process, uh, look like. The empathy needs to go beyond just the DevOps team.

The empathy has to reach out to the customer, right? Y yes. Yeah, yeah, yeah, yeah.

The customer and also, you know, the sales department, the marketing department, the support department, all of your, all of your colleagues throughout the business, there's a real danger. I think the bigger a bus, the bigger a business go becomes, the more we lose context, the more we lose clarity, um, on what's actually happening in the organization. Uh, if you're in a team, you know, a small startup, five, 10 people, you know, everybody, you know what's going on, you've got the context, the bigger the organization gets, the harder it is to maintain that clarity.

And that's why that storytelling is important and empathy with departments and other colleagues, uh, colleagues in other departments. Yeah. Do we get a little too attached to the scut work and the task at hand and that thing that we keep doing every day, whether it's writing scripts or, um, you know, just shifting a workload from point A to point B, and that becomes, at least in our mind, the job, when the job is really something else entirely different.

Uh, I would say, yeah, that's just another, uh, kind of another way of framing the same problem that, that we, we, I think as humans, we naturally lose context. It's, it's like you get sucked into a game or like, if you're watching a TV program, the world disappears. And that's amazing that our minds can do that, that our minds can sort of zoom in on something and just enter a new world.

And, and that's very important because as I said earlier, it, and especially software development there, there's such concentration intensive tasks. It's really important to get the world to disappear so that you have complete space in your mind to tackle these very, very cognitively demanding, um, tasks. And, you know, if you're, you know, the reason people become professionals, IT professionals is 'cause they like it.

They like the concentration, they like the sort of piece, they like the problem solving. They like the focus. And so, uh, anytime you get that, it can be a little addictive.

You can get a little attached to it, as you say. Um, and you can lose context. You can stop, um, uh, you know, seeing the big picture of what's, what's really needed in the organization.

And that's why I said, uh, I'll, I'll keep repeating the same thing, that there's this sort of left brain, right brain balance where we need to shift between the very focused left brain kind of approach and the, uh, the situational awareness, the broad contextual part of the mind that is, um, that we get with the right brain. And there's a lot of ways to do that, uh, storytelling, but getting out and engaging with the customers, hearing from other people in the business. But you're right, I think there is a tunnel vision that is detrimental, um, yeah, detrimental, uh, in, in all kinds of ways, including we can just be building the wrong solution.

We, you know, and we need developers to be engaging their creative minds. The better a developer really understands what they're doing, the more creatively, the more creative they can be in solving that problem. Um, Are we on the cusp of some major disruptions of our brains with the rise of artificial intelligence?

It seems like you can't walk down the street these days without somebody leaping out to tell you about their great new AI thing, but does seem like, you know, we're automating large swats of the DevOps processes, or at least they're about to. Yeah. Which I guess is you're prompting me to tell you about my great new AI thing.

No, uh, no, you're right. I mean, and the, um, the buzz and the hype, I mean, it's, it's for good reason. This is quite a disruptive, um, innovation, uh, to use that, that cliche.

Um, and I think that there is something really, there's, is very interesting, a little, little bit unsettling I think for software developers that we've been in a, we've been, um, in this very comfortable position where while the world of manufacturing was getting automated away by robots and, um, uh, you know, uh, that was also shifted, shifted outside of the us for example. Um, and we have had it and tech jobs shifted outside of the us but we've not had previously the, the sense that there could be an imminent disruption where robots are taking our jobs in the IT field. And so I think it does necessarily put pressure for us to, to think about upskilling, uh, learning, you know, how to work with these new and disruptive incoming technologies.

Um, but also it puts, it shifts the pressure, it shifts the pressure away from, you know, I know stack overflows experiencing a lot of, uh, you know, risk. They laid off a significant part of their sales team because a lot of the stuff that people used to go to Stack overflow for, to copy and paste solutions, now they're getting from copilot or chat GT or something like that. So, but that doesn't take away the need for thinking, it just reduces some of the upfront thinking to like, what's the right template for this?

You know, now you can get chat GPT to get, you, get, you give you a template that may be a good starting place, but it shifts the pressure, uh, it shifts the pressure towards editing, towards sanity checking towards making sure it actually works. Um, and towards understanding, um, how what you're building will fit into the broader landscape of your broader lands IT landscape in your organization. So the need for high quality thinking hasn't gone away.

I would say actually the, the pressure on high quality thinking, the pressure, pressure for high quality thinking has increased. So we need to be, while everybody's talking about artificial intelligence, the most important thing we can do is cultivate and protect our natural intelligence. So natural intelligence is, um, incredibly varied, right?

It's not just analytical intelligence, right? It's aesthetic intelligence, social intelligence, emotional intelligence, kinesthetic intelligence. There's so much, such a rich variety of intelligences we have and we really are under pressure to use them.

And I think you're, you're kind of hinting in that direction that software developers probably, you know, talk to people more and, uh, you know, get outside their cubicle a bit more. Uh, if anybody's still sitting in cubicles, um, uh, we need to use that natural intelligence because it's, it's, it's also easier to get fooled, right? It's easier to get, um, get results back that maybe have security flaws, security risks, um, in them.

You need some way to do like static analysis, uh, code scanning to make sure you've not introduced security risks into your code. You need to be, um, looking more at the big picture. 'cause, because one thing that I would say will be happening is that things will be continuing to accelerate just when you thought things couldn't move any faster, you're probably just gonna be accelerating more.

So ultimately, what's your best advice to folks about how to kind get that focus and not allow the overwhelming, uh, work of the day get in the way of actually thinking about what needs to be done at a higher level? I'm gonna, um, I'm gonna tag team some authorities on the subject that since we're on a DevOps podcast, uh, gene Kim's just, uh, reduced, released a new book, wiring the winning organization. One of the, one of the main themes in that, uh, book is basically three things that organ, that people and organizations need to do to be more effective at scale, uh, ification, simplification and amplification.

But ification, they had to make up a word to describe this, but it's, it's the idea that it's like thinking fast and slow. There's certain parts of our mind that are, that are geared towards very fast thinking, very reflexive, and it's very important that we have those, but they can't help us to solve novel problems. So for novel problems and strange situations, we need slow thinking.

And that takes literally slowing down the pace of conversation, stepping back. It's things like, uh, retrospectives in, um, in scrums. It's things like, um, postmortems, if there's an issue, it's conversations, um, and just contemplation, right?

Just taking a step back. And that there is a very, very important place for, for that slowing down the thinking process that also extends to things like being able to run tests in reliable testing environments, these kinds of practice, uh, environments where you're, um, you're, you're honing your skills in a non-production environment. Um, you know, simulating, um, simulating failures, simulating, uh, disaster recovery scenarios and so forth.

These are all examples of ification where you can slow down, get out of the heat of, of battle, so to speak, in a production environment and begin to, uh, yeah, do high quality thinking. So that, those are some thoughts on this. All right, folks, well, you heard it here.

I think what we're calling for is the equivalent of a DevOps retreat where we can go contemplate some of these issues and take a minute and maybe reorientate ourselves because so much of what we do becomes firefighting, that we forget how to focus on the fire prevention in the first place. Hey Andrew, thanks for being on the show. Well said, Michael.

Thank you very much. All right, and back to you guys in the studio. Hello, and thank you for joining me today for, uh, our discussion on Roblox to change, specifically focused on legacy systems and technical debt.

I'm Michelle Dunivan, and I am the analytics director at Best Friends Animal Society, and I'm really excited to share some, uh, insights and, and knowledge with you all today. So the first thing that I wanna do is make sure that we're on the same page about what is a legacy system and what is technical debt. So for today, we're gonna talk about legacy system in terms of an outdated hardware or software that's still in use, but makes it difficult or impossible to interact with newer systems.

And then technical debt is going to be the cost incurred when problems aren't fixed that will cause problems in the future. So in other words, legacy systems are one type of technical debt, and it's the type of technical debt that we're gonna be focusing on today. So what I'd like all of you in the audience to do right now is to think about a project that fits these parameters and what legacy system is causing you technical debt, probably all of them.

And if you don't already have a list, then now would be a good time to start writing it, because you'll probably get some ideas along the way of, of different things that you might be able to address in this way. So if you have legacy systems, then you're probably starting with some baggage. So one of the things that comes across often is imperfect predecessors.

So whoever came before you might have been beloved reviled. Either way they weren't perfect and you're gonna come along and try and make some change. And, uh, this isn't, this process isn't about changing or exerting who you are or comforting people about what you're going to do differently and why you're going to do it.

Really, you wanna understand what the predecessors were doing and where people stood so that you know where the teams are. Um, another starting place that you might be struggling with a little bit is turnover, or even your team growing to quickly. This can lead to unreasonable expectations.

So maybe if there's been a lot of turnover, they're thinking, oh, we hired the right person, they're gonna fix all of our problems, they're gonna be our savior. And maybe eventually you can be, but you might also need a lot more time and effort and investment than that, what they're expecting. So you wanna make sure and, and keep that in mind that, um, regardless of of what direction you're going in, that can be a, a struggle that you're, you're bringing with you into this process.

Also, antiquated or absent processes. So this is, that's how we've always done it kind of work. And that can be problematic in its own right that you're, that you might be working against.

Oftentimes we're dealing with not enough documentation, whatever it is, there's probably never enough documentation. Nobody likes to do it, but it's something that we do have to navigate. And then of course, the legacy system itself.

So if these systems are old enough, you might have a very small group of people who have the credentials or the skillset or the interest even in managing or maintaining that system. These legacy systems sometimes get forgotten. And so they might have lapsed maintenance or security patches.

And we also know that legacy systems are expensive to maintain, but they're even more expensive to replace. And so it feels a little bit like a known in situation because there is an investment needed, but it's not new and exciting. It's really just to maintain the status quo or to create something new that still only provides very similar functionality than what you had before.

So you're starting out with all of this and what's the problem? It's technical debt, technical debt everywhere. Um, the more you get, the harder it seems to dig out and it can be very demoralizing for your team.

The other problem that we see is oftentimes there's a disconnect between what the IT teams see behind the scenes and what the rest of the organization sees. And you don't always want to complain about or educate about all of the nuance. That's why they have an IT team is so that they get to deal with all of that, or that's why they have a data team, or that's why they have whatever team you are, you are in is so that you can handle all of that.

But there are some challenges that come along with that. So this cute little cartoon talks about shows how there's a, a house that's falling apart and somebody that says, I just don't understand why we can't add a new window. So you see this a lot when you hear stakeholders and business units saying, you've always made it work for me before, um, or somebody in your team promised me that we, I was gonna get this window and all I'm asking for is a little window.

Uh, one of my favorites is I should just be simple. It's just a little window, right? It's just something small.

And, um, one of my least favorites is, um, but the CEO, that the CEO definitely wants it or would hypothetically want a window in this exact situation. So really having to balance understanding everything that's happening in the background, but not necessarily being able to, to share that with everyone. So when you have all of this happening but still need to make a change, we are going to help come up with a buy-in strategy.

We're gonna talk about relationship building, and then we're gonna talk about how we execute. And you already have the technical expertise, so we're not gonna talk about the technical aspects of these changes. We're gonna gonna focus on strategy and soft skills that are gonna get you to execution.

I want you to remember everything is communication. You cannot not communicate. So when you're listening, that is communicating when what you don't say will communicate a message to some people, whether or not you want it to and what you say is important, but how you say it is really going to be the difference between whether or not you get that buy-in and that relationship building opportunity.

So starting from the bottom, we're gonna listen and we're gonna start from the grassroots. I really like to start with my team. It's who I have the easiest access to.

It's who feels like they have the, the most access to me. I wanna learn about their goals. I wanna learn about how they think I can help them achieve their goals, and are those realistic?

I wanna learn also about the formal and informal networks. Who are your mavens? Who are the people that everybody goes to for advice or if they change their mind about something every, you know, not everybody, but a lot of people are gonna follow suit.

And can you find people who are already on board with your vision and who are willing and able to help? So in the US our culture is very individualistic and we're very privacy oriented, so we don't always ask the questions that we could or should, but if you can be truly interested in and curious about someone else's role or their experience, you can ask all the questions you want. It's flattering.

And incidentally, research shows that the more questions you ask contrary to popular belief, it also builds liking. So you're building a relationship and you're getting knowledge. So you start with the team, you understand what the, what the ground source truth is from your team's perspective.

Then you move out to business users or end users and figure out what their needs are, what their goals are, how they think you can help achieve their goals, what are those formal and informal networks and who's already on board? And then you move on to leadership because you have all of this other information. They don't have to tell you about the whole universe, but they can look more holistically and tell you, here's some broader goals that we're trying to achieve.

This is how you specifically fit into their goals. Here's their formal and informal networks, and then again, who's already on board and willing to help. So once you have all of that figured out, um, you make a plan.

This is not the final plan. This is an initial plan and there's entirely too many variables. So I'm not gonna tell you specifically about how to build your plan.

I'm just gonna talk about a few general, uh, concepts that you wanna make sure are included in your plan. And the first one is think about all the goals that are out there. Start with all of them.

You've collected all of this information, you know what people want and need, and then think about what you can realistically achieve. Can you actually deliver those things? And then realistically, what you need to achieve that goal.

One thing I like to remember is that when you're trying to impress some people or you're trying to get people bought in or you're trying to help people, you might want to over promise, but we wanna keep realistic because I can either disappoint you now with how much it's going to cost or what I can actually do, or I can disappoint you after we've already invested time and money and energy into this project. So just a little, uh, a little information about what is realistic. The three-legged stool is something that I go back to all the time.

What is a realistic scope, time and money. So when you look at that list of technical debt, hopefully you've been compiling or you already have created, I want you to think about which one of these three is the biggest barrier to buy-in. Is it that the scope is too big, not big enough?

Is it that there's, it's gonna take too much time to achieve that level of scope? Or the the time maybe doesn't feel like it's worth it to the people who are going to be implementing and the money. Um, money's gonna be an issue for every type of organization all the time, right?

We always wanna save as much money as we possibly can. So then after you have that plan, start shopping it to leadership. Remember, this is an initial plan.

You have all of these things taken into consideration. And for me, I like to start with leadership to the extent possible. That doesn't mean that I don't go to my team about what my plan is or I don't go to select stakeholders about what the plan is going to be.

But once I feel really confident in like, this is a really good starting point, I do wanna go to leadership. Because if you don't have leadership, buy-in the rest of it is gonna crumble, especially for a, a legacy system tech get type of project because it is not fun, it's not exciting, and you do need wide support in order to get it done. So, um, buy-in then is where you start getting some resistance and there's a lot of different types of resistance.

So this is also the, the phase this buy-in phase. When you start getting this resistance, the first thing that I start thinking about is what you wanted me to fix all the things, and here's how we do it, this is how we start. But you have to think about the other side of that coin as well.

Change is hard. You might not be thinking about, you know, the the newest shiniest innovation. This is something that is, that is foundational to your organization or that is in a, in a back corner somewhere that people aren't even aware of or don't even realize needs to be given some love.

So it's gonna be hard for them just as if it was a bigger innovation. Um, these system, these these pieces of resistance are going to be combated with relationship building. And that doesn't mean that we're being duplicitous or manipulative.

It's that we truly need to build relationships with stakeholders. That's leaders, peers, team members, business units. You don't have to get a hundred percent buy-in to be successful.

So this isn't about saying like, yep, there's lots of barriers. So I guess we should just give up. This is about reframing what you need to do, not technically, but what you need to do relationship wise to move the needle on the projects that really need to be addressed.

So I'm gonna start with an example. Um, maybe you are in a local government agency. There's a homegrown legacy software system with thousands of embedded crystal reports and it's six versions old.

When they embedded it, they didn't think about having to upgrade the crystal reports along the way. In the meantime, because this system is very, very old, we'll say decades old, you now have a new parallel software system that is slowly taking on the responsibilities of that legacy software system. And that new system is using SSRS for reporting.

You have no documentation because it wasn't expected 20 years ago that you would need it 20 years later. So you don't have a good view of the architecture, you don't have a catalog, you don't have business rules for why things weren't selected in these thousands of reports. It's all about reverse engineering to figure out what's happening in each and every one of them.

You also have no dedicated data engineers on staff. You have one person who's really capable of troubleshooting these reports in this legacy system, and your business units and business users are finding conflicting data in different reports and that some business critical reports are not rendering appropriately. So I want you to again, look at the projects that you've listed with your tech debt and think about which projects are facing, which type of resistance are it.

Does this give you some ideas of other types of projects that may be considered technical debt, um, that, that you really wanna think about addressing? So you have the problem, what's the plan that you're gonna come up with? So for this example, the plan is we're gonna audit all the reports.

We're gonna set and set the ones that haven't been used in 13 or more months. We're gonna prioritize by the volume of use, who, how many, which reports are used the most over the last 13 months. Identify simple conversions, purchase a conversion tool, hire a data engineer to do all of those things that the conversion tool can't do or whatever cleanup the conversion tool leads behind.

You're gonna document all the things this time around and you're only gonna convert as is. And if there's an existing backlog item that already was documented that needed to be addressed, uh, you're not gonna do bells and whistles, you're not gonna do all the improvements that come up during testing, but you are gonna rely on stakeholders to test. And then at some point you've decided that you're gonna retire the server.

So here comes the, uh, the, the first one, uncertainty. You're gonna get this from all levels, levels of the organization. Uh, in fact, all of these roadblocks, you're gonna see different types of responses to the different types of roadblocks depending on where they stand in in the organization.

So from your own team, you need to recognize that they've been working with this for a long time. So fixing tech debt is uncertain to them. They don't know what's coming.

They don't know what that means for them. So one of those is we don't even know how big the, the problem is yet. Maybe we know how many reports there are, but we don't really know how difficult it's going to be to address these problems.

What if we break something else in the process? Did anyone on our team actually have the time and ability to do this? So these are maybe not questions that don't have answers, but they're questions that people are going to have and they're legitimate concerns because people don't know yet it's new, so they can't know that it's never been done before.

The next layer of, of people that will have uncertainty is like maybe they're uncertain about your skill and ability to execute on this. And so you might get some pushback about that from stakeholders. Um, you might get some pushback about like, I already know how to do what, I'm gonna do this new thing.

I don't know how it's gonna work. And so I'm just gonna go ahead and hold onto what I have right now. And then this idea about like what if you decommission or sunset something that I actually ended up needing in the end, what if I don't get it?

What if I don't get it back? What if I don't realize I needed it and I end up needing it? Again, legitimate questions that need to be answered, but they're going to come up and they're going to be, because you know all of the ins and outs, you are gonna know those answers and they're not.

So patience is, is key in this. And then how long will it take from leadership? Leadership's gonna wanna know like, how long am I making these sacrifices and, and not moving onto the shiny fancy new things in the process.

And then, is it really that important because this is a huge project. Do we actually have to do this? So when you get this kind of feedback, you can move on to um, how you, how you combat that.

The first thing is transparency. You're gonna need to promise change. You have to sell it carefully that there will be benefits, but that there's also realistically gonna be some challenges along the way.

You wanna keep expectations reasonable and that's transparency is one of the best way to to do it. If you don't know something, you can say that you don't know something, it's okay. Um, it also helps you to maintain your personal credibility.

You're not over promising when you say something's gonna happen. They can be certain that it's gonna happen. Communication constantly, clearly, frequently, you wanna fill the void so that the rumor mill isn't your competitor.

If you don't answer a question, if you leave something up in the air, others will fill that space. They will let their imaginations go wild. And you don't wanna have to fight against rumors that that started because you just didn't communicate enough.

And then you wanna clearly explain the processes. So that's how we're going through this conversion. But also providing some resources for in the end, if you're not familiar with the new reporting system or new style or how we're going to do that, provide all of that knowledge and information so that it reduces the uncertainty and so it reduces the anxiety with the change.

The next one is to break habits. Um, some feedback you might be getting from your team is, uh, that's not how we do it. We have a habit of doing it a different way from stakeholders.

I'm just gonna keep doing it the way that I've always done it. This workaround is just fine for me. Um, why do I have to learn something new?

I'm good with what I have right now. And leadership might be thinking, we've never had to do this before. This isn't a thing, this isn't a process.

This is brand new to us. Why can't we just keep doing it the way that we've always done it? The longer that a group has been doing something a certain way, the longer it's gonna take to undo that habit of, you know, just going directly to this place or directly to that place, or knowing that they need to assign this task because the pro, the system isn't doing it the way that ideally it would be doing it.

So when you come across this kind of resistance, you're gonna look at, uh, understanding that people will revert back to autopilot. It's natural, it's expected, and it doesn't mean that we go back to the status quo. It just means that you recognize that it's not the end of the world and it's not personal.

Don't take it personally when people forget or they're in a crunch and so they have to go back and do it the way that they did it before starts. Small, small changes can have a big impact. If you think about turning the, the a boat one degree difference and letting it go on a one degree difference course, it ends up in a very different place than where it started.

And that's especially the technical debt. That tends to be a really strong way to move the needle. And then at some point, to maintain the boat metaphor, you do have to burn the boats.

You have to make sure that there is no escape route. That you are making sure that we are all certain that this is the direction we're going in. And so we are going to decommission, we are going to make them unavailable sooner rather than later.

You have to commit so strongly that there is not a way to turn back. But third roadblock is the investment, right? And this isn't always just money, it's also tying in people's bandwidth that are being invested.

So your team might be saying, I can't believe they're gonna hire someone to do this instead of the millions of other things that need to be done. Can't we just start from scratch? I don't know how many times in projects we've said, I just wanna blow up the system and start over.

Your stakeholders might be saying things like, I don't have time to help you test. I'm not gonna invest that time. That's your job.

You figure out how to do it, or you're not converting all of them. We're investing all of this and we're not getting everything that we started with to, to end up with. Leadership's gonna be saying, I'm investing an entire tool and an FTE into this dying system, or we can't develop any new reports during this conversion.

And then another one is an investment of social capital From leadership. You are going to need them to back this and to help burn those votes and to help persuade at higher levels of the organization. And so you're asking them to invest their social capital in what's typically a pretty boring project when you get that kind of, uh, pushback.

Again, you wanna rely on transparency. What is the cost of a change? There is going to be a cost and then only proceed it when it can actually be afforded.

Tech debt needs to be dealt with eventually. Oftentimes, sometimes it doesn't need to be dealt with. Sometimes there is some other way.

And if you are showing the true costs and the organization is just not willing to absorb those costs, knowing that upfront can stop an ill-fated change from going into effect. Similarly, if you are 20, 30, 70% of the way into this project and you see it is just not working, it's just there's a different better way. You have to be willing to kill an underperforming initiative.

You can't keep throwing good money after bad people's time after something that's not gonna come out in the end. You can also look at the flip side and communicate the cost of the status quo. You're gonna continue to be getting poor quality reporting.

You're gonna continue to be struggling and having workarounds if we keep it the way that it is. And then an investment of power and responsibility to others on the team can sometimes turn this around as well. When you recognize that individuals can feel invested in the outcome of this project, that can also help you to overcome this concern about what the investment is.

Okay, the next roadblock risk. Your team will be saying things like, what if we break something else in the process? What if we can't figure out the mess of a system that was left behind?

Stakeholders will be saying things like, well, mission critical work be impacted negatively. And leadership will be asking, could an error in this project land us in the news for all the wrong reasons? And you start hearing that kind of pushback.

You wanna lean into the risk taking, actually, this is important. This is how we innovate, and this can be a really good, uh, example of what we're gonna do on more fun projects is you lean into that. You can actually make this an opportunity as a catalyst for more change while you're going through the change.

Your goal is not to stabilize during the change, it's to create stability afterwards. So while you're in this shakeup opportunity, is there something else that you could kind of sneak in or that could be part of this, this bigger change? You wanna address people's fears.

They have legitimate fears and they are concerned that it will affect them negatively. And it might, but you can talk about how we alleviate risk and how we mitigate risk. Um, and, and again, it comes down to communicating and, and being open and understanding that it's a natural part of the process.

And again, when you start small, you can keep the risks small as well. The next roadblock that we come across is culture. Um, you'll hear things from your team like, I'm gonna be blamed if something goes wrong because that's the culture that maybe existed already.

I'm gonna be out of a job after this project. How can I work in this environment when I'm really finishing something so that I no longer have a fleece here? Um, you know, you can also just stay out of it, right?

Like I, I don't, I don't feel like being part of this. I'm gonna let them go ahead and, and deal with that monstrosity over there from stakeholders, you hear, why should I support your efforts with what's in it for me? Um, or even territoriality.

They're not gonna touch my reports. I'm good with mine. I don't need you to do anything else.

And then leadership, my especially on something like this where it's is more technical heavy, the those technical debt items, they don't need me to get involved in this. I'm good. They can just, they can deal with that over there.

It also keeps me from having to give up any of my social capital. When you hear these, what you're gonna see is that the, the best path forward is a supportive work environment Change may make employees feel threatened, insecure or vulnerable and, uh, and become inhibited. So you wanna create that supportive work environment.

As soon as people start shutting down, it's the exact opposite of what you want and need for a successful organization change. You're gonna need to put your people skills to work, make people understand that they are needed, they belong, and that you are gonna support them moving forward. And you're gonna have to lead by example.

Really put your money where your mouth is, you know, not just the talk, but also walking the walk and provide a sense of purpose. Uh, remember why we're doing this in the first place. We're doing it not just for this one system, we're doing it so the organization works better so that maybe our working environment in having to deal with these legacy, legacy systems is improved.

And then finally, bring in executive support where you can let them know that you absolutely need them. Anytime one of these changes, even if it's something that feels like it's background, it can become a showstopper if you don't have explicit support from executives. Okay, our next roadblock to change is the capacity for change.

This is really about resilience. So if your team is already at capacity, they've already absorbed as many changes as they can. There's been turnover, there's new leadership, there's all these other new projects, you might be hearing things from them, like, we're already working on a million other things.

Stakeholders might be saying things like, don't they realize I've got my own things that I wanna work on? And from leadership, you might hear, this just had been a good time. And this one always irks me because it's never a good time.

There's never a time when you're just like, okay, we're just gonna coast now. No, every organization I've ever seen or worked in is saying it. There is a knowledge and ex expectation that we're always gonna be doing new innovative things.

Sometimes that new innovation is as small as tech debt, but there's always improvements that are needing to be made to remain relevant. So again, start with small goals. Small goals are gonna be easier to absorb.

If you think about a saturated sponge, just a little bit more is gonna be much better than a huge, a huge change. Short range objectives, you're not thinking about transitioning thousands of reports you can think about, we're just gonna start with these from this one department. These, you know, these four reports that have the biggest impact.

The next one is, you still wanna keep it organization-wide to the extent possible, they deliver solutions that are common across everybody in our sustainable long term department specific customizations and, and projects. They add business value. The department level deployments are faster, they face fewer hurdles.

So it kind of fits into the small goals, the short range objectives, but it lacks the resources and general appeal that helps to maintain them so that that can become problematic as well. And then of course, be agile. You might start out thinking that you're gonna do one thing, but you can do it incrementally, right?

And you can shift and adjust once you understand, okay, this group is ready for change and this group isn't ready for change, or this is a change that can be absorbed. The last roadblock that we see is about metrics. And this is really important to capture those metrics even in the throes of everything that comes at you with an organization change, it feels administrative.

It feels like there's not a lot of value add, and teams are already complaining about documentation. This isn't gonna make them feel any better, but we have to collect this information at the front in order to understand where we continue to have issues and what other resources we need in the future and how successful we are. So you're gonna hear things from your team, like, I'm too busy trying to get this effort launched.

I can't work on this too. Can't somebody else do this? Other organ or other parts of the organization might be saying, I already helped test.

I don't wanna help maintain it too. Don't be asking me for, for things along the way. And even leadership might look at this and say, metrics are fine if we have time to do it, but you can do that later.

And the reality is you can't do it later. You don't know what your baseline is if you haven't collected data before you launch. So that's, that's really important how you do that.

You can focus on what you care about most. Um, those are the things that you're, what are the goals that you've tried to achieve with this? What are other people's goals that you've tried to achieve?

And how can you measure those things? And then again, transparency, make it available to everyone. Even if you're not doing well, it can demonstrate to them why you need their support.

You can can say, you can show that we're not getting the resources that we need or that this has gotten off to a slow start, but we made the right choice for these different reasons. And remember, the data is useless if it's not driving change. So you really do, again, going back to number one, you wanna focus on what you actually care about.

Don't collect data just to collect data, just to say that you have something. You wanna make sure that when you, when you have it, it's, it's gonna be ready to go. So after all of these roadblocks, you've navigated all of them.

Now it's time to figure out when to execute. And this is when you need to think about your own roadblocks in overcoming challenges to change. This is your time to drink your own champagne.

So if you're facing your own uncertainty about when is it time to actually pull the trigger, 80% consensus, not 100%, even 80% of the information, if you wait until you get a hundred percent consensus, you've missed the boat and you've invested too much time and effort into that part of the process process, breaking your own habits, find out what that crutch is and remove it. Be disciplined enough to know what it is and know how and when to, to remove that crutch. When you're thinking about the investment that you're gonna have to put into this, you can scale it and make sure that it's a reasonable investment.

So scale down, not scaling up and really thinking about what is, what is the right way to take advantage of this opportunity? You're thinking about the risk, that's, that's part of this. And then you gotta think about what's the risk of not executing?

What is the organizational culture? This is the slowest thing to change. This is something that one person cannot change, but you can come back to your own, your own part of the organization and the culture that you want to be responsible for and how you want to do that.

So come back to your why, why are you doing this? So even if there are cultural barriers that are going to stop you, remember, you know, if you have a strong enough purpose for why you're doing this, it's going to help you get through to the next stage. And then your own change capacity.

Like, how can I actually do this? Am I, am I ready? Am I prepared to take on something larger?

So again, remember to, to start small. And then finally metrics. And you've gotta lead the way if you want other people to use data to come to you and say, okay, this is why we need the next, uh, change to be made.

This is the new system that we're going to implement. Uh, you've gotta show them how to do that. A lot of people in a lot of organizations try to be data savvy and data-driven, and they aren't there yet, but you can help 'em to show what what's happening.

So now I want you to take a look at your tech debt list that you've been compiling and think about where are you being your own barrier to change, which changes already have leadership buy-in at least conceptually. Maybe you're not there on the nitty gritty of it, but where do you think that there's, there's not a, a challenge to get them to buy into this? And are there any roadblocks that will actually kill the project?

And can you overcome them? Can you be prepared for that barrier so that you can still, you can still move it forward? And if you can't be realistic about that and, and why you can or can't.

So in some, we talked about a buy-in strategy. We talked about relationship building and execution. And now I want to open it up for any questions that you might have.

Security remains top of mind for organizations as we wind down 2023 and look ahead to 2024 and beyond. But what does an effective, efficient SecOps team look like? At SecOps Vision for 2024, you'll hear from industry thought leaders who are pushing the boundaries of SecOps practices, leveraging new tools to improve detection and response, and delivering effective security throughout their organization.

Don't miss this free virtual event to learn what an efficient SecOps team and culture looks like in 2024 and beyond. Hi again, everyone. I hope y'all enjoyed today's episode of Techstrong tv.

We had an amazing set of interviews with industry professionals to give you the inside scoop into the tech world. We'll be back again soon. So I hope to see you then.

In the meantime though, if you want more tech strong TV content, be sure to check out our podcasts or download our mobile app. Thank you so much for watching and I hope you have a wonderful rest of your day. As always, stay strong.

Text strong.