Scaling A Cybersecurity Business - Example

I did keep up on email, so I monitored email and interjected a few, you know, replies here and there. But, you know, didn't hold any meetings, didn't do any testing, didn't write any reports. That was, that was the team. The team took over for two weeks and there's no way we could have done that without systems in place.

Hey, it's David here from Systemology and System Hub and we are shining a light on business owners that are building systems culture today. I've got Terry Bradley here from milehighcyber.com I'll make sure I put a link right near this interview, but maybe just to start, Terry, if you could introduce yourself, tell us a little bit about what the company does and a little bit about your team.

Yeah, thanks, David. I'm Terry Bradley. I'm president and co founder of Mile High Cyber and we're a small business cybersecurity consulting firm that helps businesses build and improve their cyber security programs. And we do this so they can hopefully avoid painful and expensive cybersecurity incidents which are becoming more and more prevalent these days.

Yeah, it feels like just by the nature of your industry that like systems, it's just going to be part of your world, like is that I know there are different types of systems, there's software systems, and we're talking about systems in the context of process and how to documents. But would you see yourself as a systems person?

Well, I don't think I was until I read your book and saw the value of written procedures and systematizing things in my industry, which is the cybersecurity, specifically offensive cyber security, ethical hacking, penetration testing. I would say there's a great lack of systems. Most of the folks who work in this field are, you know, very talented and they're very creative and they don't want to be constrained by written procedures or test plans. Having led some other penetration testing teams in the past, it wasn't uncommon for us to show up at a customer site, five different hackers, plug into the network and everyone's doing something. And as a manager I wondered, I wonder what they're doing, I wonder how long it's going to take. And, and you know, I was really reluctant to ask because they're like, you know, if you don't know then you shouldn't even be asking. And so, you know, you can imagine that that doesn't always produce a consistent outcome. And so when I started my own company, I wanted to systematize things so that I knew what was happening. I knew if we'd done everything that we were supposed to, and if we didn't get the results that we needed to have, we could go back and figure out why and how to improve.

Yeah, I'm imagining as well, again, not knowing too much about your industry, but it's. I could see a lot of people in the cybersecurity space being the technician that has the entrepreneurial seizure, that's what Michael Gerber calls it, this idea that, you know, the hacker is the technician. And then they think, you know what? I'm going to start a cyber security company. And then they very quickly learn that it's different to run a business versus knowing how to do the thing. So, yeah, I don't know if that kind of speaks to what you're talking about.

Oh, it really resonates with me. In fact, the first book I read was, was Michael Gerber's book. And that led me to ask, how do I, how do I put together a system like you talked about? I really resonated with the, with the hotel example. You know, it was mundane things that they did for their guests, but the fact that, you know, they documented them and they trained that and they instilled that in the culture, I was like, wow, how could we do that for cybersecurity? So I meet all kinds of people who are great hackers and they reason with themselves, man, you know, I can do this on my own and I can go out and, you know, keep all the money for myself. And what they find very quickly is they have no trouble, you know, getting, getting work, but pretty soon they're at capacity, and then how do they replicate that? You know, we always joke you need to clone yourself, but you just can't. And then they're ill equipped to build a business and to build an organization or to train people, and pretty soon they're going back to their, their cubicle and working for the big cyber security consulting firm again. Yeah.

Are there other common challenges that you see in the industry, you know, for cyber security space? It sounds like that, that challenge of, oh, yes, I'm the technician, I know how to do the thing, I'll go do that. And then they find out, no, I'm going to go back and then work for the larger organization. Are there other things that you see that are quite common in your industry based on the fact that a lot of these other cybersecurity systems won't have systems and process in place?

Yeah, I think you, if you read very much about the cybersecurity industry, you'll come across statistics that there's a big lack of skilled workers. And you know, there, there are a lot of skilled workers out there. They're just few in number and they're very expensive. So if you're trying to staff a company or grow a company, it's a very difficult problem to find the people to do it. And creating systems allows you to, number one, train folks who are lesser skilled individuals to get them up to, you know, mid and potentially senior level. And then also it addresses a big problem in cybersecurity, which is knowledge hoarding. You know, if I'm the guy who knows how to do, you know, the greatest hack and I, I get called upon to come in and hack the customer because that's, that's what they want and that's how we demonstrate that they got a good value for your, for their money. There's a lot of reluctance to show other people, you know exactly all the things that you know how to do. Whereas if you're building a systems culture where you document all the tests and all the procedures and all the tools and all those great hacker techniques that you've learned over the years, then it's a lot easier for other people to pick those up. There's less of this knowledge hoarding. And it also allows you, as that highly skilled person to not be completely indispensable to the point where you can't ever take a vacation or, you know, do something different.

Yeah, that. I'd love to dig into that a little bit more around how you've able to work on building that culture. Because if it's, you know, in the hacker culture to want to hoard, and we see this in other industries as well, where people create a little black box around them that nobody really knows what they're doing and then that makes them indispensable to, to the business and then they feel like they've got a level of job security. So I very much get that. And to a certain extent there's probably certain things in the hacking space, like it's a quick moving industry, technology is changing. You're going to have to be quite creative to think up different solutions and things like that. So I'm wondering how you've fostered that culture and what sort of resistance, if any, you've had with your team members as they come on board.

Yeah, it's, it's a great question. You know, initially when I, when I got the glimpse of, of what we could be doing with systems, I asked myself, how do I get people to buy into this.

Yeah.

And so the technique that I used was to bring a consultant in, a systemology consultant who sort of allowed me to distance myself from this bright idea that I had. And he came in and talked about all the benefits and, and you know, then I'm able to kind of play off of that and it gave me some distance so that I wasn't, you know, it was like all or nothing. You know, it's going to be catastrophic failure if people don't buy in. But he did a good job of selling some of the benefits. And then I reinforced that by incentivizing people with bonuses and objectives in their performance reviews to adopt and help us build all the systems that we had to build. And then I would also say there was some resistance that, you know, if you know how to do something, there's a little bit of reluctance to, to document that because it's, it's a lot of work. And you know, recording videos for step by step instructions in some case is cumbersome. But, you know, I would say we've made incremental progress and people knew that this was what we were going to do and you know, they had to get on board eventually. Or I think maybe it was one of the other books I was reading. Some people self select out of that system. And so I don't mean to sound harsh and say it's my way or the highway, but we just made systems a priority for all the benefits. Not because I had some particular bent towards them. I definitely had never done this in my past. But once we demonstrated to them that, you know, this was going to not only benefit the business, but benefit you as a person so that you will not be the single point of failure on these projects and you'll be able to take a vacation and we won't bug you while you're gone, I think people began to realize, okay, we can do this. And we were fairly realistic in terms of not getting it done overnight. It took us probably nine months to document the systems that we knew about. And then we're constantly discovering new things that we need to create systems for that we didn't even think about. We embarked on the. On the journey.

Definitely sounds like you're on a bit of a journey and you've read some books. How did you come across Systemology? Because you mentioned the E Myth and. Yeah, was it. Did someone refer it or did you happen to find it on Amazon or a YouTube video?

Yeah, well, I'd read the E. Myth. That was the first book that kind of got me thinking in this direction. And there was a individual in a networking group that I was with that was a systemology consultant and he graciously gave me a copy of Systemology. Yeah. Yeah, cool. He knew exactly what he was doing. And once I'd read that, I'm like, yeah, we, we could really use your help to implement this.

Oh, good. And did you. One of the things we talk about, I'm finding it more and more as such critical difference between those that make it work and those that don't is the idea of getting a systems champion or nominating someone inside the team. Is that a path that you went?

Yes, but we're pretty early on that just, just at this point we do have someone who's been designated as a systems champion and that's been based upon his motivation level to create new systems and to edit systems that, you know, have deficiencies. And so after a period of time, you know, I kind of looked around and said, who's the most likely person to do this? Because I don't think the business owner can really take that role on. Yeah, actually I assigned it to a person that I thought had excess capacity, but I found in time that they, they really didn't have a heart for it. I mean, they were willing to follow systems, but they were not really the person who was going to drive and push it. And so after a period of, of reflection and watching to see who was doing what, identified the person who was the best candidate and they, they, they've taken that on. But really only in the last month or so. Yes.

Yeah. As you kind of gone through this, I know in your industry in particular, things move quickly and I'm curious to know how you tackled the challenge of, you know, are we going to document systems that are going to very quickly become out of date? Like what's your thinking around how you're documenting process to handle fast moving components in your business?

Yeah. You know, in the cybersecurity industry and especially in the, in the security testing realm where we operate, a lot of the things that we do, the tests that we run, they don't ever become obsolete, they become less and less relevant. But you know, we run into customers who have ancient equipment and so we have to maintain those tests that look for those old vulnerabilities, those old security flaws, while constantly adding new tests. So really systemology is the only way I think you can do it effectively, you know, to, to document those procedures, to keep all the old ones. And then when you run across that ancient, you know, Windows NT or Windows 2000 server, you know, without having documented the tests that you used to do 10 years ago, you might just scratch your head. Or if you're, you know, some person is new to the field, you'd say, I've never seen, you know, Windows XP before. And you're like, oh yeah, we've got some tests in our bank of systems that we can run on that. And it's, this is going to be a fun day for the hackers.

Yes. Yeah. And I find the more companies we work with, sometimes it just requires a change of thinking and a slightly different frame. But I think where it would be easy for someone in your industry before they went down this rabbit hole to say, ah, systems won't work for me because all of this technology is always changing. Sometimes it's just this belief that hold. And then when they actually test that assumption, they realize that it's not true because it, from what it sounds like for you in this example, it's accumulation of knowledge. Like, this is a iterative process. You're never going to be done when it comes to creating new systems. It's just part of the culture now. And as new things come on board, technologies change. You're just adding to this knowledge base of like the business intelligence. Is that, you know, my assessment correct?

Yeah. I think there's a fear probably among some of the more skilled security testers that if, if we document everything with written procedures and systems that I'm, I'm going to be locked in, it's going to somehow, you know, stifle my creativity. But really what it does, it just ensures you have a strong foundation. One of the things that we use a lot in penetration testing, ethical hacking, are mind maps. And, you know, those are nice. They're graphical representations of different decision paths you could take or different tests you might run. But they're not really what I would consider robust systems. I can, you know, say I use the mind map. But after the fact, no one can say, well, you know, did you do this? Did you do that? Without having to ask me. And then I'm like, I'm not really sure, I'm not sure I remember. Whereas if we have a good task management system that's based upon written procedures, we can tick off all those boxes and say, yeah, we did every single one of those tests and we know we did them this particular way and we've got the output from each one of those tests because we've systematized it. And then if you think of something new that you know, well, what if we did this and it turns out that that was successful, then that's, that's the chance where I say, hey, write a system on that. You know, we're going to add that to our bag of tricks and we're going to use this on every project going forward where, where it's applicable.

It almost reminds me of the automotive industry to a certain extent. You take your car in for a service and before they really get into, you know, maybe uncovering your unique issue, they'll run through the 50 point checklist to do the first basic part of the service, which then helps to uncover something. And I think you touched on something earlier that I thought was very astute was this idea of, you know, you mentioned about the systems helping the less skilled team member so you could effectively have newer, less skilled team members run through that checklist first that we're talking about that may or may not resolve the issue for the client. And if it doesn't, then you can escalate to the more senior team member who now knows, well, hey, we've got all the base testing done. I can now move on to, you know, utilizing my highest level knowledge.

Yeah, absolutely, that's, that's a really, really great point. We see that a lot with, you know, a lot of security flaws that get discovered during security testing are really just, they're almost blindingly obvious. They're, you know, systems without a password. They're systems where the, the password is admin. And you know, we can have the junior people KN out and you know, from a cost perspective, their labor hours are much cheaper than those, you know, seasoned certified, you know, multi generational hacker type people. And so we can have the junior folks knock out some of the basic tests. And then when, you know, they've exhausted all of things that they know how to do and we've run through all the systems, then we can call in that seasoned hacker to say, okay, what else can we come up with? You know, how can we crack this, crack this case? And on the flip side too, you know, a lot of times some of these senior penetration testers, senior hackers, they're the ones who try admin, admin on the web server and get in. And you know, everyone says, well, of course they got in there. You know, they've been doing hacking for 20 years. But when that junior person gets in for their first time with username admin and password of admin, they get super excited. They're like, I did this, like I hacked that system. And you know, and the reality is most of the security incidents, security breaches that happen, they're the root cause is some really stupid mistake. And the security testing that we do, you know, helps uncover those stupid mistakes that people sometimes make because they're in a hurry.

Yeah. Now that you're a little bit further down the path and you look at back to where the company was before you really embraced systems, is there anything that you either wish you knew earlier or things that you've learned along the way or insights, tips, Just I don't know if anything comes to mind where you're just like, oh, that would have been helpful to know earlier.

Yeah. I think when we first before I really understood what, what I was doing, I knew that we had to have better way of keeping track of who was doing what if we were going to build a team that could scale. And so initially I tried to do things on the cheap in terms of software systems. You know, Microsoft Teams has this feature called planner and can make these to do cards. And that was a great place to start, you know, because it was free, you know, it was built into Office365 at the time. And I thought, well, this is what we're going to use. And very quickly I found out it had a lot of limitations that were going to impact our performance on projects. And so I very quickly jumped up to a much more robust task management system. And at the same time we were implementing System Hub for our written procedures. And so I would say, you know, early mistake would be to try to skimp on the platforms that you use to manage your tasks and to document your systems. You need to invest that money, otherwise you're going to have to recreate it all in a better system down the road. Because with the basic systems that were sort of on the cheap, we couldn't do a lot of things that are really beneficial in terms of exporting tasks, collecting evidence, collecting metrics on who's doing what and how much. Custom fields that you, you didn't ever think of needing until you needed them and then you find out that this basic cheap system doesn't allow you to do all those things. Templating, that was a big one too. We could templates and once we were able to create a template for different kinds of projects, that made us much more effective and consistent in our client delivery. Yes.

Yeah. I think it also sends a very clear message to the team that systems in process and having a structured way of doing things is important here. I know sometimes if, you know, it's, it's sitting off in a Google Drive somewhere or it's really clunky or it's teams and things aren't quite connecting together. It, it doesn't send the right message to the team. Like I'm a big believer that systems and processes are the most important asset. And I know I'm a little bit biased and there's a case to argue that it would be the team as well. But I still feel like with, you know, you do need both, but the team members will come and go and it's the systems that will remain with you as business owner and it's that knowledge source. So anything that you can do which streamlines the efficiency of accessing it and showcasing to the team that this is important and pooling that knowledge is important for building that right culture. So yeah, look, I've absolutely like, I love hearing these stories and I don't know, maybe in the tail end if you've got any particular stories or things that have happened along the way, now that you're building this culture where you've had some wins or if something's gone on in your business that you might be able to share.

Yeah, well, a couple that I wrote down thinking about that before this call, probably the most immediate one that's very relevant to me personally was this past couple of weeks I was able to take my first vacation as a business owner. So three years in business and yeah, my wife and I literally didn't have to work now because, you know, this is our first time and it was a little nerve wracking. I, I did keep up on email so I, I monitored email and interjected a few, you know, replies here and there. But you know, didn't hold any meetings, didn't do any testing, didn't write any reports. That was, that was the team. The team took over for two weeks and there's no way we could have done that without systems in place. Congratulations. Like that.

Some people, that takes 10 years or more. Like I've seen business owners get trapped in that spot for longer than you realize. So to be able to do that in three years, like first years are always the hardest is the most work. So yeah, big hats off to you for that one.

Yeah, well, it was very, it's very personally enjoyable too. The other thing I want to say is, you know, one of the ways that we've differentiated ourselves as a business is by not going out and buying, buying a whole bunch of expensive hacker talent we've built primarily with, with more junior folks. And that means that we have to take some risks on projects we're not always going to get the outcome that we want because you know, these folks are not seasoned, experienced veterans. Having the systems in place allows us to have a really non confrontational way to address unexpected outcomes. You know, if we don't get the outcome that we're expecting, you know, there would be a tendency, I think as a, as a business owner to say, you there, what, what were you thinking? Why did you do that? And it probably would be extremely threatening, especially to junior staff who are like, you know, I'm new at this, I'm just, I'm doing my best. You know, why, why do you have to be so critical? Whereas with the systems in place, from a team perspective, we can say, hey, let's, let's do a debrief on this project, let's talk about what went well, what, and, and why some of these things didn't work the way we expected and we can always put that on the system. You know, if there's a bad outcome or a something didn't happen the way it was supposed to, I always say, let's look at the system. And so immediately we're going to blame the system. And I would say about 50% of the time it's because the system wasn't clear, the person followed the system and it just, you know, I thought it was clear, you know, I might have written it myself. And as a business owner, I can say, you know, sorry about that. I can see what, why you did what you did and we're going to fix the system and it's going to be better next time. And then maybe the other 50% of the time the person didn't follow the system or they skipped a step and we can say, hey, you know, just make sure you follow it step by step until you have it down by heart. And, but you know, probably it's better off to follow it step by step even after you do have it down by heart. Because we're constantly updating these systems, we're improving them, we're making things more clear, we're adding additional steps that we find would be beneficial over time. But I would say in terms of training and building a staff, it's been very beneficial to not, you know, hurt people's feelings when you have to fix problems.

Yes, yeah, yeah, I, I can see you've adjusted the DNA of your business. I can hear it in the way that you manage the staff, the way that you're deploying out the technology, the way that you're leading it, even the way that you're thinking about how you can grow the business using these junior team members, which ultimately gives you a competitive advantage, enables you to operate more cost effectively, which then gives you a bigger margin for error, which means as a small business, you can start to grow. So, yeah, I appreciate you so much for sharing the story today. I know someone's going to watch this and get inspired. I'm going to point them over to milehighcyber.com so if they've got any security concerns or want to chat with the systems driven security security company, you guys are the ones to chat with. Is there any final things you'd like to leave us with?

No, I just really appreciate the opportunity and it's really great to meet you, I guess somewhat in person and yeah, I would just encourage people to, you know, to start on their journey, start small and then, you know, build over time. It's going to take a while and you know, you've got to try to figure out how to get the buy in with, with your team. But I, I think it's definitely worth it. Perfect.

Thanks for that, Terry.