Career Village: WTF is an Org Chart? Building Security Teams

Hi everybody. My name is uh Matt Damco. Uh I am the head of security at Zenity. I'm passionate about a couple of things. Security engineering is certainly up in the top. Uh but leadership theory. I got introduced to this concept called organizational psychology and it's just nerd out about it later with me. It's it's fun. Um, but yeah, so that's that's me. That's who I am. Uh, just a before we get started, quick show of hands. Who here is from like a manga company? That's right. I'm using the acronym now. >> Wrong. >> It's is it a different >> No, it is. >> Okay. All right. So, so about half the group. So, here's the the disclaimer

that I'll give you as we go through this. Uh the the reason I wrote this talk is because I've been spending a lot of time with with founders of startups, smaller companies, and they're trying to figure out based on what phase we're in, how do we grow security throughout that program. And so if if you're at Amazon right now and you're on one of like 12 federated security teams and you're trying to figure out how to write your one p your five pager so that you can get approved for OP2 I all those terms I've I've kind of backed away from them. Uh and so the the focus of this is really from that like first security

hire up until we get close to an Amazon scale. And so that's sort of the the goal of what we're going to talk about today. I kind of answered the why uh where it comes from. Uh but in reality, the reason why I wanted to create this talk is because security kills companies. And when I say that, you probably think this, right? If there's a significant breach, if we release software with a uh CVSS 500 score, we're going to have a bad time. The company's going to struggle. Um uh so it's it's going to be tough, but the other thing that kills companies is security. And so if we're if we're we're forming an organization and

there's only five of us, but every single thing that you want to do requires a ticket, that's going to slow the company down. It's going to die before it can actually make any progress. If every single third-party library that you and your co-founder want to use has to get reviewed by a security person, you're going to light money on fire asking someone to review all of these libraries and your company's not going to go anywhere. So, whenever I think security kills companies, I think in both of those lenses. And so, how do we as we're we're building these programs make the right decision? So the the first question is when I when I meet with these founders is well what

should the security team look like? What should the program look like? And the answer just with everything else is it depends. Who said it depends this week, right? It's it's our favorite phrase as security uh practitioners. Uh the same thing goes when we're building the team. But the it depends in this case is what does the business actually do? Are we in an industry that requires super super highlevel security programs or are we in an industry where you know if if my Facebook pictures get shared all over the internet because I I linked with this new device it's not really the end of the world to me. uh is the company five people or 500 people uh and then

the culture of the company kind of plays into it as well and we'll talk about that too. So whenever I try to solve for those last few questions uh I start off by defining our business persona. I identify the needed security personas and then I figure out how to organize them. So, we said, well, it depends on the industry, it depends on this, it depends on that. These four questions are going to be the things that really help you rightsize the program that you're building. Uh, the first one, uh, what type of product do we have? Are we selling directly to consumers because they don't generally care as long as the product works? Are we s selling to Amazon? Will

they care? The Amazon thirdparty security team will run you through the mill. Um, it's it's tough. Uh, or are we selling to businesses and they're going to take our product and put it directly in front of their customer. So, if you think about the difference between how worried you are about Jira versus the how worried you are about Ozero. If you are Ozero, you're very very worried about your site going down because it's not just you, it's half the internet that decided to sign up with Ozero. And so understanding where the business fits in that place is really important. Uh the next piece, are we in some sort of special industry? So creating an AI IoT

device that could go either way. It could be a HIPPA compliant medical device that uses AI or it could be a stupid orange box that you can talk to it and it can pretend like it's controlling something for you. Uh and then uh the last piece is about the customers. So when we think about our customers, are they very very focused on the tech or do they just want something that's going to work? They're not actually interested in it. We're just a pathway to getting things done. Based on all those things, the way that we build the program's going to change. So, we've kind of covered how we want how the business needs us to act, but

now we need to think about what does my team need to be made of. So, I like to call these security personas. And I break them down into uh work type and superpowers. So work type super super broad is it corporate security? So we're thinking about laptops, printers, software, endpoint device and response. That's not the right acronym for EDR. Uh EDR software uh uh we're thinking about those kind of things. Product security. This is where we're actually thinking about the software that our company wrote. We're thinking about all the features that are involved and and do they actually support a secure adoption by our customers. And then the last part is the part that keeps

founders I think the most busy which is sales security. Because if I start a company in my garage and I try to sell it to someone else and say you should be my first customer, they're going out on a limb to to trust me inside their environment. And so a big part of what a founding security person is going to do is what does the customer want? Okay, I need to go do that right now. So that's sales security. Uh and then we have superpowers. And so I like to separate the focus area from the superpower because you're engaging in a totally different way. So if you're engaging with an auditor, you're very very focused. I have all of my artifacts

done. Uh I have all of my policy letters written. If you're dealing with engineering, you're you're creating libraries, you're reviewing designs, you're helping engineers understand that the pattern that they chose to start with doesn't work just from a availability perspective, but also from a confidentiality and integrity perspective. And then the last piece, which is really, really fun when you get to work for a security company, is the evangelism because you get to go places and say, "Hey, I know something about security. Let me teach you about it." or here's a struggle that we're having internally. Let me share that struggle and how we solved it. You're going to need at a small to medium-sized company

someone that can stretch across these uh all nine of those areas. So what I do is when I first meet with the founders is I sit down and I I draw up this little nine box, but instead of having somebody's potential versus their uh current performance, uh I I lay out those personas and those focus areas. And it's really nice because if I look at the tasks that I have to complete throughout a week, a month, a year, uh I can I can typically put a dot somewhere on that grid that says this is the work that I'm doing. So whenever when I meet with founders and we're talking about, hey, there's like 10 of us right now that we want to

make our first security hire. I typically tell them no. I typically tell them what you need is an S sur with a black hoodie. What you need is to not is to be thinking about the future but not necessarily building that huge program that you had at Facebook because it's not going to serve the business in the same way because you don't have the same resources and you don't have the same constraints. And so this is what uh the the security team at a very small startup looks like. The the big thing about working in this area is anywhere we go wrong, the company's going to die. If I make security too hard, I'm going to kill the

company. If I'm not secure enough to make the customer happy, I'm going to kill the company. And then if I end up on CNN, uh, I'm certainly not going to be having a good time. So, what do we do to address that? The the way that I like to talk them through this is find a trusted partner. At this stage in your life, you really need someone who has expertise in the problems that you have. And so if you have a problem with a customer needing you to have a sock too, yes, you can you can absolutely invest hundreds of hours in doing all of those steps yourself or you can hire someone that's really good

at building out a good SOCK 2 compliant program and they'll come in, they'll help you and then they'll actually help you find the auditors that will audit you and then the entire process just sort of rolls through. Uh the same thing goes for EDR. I I wouldn't want to manage an organization that doesn't have some sort of antivirus running on it, right? That that doesn't sound like a a good thing for me. Uh, but at 0 to 50 people, I don't have the resources to hire a full-time detection and response person and a full-time corporate security person to make sure that it's managed, to make sure that it's monitored, to make sure that we're doing

something when it's over. And so, what I'll typically do is find a third party to partner with and, hey, you're going to be my managed sock and this is what you're going to solve for us. Typically, it's the other way around. you go to them and you say, "I need an adult." And then like five different uh vendors will pop out of the woodwork and say, "Hey, we help we we do security for you. You just got to pay us." And it's typically much less expensive than uh a principal engineer full-time working on those things. Uh the other thing that I like to focus on in this phase uh is composable security patterns. What do I mean by

that? I hate solving this oneoff problem. I hate looking at a single API and making sure that it's secure. What I really like doing is saying, "Hey, as long as you imported our library for doing a authorization and authentication, we're done. Just only use that library." And then either me or one of those third parties that I hired will help me create a CI/CD pipeline that validates. Okay. Yes, they used that library. They were supposed to. There are people you can hire to help you create checks in your CI/CD pipeline that say, "Okay, you didn't pull in any dependencies that we know are compromised." Next week, we'll get a different answer. Thanks, AI. Um, but uh

it makes it better. Uh, and then the last piece is self-service tools. So, one of my favorite things about working at the bigger companies is you get to build these super impactful, super scalable self-service processes. Uh, I have a friend who helped roll out uh, Santa uh, internally and it was the coolest thing because instead of having to manually approve every single binary, we just had a web page and you run a command, paste in the the the hash of the binary that you want to be able to run and then if enough people click yes, this is legitimate, I want to run it, it's just automatically allow listed. That's a really cool self-service tool

to help the company be safe but also unblock people. But at 0 to 50, you don't get to build that. You need to find someone else to do that for you so that you can do other things. Uh the the sort of the high level thought for 0 to 50 is I don't have a program, I have a problem. And we're going to solve those problems. Eventually, we will push those problems into programs. So here's sort of what that looks like. We went from just that one person to now we're augmenting with some sort of external staffing. Uh super secret that I hope is not as big of a secret as it feels like it is sometimes. Um if you're

launching a startup and you're like I want this but I can't really afford to spend half a million dollars on a top tier integrator. Fun fact, AWS, uh, Google, Microsoft all have accelerators for startups where you can say, "Hey, I'm starting a company. It's pretty cool, but I need help." And they'll end up giving you credits. You can use those credits not just for compute and storage. You can use those credits for professional services. And so I've worked at companies where we got six months of expert support from an entire team of people and it cost the business zero dollars because we went through those accelerated programs. So uh certainly take advantage of those. Uh in any case

0 to 50 you're getting support you're not providing support. So the next phase uh is what I like to say we're scaling. So it's it's 50 to 250 people. Um the the things that you're thinking is, "Oh my goodness, I can't believe we did that three months ago." Uh and now it's a problem. How do we solve it? The things that you're thinking are, "Why did our last customers not care about this?" But these new ones that are writing us extra zeros on the contracts, why do these new customers care so much about the version of TLS that we're using? Um, you're you're struggling with maturing with your customer base. But one thing that you're noticing is those personas that

we thought about earlier, compliance, engineering evangelism sales product corporate security, they're they're starting to become less of these just one person grabbing whatever they can and they're slowly turning into pillars. So you might slowly have one person who handles all things compliance and that person works both with customers and with auditors and with the engineering team. The idea is as we continue to grow, we're able to specialize a little bit more uh and life gets easier. So, if you look, I don't think it's on the next slide, but you'll see that I added three things here. Instead of that one giant bubble in the middle, we still have our support, but we also have our

GRC analyst who handles things top to bottom within the compliance field. We have our security operations person, which handles sort of product security, corporate security, left to right. And then we we have a prod tech lead. This is typically when I think like a a first hire at a at a company, it's typically that prod tech lead and then they're just struggling until they can get into that grouping where they actually have two other people wearing those two other hats as we're as we're looking at hiring. So, you've got your your first security person, they join, they're just sort of running around because everything's on fire. They're obviously going to say, "I need help." The thing that that I think

I've seen a lot of companies go wrong with is they're like, "Oh, well, we have a budget. We already have a senior person. Why do I need another senior person?" Uh, "Oh, well, the team's growing. Maybe we should hire a manager to organize all of this." And what is no fun in my experience is to be a manager of a team with one person that actually executes because what is what are you doing as a manager if you have one engineer that does all of the work. So those first three hires in security as we start to scale I think in in my opinion I love to see them all be executors. They're people that are

subject matter experts in their field. They're people that are really excited about what they do. And they're people that aren't afraid to stretch out a little bit because we're still not in a place where you can just say, "Oh, this is my lane." Uh the other thing you notice as the company grows, that same focus we had within security, we're going to have outside of outside of security. So when the company first started, it was probably five engineers, one marketing person who did literally everything for marketing. So as far as uh I have to worry about random software being installed that's that's actually malware, there's like one person at the company I have to worry about. We can be

friends. It's pretty easy. When we get to 50 to 250 people, you've got like 10 people that are non-technical. You've got like 30 people that are non-technical. You've got way more people that that haven't been here since the beginning and they don't innately understand all of the problems that you've been facing. And you have to either have time to teach them all or have time to respond to all of those problems. I think there's a happy medium between those two. But the point is at this phase, the business is chaotic and you're just going to have to figure out how to deal with it.

When we get over 300 people, this is where because earlier I said we're starting to switch from personas to pillars. When we get over 300 people, this is where we see those pillars show up. And the gap between this and a 5,000 person organization is is really going to come down to uh how well did you define each one of those services that that fill out within it. So at at 300 people plus, this is where we need to start planning because if we're at 300 people today, we're going to be at 600 people in six months. We're going to be at a,000 people in n months. Uh if you think back to those first questions that we were asking

about the business, one of those questions is how big is the company going to be in six months? We need that answer so that we can decide on how much capacity we need. So at this phase, we have to be taking time and this is really hard to do because you have you have this opportunity to just always feel like you're doing the right thing which is putting out a fire. But if it's a tiny fire right now and we just leave that other thing that's not even fun to do planning, if I just leave that to the side while I put out tiny fires in six months, that fire is going to be huge

and I'm not going to be able to put it out and I'm just going to have to continue to do my best. So making time for yourself towards the edge of that 50 to 250 uh growth phase in order to actually do some some solid planning, thinking about what the business needs you to do. That's super super important as we grow this team. We're thinking about what the hot spots are. And what I mean by that is if I spend 90% of my time doing customer security reviews, a customer wants to buy something, I need to tell them how secure we are. I spend 90% of my time doing it. What else aren't I doing? And is that

the most valuable thing that I can do or can we find someone that specializes in that to just do that and I can focus on everything else. So the way that you grow this team as you've shifted into the pillars is you look at each one and you say okay I spend a lot of time managing vulnerabilities in Python libraries because nobody is going through and updating the way that I want them to and it makes my reports look bad and I'm sorry that's flashback from work. Um the the the point is you find this hot spot and you decide either I'm going to invest in technology to solve it for me or I'm going to invest in a person to to

build out that that problem space.

So there's been lots of highlevel hypothetical how do I do this or this is what you need to do. Um taking it and putting it more into practice. How do we plan ahead? Once we're at the point where we we're defining pillars, I really like these three, by the way. I think they will get you through up to like a 500 person company. Um it and it makes sense in my head, but every company is going to be different. Again, if you work in a medical device field, you probably don't need as much product security as you need GRC. you probably don't need as much security operations at a brickandmortar store as you do loss

prevention people, right? Um, so it's it's going to depend on the way that the work comes into you, but the most important thing that you can do once you've defined these pillars is take the time to write down these are the buckets that I want to put the tasks that people bring to me. And it's a really weird shift because if you've ever worked with with partners that that do service delivery, so if you've ever hired a contracting firm or a staffing firm and you've said, "Hey, I have this problem. Can you just solve it for me?" They have a list of services that they provide. If you want a pentest done, you go to a

pentesting company and they can look on a sheet and say, "All right, I have five people. I can do 12 engagements a year based on this math." And they know that because for the first six months that they did pen testing, they created a ticket for every single task that they had to do about that pen test. And then they measured how long does it take. They measured how long did the customer have to wait and then they were able to take that data and actually understand okay this is how much re this is how many resources we need to provide this capability. that same thing that you'll see the people that you're paying to

manage your EDR the same work that they do you take that internally you say hey how did you decide how many people you needed in order to support our size of company and the the true professionals in that area will be able to explain to you oh well based on whatever it is um this is this is how we arrived at the amount of resources we needed it's it's a really fun nerdy math thing. Um, I think we hit everything there. Oh, my presenter went away. So uh we talked about these things. We talked about measuring them. Uh, the next piece once you've measured them is is reporting them in some way. So, fun fact, uh, this is a, uh, lightly

sanitized document that I wrote a few months ago. Uh, and this is how I decided I was going to grow my team. It's how I decided was I going to hire a product security person before a security operations person or before a GRC person. And the way that I did it was pretty easy. We have Jira. So every time someone asked me to do something, I looked at my list of services that I provided and I added a label. Just the simple act of saying customer request as a label in Jira. At the end of a month, I can look back and say, "Oh, wow. We had 250 questions about our sock 2 last month." Uh, that's

that's a lot. Maybe I need someone to look into that more than I need to have someone look into um I don't know, we'll go with I have this down here. Uh we'll go with secure design. I only did like 10 design reviews that month. I probably want someone to do the GRC work and then I can spend more time on getting people to understand, hey, you should come to me for design reviews. Uh but that that's why we create these metrics. That's why we put those tags together. We build a table like this and then we add some color to it. We don't really have at this phase a good way to say, "Oh, one of these tickets is equal

to one hour of work. There's no way that I'm going to take the time to make sure that I have 50 tickets open for uh for 50 hours worth of work. I'm just not going to do it." And so what I do is in the document I write down whatever my assumptions are. I write down I say we had 26 tickets based on a sample. I'm going to assume that each ticket that I worked took about two hours to complete. I don't have data on that, but at least I know I have 26 tickets and I can approximate that if I hire a new person, uh, they're going to have x amount of hours worth of work to do. Does that

make sense? Okay, cool. that's gone. So anyway, that's that's what I take to the CTO and say I need more people because of when we're living. Uh two years ago, I was working through the same playbook and I spent hours and hours and hours managing Jira and I was reviewing tickets and yelling at people for not putting the right tag on the ticket and all of those things. But because it's 2026, if you have something like clawed code, you can just define what you want your structure to be and then create a skill that creates the ticket, applies the tags, and yells at you whenever a ticket exists that doesn't have the tags. And so it's just

one of those things that used to be so laborous and we didn't do it because it was laborous. It's easy now. You have no excuse not to know how much work you did for each service you provide. You might not know the hours, but there's no excuse why you shouldn't know how many different tasks you did. Does that anybody think like, oh wow, yeah, there's I used to not want to do that, but it's it's easy.

Okay so lots of highle thoughts. I wanted to make time to make this a little bit more interactive. So imagine you just got hired to be the first security person at Novabyte or imagine you're the CTO of Novabyte. Uh give that a read. I'll give you a second and then we'll go from there.

All right. So, you're at Novabet now. You know your job. Who has a question that they want to know about the business based on what we've learned today?

>> Oh, okay. Okay. So, the first question was, is it B2B, B to B to C or B to B to B to B to That's a lot of letters. Yeah. So uh uh let's go with it's it's B2B. Anybody else have a question? Go ahead, sir. >> Oh, what what kind of in inventory? Okay. Uh say a little bit more. >> How proprietary is the inventory? So, you're talking about of the customer. And so the idea here is getting around like are the customers very sensitive to the fact that that we know and we have a copy of how much they have. One more over here >> oh is it pharmaceuticals or farm equipment? Uh in in the Midwest 95% of

chance it's going to be farm equipment. Uh but no e exactly. Uh and so the idea here is to get you thinking about that. Okay. So let's say it's pharmaceuticals. They are very very worried. Uh what's your next step?

>> Say that again. >> Current state assessment. I love it. Okay. And then uh doing the current state assessment. Are you going to do it yourself or what other option do we have? like if >> let me outsource it, right? Can I have $20,000 to get an expert to come in and do the assessment for me? Not only does that take my bias out of the picture because I work here now. And so now I'll get like a ruthless feedback on the way that we are, but but also now I don't have to focus on this thing that anyone with experience can do. I can just read the report and start executing. I probably want to validate some things,

right? It's a third party, but I can do that. All right, we'll move on to the next one. Clear path retail. Okay, hopefully we can find some new CEOs, some new CTOs, some new heads of security in the room. I'll let you read it. All right. Who has a question for the business? >> So, can I show their stuff? So you're you're very close to a question that I was hoping someone would ask. So the the the answer was I'm the first security hire. Uh who was doing? That's not the part you said though. Did you Did you say that part? Who was doing this before? >> Can >> I'm se skeptical. I'm skeptical that

this is the time to hire a security person. So, fun fact, I've showed up to a business before and said, 'Oh my goodness, I can't believe I'm your first hire. And I start doing all of these things in a silo. I start doing the assessment myself. I start interviewing people, not within like the core technology, but outside in the rest of the business to understand what's going on. And I build out this plan for how I'm going to build this great program and how valuable I'm going to be. And why hasn't this company been doing this for the last 5 years? And then I meet with my CTO, very proud of myself for all of this work that I

did, and he's like, "You didn't talk to Jeff?" I Who's Jeff? He's like, "Oh, that's our third party auditor. He's been partnering with us since the very beginning. Uh he's brought in a couple of companies to do these audits. Uh things have been going pretty well. We've got all of these. He should have told you about these tools. You didn't talk to Jeff." And so one of the first questions that we often forget to ask is who's solving this problem for you today? If the answer is nobody, okay, great. But it's entirely possible that somebody else has already done that work. Somebody else already understands what the pain pain points are and all you have to do is ask. So that was it

was that that was what I was looking for. That was the point of this sort of idea. Um, so yeah, and then like the other thing to think about that I wanted to cover here too was we see 12,000 people. If we think 12,000 engineers, product managers, um, marketing people, that's a lot. But if we think Oh, go ahead. >> How many of those are like sales people in >> Exactly. How many of those people are in a retail location? How many of those people are delivery drivers? How many of those people don't te touch technology in their daily basis at all? And so one of the things that we have to rightsize with ourselves uh is what does that

12,000 person number mean exactly?

So we got one more. It's the last example. So, I'm hoping I can get four new CTOs, four new first security hires this time. So, I'll let you get a read of it.

All right. Who's got a question that hasn't asked one yet? All right. In the back >> given that they live almost

>> exactly. So the the the question for the business was you are like 90% you are mostly in the physical world. Why are you hiring me? Why are you not outsourcing? And that question is really hard to ask during an interview. But you know what's worse than going to this interview and and asking a weird question is showing up, doing your best, doing what you think the business needs, and then finding out we don't have the budget for a $2 million security program because we're in the physical world. If all of our computers stop working tomorrow, we'll keep making knives until we buy new computers. And so the thing that we always have to make sure we're

thinking about is am I protecting enough revenue to actually justify this beautiful program that I want to build. There are no bonus points for extra security. Um yeah, I think I think that's a good way to end it. Uh questions? Let me pop to the next slide. There we go. in front. >> How do you make a business case for an emerging risk for a problem? >> This is a great question. The question was, how do you make a business case for an emerging risk or a problem? And so, uh, I worked with a really good CISO, uh, five or six years ago, and the thing that he would always say is data wins arguments.

If we don't have data, use professional judgment. Somewhere in between there, right, is this this idea that we can approximate something else. So a we'll say two years ago AI was brand new. A year ago, nobody had nobody could easily have an AI run their computer. How do you make a business case for protecting the company from that? And you can look back throughout history. When's the last time we had something new? Machine learning, right? Anybody remember whenever every sales pitch that you got was, "We have the world's greatest machine learning algorithm to detect and destroy threats on your network." Did you guys see that commercial? >> Yeah. Last week. Okay. Uh so whenever that started happening and you can see

this in the standards that we've developed as well, uh we took this idea of oh data providence is important. We need to understand that when we're creating these models uh machine learning models that uh our data can't fit weird. We can't just steal our data from somewhere else. We have to license it. Uh I don't want a company to take my data and use to build an ML model and then they get richer off of my data. These are concepts that we saw in the past and we're just applying them to AI. So when hologram technology becomes a thing and all of your speakers are AI holograms, uh we'll probably look back to the research that we did and the the

controls that we put in place for just regular AI uh and apply that there. Any other questions? No, absolutely. So, and the let me go back to this one. So, I think organizational culture shifts how wide each one of those lanes are. And so if it's a I'm trying to avoid saying the word legacy, but I'm imagining all of these companies that build software using Waterfall and like their manager cuts a ticket for every single piece of work that they do. Uh in those worlds, you're probably better off investing more on process improvements. And so that product security engineer, if they're on the side of let's make the waterfall move faster so that this and the

security piece of that smaller, I think that's where that investment goes. If the is it back up? Nope. That's okay. Uh so like in that case, that's what you would be seeing. Uh if if it's a case where culturally the company everyone cares about security and like you get asked questions every single five minutes about can I do that? I'm investing more resources in the evangelism side of things because now people are consuming it. I just need to put out good information. Uh and so that's that's what it changes the thickness of those bars if that makes sense. So thank you. It was a really good question uh in the back and then I'll come to you

in a second. Yeah. How do you combat against a small organization's desire to follow an Amazon? >> So, I think so, a I'm guilty of that. Every single day I show up, I wake up and I say, "God, I really wish people would write five-page PRFAQs because it just makes it so much easier for me to understand what's happening." uh and and the way that I fight with that with myself and then the way that I push back on those sort of big company requirements compared to what we have at the smaller companies. Uh the the way that I handle that is really just thinking about the time that we're investing. And then I also challenge

people on how long is what we have today going to stay that way. Because if we're in hockey stick growth, the the way that even the services that we've built look night and day three months from now. Uh just it's it's going to change. And so the question that I ask people is like, okay, this process that you're building, is it a pet or is it cattle? Because because if it's pet, we'll keep it. We'll give it a name. We'll make sure it's fed. But if this is cattle, if this is something we're going to butcher, it's done. Like let's let's not waste too much time on that right now. That was actually kind of uh my question

was I I uh bas basically like the kind of three stages you had. What if you're at a company that is not looking to grow anymore like just profitable at the like 50 person? >> Yeah. No, I one thing uh are these recorded like going on the internet? We'll find out. So uh we'll find out if anybody watches it. So my my little brother and I uh we he's also into organizational psychology and and one of the the concepts that we joke about and I don't know if this is widespread or just something that he made up but it's palm the point of mediocrity. And so if you're in a phase where you can invest minimal effort to have an

acceptable life you're not going to change. Why why would you change? Uh and so at that point you have to decide am I going to be the person that inspires others to to achieve these great things that I think that we can or um am I going to find a different team to be on? Uh they're both acceptable answers in my opinion. I don't think very many people will say that out loud. But I I think it's okay to be part of a 50 person company that's profitable and you don't have to do much work. Like that's fishing every day is the dream. If you can have it now, why not? Um but then also if if you want to be creating a new

thing that just everyone knows about and that's what drives you, it should be perfectly acceptable to say, hey, you know what? I'm going to keep doing a great job here, but I'm probably going to go somewhere else because I want to be on a on a team full of A players. Um, there's a there's a book by I think it's Simon Synynic that talks about building uh like a player teams. Um, and I can't remember the name right now, but something to read. It's inspiring when you're in that stage. Any other questions? If your

>> So I'm assuming if you've overbuilt then you have budget to overbuild. Uh I like to do a couple of things there. One uh there's and I don't I don't work for them. I don't get money from them. But there's this there's this company called Xan Analytics and what they do is they take actuarial data from cyber insurance companies. So, the same thing that says if you live in Seattle zip code A versus Seattle zip code B, you have higher insurance rates. They take that data, you enter in uh your current risk posture, and so you say, "Oh, I I've met all of these requirements. I'm doing these things, I have these controls, and they output uh a uh an annual loss

expectancy." And so, just like with any other like financial loss, they do that for cyber risk. And so what you can do when you have this giant program, you can sum up the budget and say this is how much money we're spending. This is our annual loss expectancy. Does the investment make sense? And then you can also work backwards from that. So you can say I have control ABC. If I delete controlB, my annual loss expectancy goes up by $1,000, but I pay a million dollars a year for that control. it doesn't make sense to do. Uh, and so that's the way that I like to scale back those types of things. I don't generally want to scale it back

because there's probably some other risk that we would rather shift that to. But if if the right answer is to give the business back money, we should give the business back money so that we can get paid more, right? Any other questions? I probably have time for one more. And if not, okay, thank you so much for coming. Please scan the QR code. Leave feedback.