Defining Your Consultancy Niche Part 2 with Scott Piper

Scott Piper is an AWS security consultant at Summit Route, a company he founded in 2017. He’s also the developer of flaws.cloud and an organizer for the virtual fwd:cloudsec conference. Scott brings 15 years of tech experience to his current position, having worked as director of security at a cybersecurity company, a security engineer at Yelp, and a software engineer at the NSA, among other positions.

Join Corey and Scott as they talk about why Scott decided to start an AWS security consultancy, what it was like for Scott to quit his job only to find out the people he thought needed his services wanted him to work for free, how Scott came around to building CloudMapper and CloudTracker, what both of those tools do, why it’s important to define what kind of consultant you are going to be and find your niche, the psychological aspect of running your own business, and more.

Show Notes

Links Referenced: 

• Company website: http://summitroute.com
• flaws.cloud: http://flaws.cloud
• fwd:cloudsec: https://fwdcloudsec.org/
• Twitter: https://twitter.com/0xdabbad00 

What is Screaming in the Cloud?

Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.

Transcript
This episode is sponsored by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.

Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if wanting new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of Cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by returning guest, Scott Piper, who is an independent consultant focusing on helping companies secure their AWS environments. Or as I like to think of it: railing against the tide. Scott, welcome back.

Scott: Thank you. Thanks for having me again.

Corey: So, you do an awful lot of stuff in the AWS security space. summitroute.com has become a mainstay of folks who want to have conversations about security. You run flaws.cloud, you're the organizer behind fwd:cloudsec. It's named after an email subject line, as all cloud conferences should be. And that's great.

But today, what I want to talk about is something near and dear to my heart, where you decided to set out and carve yourself a niche as a one-person band in the AWS space. For those who aren't familiar with my backstory, I did something very similar around AWS bills, then I took on Mike Julian, my business partner, two years ago and now we're 10 people. So, I sort of let the thing run away from me, you have kept it a single person operation, and I must confess there are times I'm deeply envious.

Scott: And I am envious of your position as well. The grass is always greener somewhere else.

Corey: It really is, usually because it's fertilized with crap. So, what were you doing before you decided, “You know what, I should be an AWS security person because that seems like the direction to go in.”

Scott: Yeah, so I talked a little bit about it in the last episode that I did with you where I was running security for a company, and I really didn't know a lot about AWS at the time, and specifically AWS security. I was supposed to be in charge of that for our company; I didn't know much about it. I tried looking around to try and identify who was a consultant that I could reach out to, to try and get them to assess our environment or to help me out in some way. And I wasn't able to find anybody. So, I knew there was demand because I wanted it, and I knew that there was no supply because I couldn't find anybody to do it.

So, I knew that that was an opportunity in and of itself. The other thing was, while I was at that job, I released flaws.cloud, which we talked about in the last episode, which is this online CTF. And as a result of that, I started to get a lot of emails from people saying, “Hey, you're the AWS expert. Can you help me out with a thing?” And I was like, “I’m the AWS expert—you know, AWS security expert?” Like, “Uh, okay. Yes. Yes, I am the expert, I mean.”

And so as a result of that I knew that other people were interested in this as well. And so again, I knew that there was an opportunity for this. And so the other big thing was that a meetup group had asked me to talk at one of their upcoming get-togethers, and they were based in another city and I emailed them, said, “Hey, that would be great. However, I'm in—” at the time I was in Denver, and they were in Chicago, and I said, “I would love to, but unfortunately it just doesn't really make sense for me to fly out there, buy a plane ticket, get a hotel room and everything, in order to talk at your Meetup group,” and they're like, “Well, we'll pay you for this.” You know, I wasn't going to profit off of this, but they were willing to pay for the flight and hotel.

And so someone that has never met me before was willing to write me a check for just a few hundred dollars; like, it was probably going to be $300 or less, but they were willing to write me that check. And so I knew there's an opportunity for this. And so as a result of that, I really just, kind of, dove in; one day just kind of announced it to people and said, “Hey, I'm an AWS security consultant. I am ready for business.” And unfortunately, emailed all the people that had emailed me previously when I was working for the startup.

And at the time, I had emailed all of them and said, “Hey, I can't help you. I'm super busy with a startup.” But then I emailed them now after I'd quit, and I said, “Hey, I can help you out.” And they're like, “Oh, we didn't know you want money for this, I thought that maybe you could just help us for free.”

Corey: “I thought you were volunteering for us?” Why not? It's one of those things like at some point if enough people ask you to do the thing you do for free, it's like, do I just look like a sucker is what you start wondering.

Scott: Exactly. So, I immediately started freaking out. Oh, I just quit my job and now I do not have any opportunities for income. What on earth am I doing? This is horrible.

But I ended up being really lucky because I had previously, years prior to this, I had interviewed at a company Duo Security and had basically interviewed for a position with them, and everything was going great, but they wanted me to move out to Ann Arbor, Michigan. And at the time, I was not interested in that. I looked at a map of America and where there's mountains, and there's not a lot of mountains around Detroit, and around Ann Arbor, Michigan. And so I was not interested in that. I want to be by the mountains where I can go hiking, and do those types of activities.

And so I said, “Hey, let's keep in touch. I'd love to work with you in the future at some point, but this is not going to work right now.” And so then when I decided to announce that I was a consultant, the opportunity arose where they said, “Hey, you can do some remote work for us, now.” And now they allow remote work and everything. And so, that was my first client was Duo Security, and giving me that opportunity to try and basically start doing things. So, yes, I mean, that was really how I got my head start on things.

Corey: There's something to be said, for having set yourself up as a consultant in that—when I've been trying to grab people in to do things, like content writing and whatnot, it turns out it's a colossal pain in the butt to pay someone who's not situated as something of a business entity. Whereas when it’s, “Oh, yeah. Here's a thing you can pay with a credit card,” or, “Here's my W-9 for whatever you need,” and just, “Here's how you wire money,” it becomes easier to throw money at folks on a certain level. And of course, depending on the customer, the requirements on that change significantly, where it's going through vendor assessments, which for what I do with billing is always a treasure and a joy. It's folks who don't realize that, yeah, maybe your one size fits all form doesn't fit me super well because I will not be getting $10 million of commercial vehicle insurance because we have no commercial vehicles; we need to buy one first.

And it goes through this one size fits, basically, nobody process. It's annoying, but it works. And we've gotten those down to a science. But as an independent practitioner, that was the biggest pain. I'm mostly biased for not doing extensive work with companies that had that level of requirement. Now, of course, we have 10 people, we can dispatch people to fill out those forms. But at the time, it was aligned with me not wanting to do all that extra work.

Scott: And I think that type of thing scares a lot of people away from trying to become a consultant in some way, and following this, kind of, independent consultant path. But what I have found is they're making a request to you, and like if you were to try and scope out the engagement that you had with them, you're going to have some back and forth about the engagement, where they're going to want a certain pricing, maybe, and you're going to haggle over that, and various things like that. And similarly, when it comes to some of those requirements that they may have, in terms of how much insurance you should have, or various policies that you should have in place, you can just tell them, “Hey, I only have this much business insurance, so if you want to do this engagement or not, you're going to have to change your contract with me to basically specify that I only need this amount of insurance, which happens to be the number that I'm telling you is how much I have.” So, you can do those types of things. Furthermore, a lot of clients that I found is they potentially are frustrated with some of their other vendors, especially some of the larger vendors in different ways and they know that I can be flexible in different ways.

And so as a result, they tend to help coach me to some degree or help me in different ways. They want this done and they recognize that my skills and ability are in this technical area, are in AWS security; my skills and ability are not in how to invoice them, or how to write a statement of work or other type of contract. And so I've been very lucky that a number of these clients are helping me to accomplish those things, to write up those documents and do things like that. So, that I think is important that people recognize that your good clients are going to try and work with you to make these successes happen. Furthermore, I mean, they'll find their own loopholes in their own situations, and so I have—for various clients for various reasons—I have subcontracted under existing vendors that they have where that vendor just takes a cut of however much I'm charging to the client. I have in one situation worked as a proper W-2 employee for a client with the understanding that I would quit after two weeks or something like that. Just ridiculous things where there's just loopholes in their own systems that—

Corey: We do the things we have to do to meet our customers where they are. Are you writing any code for your clients?

Scott: So, yeah, so I have done that. That was part of what I did with Duo Security. And so with the initial engagement, I was doing various other things for them, but then as that engagement was winding down, I told them that I was looking to make sure that—you know, I worked for other clients, they were super happy with me, they would have continued on with that contract, however, I personally wanted to end it so that I could make sure that I saw other environments. I wanted to be a consultant for a number of clients. And so I told them that I was going to be ending things.

They said, “Do you have plans lined up? Do you have a new customer or anything?” And I told them, “Look it, I don't really have plans for that yet, but I know that I want to build some tools. I want to make a tool that helps me visualize AWS environments. I want to make a tool that can help me better improve lease privileges and environments. Those tools didn't exist, I wanted to create them.” And they said, “Those sounds awesome. How about if we pay you to build those tools?”

And they will have them associated with their name and brand, and they will also help build me up by allowing me to you have a blog post on their company site that mentions me as an independent AWS security consultant. And so I'm able to take advantage of their audience that they have. And yeah, at the end of the day, I get paid for building a tool that I was about to build for free. And so as a result, CloudMapper and CloudTracker were the first two tools that I built for Duo Security.

Corey: And I've used them both, and love them.

Scott: Yeah. And it's been interesting, too because—so CloudMapper does network visualizations. And unfortunately, that no longer is something that I really maintain in that project because I built it, and that was the first time that I’d tried to do anything like that, that I'd seen anything like that. And unfortunately, visualizing the proof of concept and demo environments that I was running it in when I was building it, they looked great. If I have five nodes in an environment, it looks fantastic.

When you run it in a real environment with 10,000 EC2s or some other ridiculous number, it just becomes a massive hairball. There's just this absolute insanity, you're not able to make any sense of it. But CloudMapper does have a lot of other functionality in it now. And so it's able to audit people's environments; it's able to generate this web of trust to show you the trust relationships between different AWS accounts. And so it has all this other functionality, and that other functionality really came about as a result of working with follow-on clients who they needed certain types of tasks done in their environment; the easiest way for me to do those tasks was to build a tool to automate that process for myself, and those clients, for whatever reason, they don't want to be publicly associated with it, going through trying to open-source a tool is a difficult process for them, and so I ask them, “Hey, is it cool if I just put this into the existing CloudMapper project and just add that as just additional functionality into that tool,” and they've been fine with it.

So, as a result, CloudMapper has expanded over time, largely as a result of follow-on contracts that I've had with other clients that have been willing to pay me to do certain types of activities for them, which then benefited those open-source tools.

Corey: I think there's a huge value to doing stuff like that. I got out of anything that resembled implementation pretty early on because I found that when I was doing the advisory thing, it was extremely repeatable. Sure, you learn something new from every account, but it's something of a bounded problem space, at least on the costing side. And I can scale to give advice a lot more than I can scale to do actual code. And plus, when I find that I'm writing code for a customer and doing any implementation stuff, I'm suddenly beholden to their release timelines. And that is a great way to basically lose margin on the deal if you do what I do, and don't bill by the hour or by the day. So, it comes down to just having a good answer there.

Scott: So, I think it's important that when you are defining what you're doing for consulting, is that you make the decision up front: do you want to have long term engagements with clients where you have these repeated follow-on contracts, or they essentially have you on retainer—

Corey: Recurring revenue has things to recommend it.

Scott: Yeah. Or do you want to have engagements, which is what I do, where I love my clients that I've had, but I do not want to be in a position where they have to call me in the middle of the night; I don't want to be in a position where—like, some consulting businesses, their model is basically what's sometimes referred to as ‘land and expand.’ You get involved with the client, you do some type of work for them, and you have to constantly maintain it. And so as a result, you've basically infected that client. And you are constantly having to do repeat business with that client.

And so I say, this as a very negative thing, but it can be a legitimate business strategy and done in a good and ethical way. However, that's not the business that I want to do. I want to do short term engagements for clients, where I am doing an assessment for them; I am training their team; I'm doing something along the lines where there is a fixed end date for this contract, and I have delivered value and can walk away from it entirely.

Corey: Oh, yeah, I assume people are going to hate me by the end of the project, once they've seen my code and realize that I'm a giant fraud. So, yeah, I want to make sure that check is cleared at that point, by the time I hand anything over and oh, they're never going to let me back in the building.

Scott: Yep. And so yeah, so I mean, like, the code that I've written has been an additional thing that they can use. CloudMapper is this open-source tool that exists in isolation, that they can run on their own whenever they want. It is not incorporated into their existing applications and things like that. So, I don't have to worry about, am I writing it in the correct programming language? And does it work with the correct operating system or anything else in their environment? It is able to work in isolation. So, again, I think that that is important, as you're defining the engagements that you do, is you define how you want to do those engagements. Is there going to be a set end date? I know you've talked about in the past of having fixed-fee contracts, where you're specifying, I am going to deliver this type of value for this money, and we're not really going to talk about how long that's going to take, or—

Corey: That is the only way we operate, from a consulting basis. I take that back. We also have retainer agreements, where we will manage company’s cloud spend for them on an ongoing basis. But our optimization projects are—yeah, absolutely. We are pretty good at estimating how long it will take based upon a variety of different factors, and we are highly capable of turning that into a repeatable, scalable engagement.

And again, people are like, “Oh, so when are you going to just turn this into software?” Well, first, we turned some power tools into it and called it DuckTools, but the honest answer here is that I don't believe that software does this all on its own. At a certain point, there needs to be business insight. Otherwise, you're just doing things that don't make sense for the company.

Scott: Exactly. And I have talked with companies previously, where they've been interested in doing an assessment. I told them, “Look, I'm super busy with other clients. I can't really help you right now.” They're like, “But we really want an assessment. What is the bare minimum you could do for us?” And I’d say, “Look, I could run, like, CloudMappers auditing in your environment, but you could do it as well.”

But they will pay you for those types of things because they know that when I run it in their environment, I'm not just going to basically copy and paste those results into a report and throw it over the wall, I'm going to explain to them why these different issues are problematic. What is the different severity of those issues based on some things I know about their environment? You bring in some of that human capability to it. And that is the value that you're delivering is being able to tell them why and how, and what are the potential limitations or gotchas of trying to fix these different problems that you're pointing out to them. Because a lot of my clients, they are running vendor solutions in their environment that potentially have told them about different issues; they have generated alerts and alarms and things like that, but the client may just not know how to respond to some of those issues.

And so, that is where you're bringing the human element to coach them on how to actually fix those issues, or how severe is that issue? If the thing is telling you that you do not have something that's encrypted, a lot of the encryption in the cloud may not make that much sense.

Corey: Encrypted at rest on disk, why? That makes sense in a data center or your laptop, for example. Someone's going to take that away from you. But what is the threat model you're really guarding against? That they don't dispose of drives properly? Yeah, good luck.

Scott: Exactly. And on top of that, you will have those types of issues along with you have a public S3 bucket with all of your customer credit card information in it. That is a much higher severity issue to fix than whether or not some EBS volume is encrypted or something like that.

Corey: Oh, absolutely. But at the same time, it's also way better to wind up just checking the box if it's easy to do and doesn't really come at a cost or performance penalty than arguing with your auditor all afternoon.

Scott: Exactly.

Corey: So, it's smile, nod, pick your battles.

Scott: Yep.

Corey: I dabbled briefly when I was consulting with an infosec project or two, or I did assessments—you know, picture the really crappy version of what you do and you're sort of there. And it turns out that the talking points you develop for specific offerings, with specific tools, and specific parts problems sound like crap if you try to pivot it. For example, on the cost side, I am not partnered with any vendor in this space, even AWS, so there's no perceived conflict of interest. When I say, “I’m not partnered with any vendor in this space, even the cloud provider, and now I'm going to look at your security.” It's, “Are you simple? Why wouldn't you partner with people? You’re claiming you can do it all yourself?” The thing that serves as a selling point serves as a giant screaming red flag in a different niche.

Scott: Yeah, it can. I mean, I'm similar. I don't partner with any vendors in any way, and so as a result, there are some customers that don't make sense for me to do engagements for because they are very aligned with various partners. And they have a certain philosophy on how to do security, that is going to leverage different vendor solutions. And as a result, yeah, those customers are not going to make sense.

So, again, I think that that is important is trying to define that niche. And I don't know if we made this point specifically, but I want to make sure people are aware of it is that you do have to define what it is that you do, and to narrow your scope, and to not broaden that, even if a customer is potentially going to write you a check that maybe sounds enticing in some way, if you are broadening the scope of the things that you can do and it's going to weaken your ability to be an expert in a specific area because as you try to broaden that—for me, for example, I only do AWS security. If I was to try and cover Azure, and GCP, and potentially some of the other cloud environments, it's way too much. I'm not capable of doing that. If there's somebody else that is able to follow all those things, good for them, but I'm not that person.

I have to focus solely on AWS. And by doing that, by defining that niche, it's not only in terms of technically being able to follow these things, but it's also the relationships that you have. You're able to reach out to, potentially, people at AWS or potentially people at other companies that work heavily with AWS in order to get questions answered. You're able to sell yourself to customers because if you are just a generalist if you are able to say, “I am a programmer,” that's not helpful. If you're a technical person that's not helpful.

You need to narrowly define that niche and that is going to motivate people to reach out to you. Because all of my business is all inbound: it is all people reaching out to me saying, “Hey, can you help me with a thing?” And I say yes or no to all that. I'm not cold-calling people. I don't want to do that. And it's because I've narrowly defined that niche. When someone wants someone that can help with AWS security, I'm going to be probably on that list of people that are recommended to them.

Corey: Absolutely. It's about, basically, rising to the top of the mental SEO for whatever expensive problem it is that you solve. And I backed into my current positioning, where I had engineering skills, I’d done a lot of systems engineering, systems architect, solutions architect, style work, and it was okay, well, that's a skill set I can bring, what expensive problem can I align that with? Because the broader you go, the harder it is to wind up differentiating yourself. “Oh, I do AWS cloud architecture.”

Yeah, now I'm competing against Deloitte and Accenture. And yeah, they're Deloitte, but I'm Deliotte-ful. And [00:23:20 unintelligible] management consultancy side of it. Now I'm calling myself McQuinnzie and getting sued for it. But it becomes harder to differentiate.

Narrowing it down is the better approach. If I weren't as noisy as I am, I could have kept going. All right, I fix the horrifying AWS bill—which is what I do now—for SaaS companies in the Bay Area. Like at some point, it narrows it down so much that someone hears what you do and pops up with, “That's me.” What I try and do is look for the Rolodex moment where, when I describe what I do, I get basically three answers. One is, “What's that mean?” Cool. The other is, “Oh okay, that that sounds super useful.” But the one that really makes this work is, “Oh my God, I know someone you need to speak to.”

Scott: Yep, exactly. Yeah. And I think also, a lot of people don't recognize that they think that starting your own consulting business like this is a very scary thing that's very high risk. And to some degree, it's much less risk than being an employee for a company. And part of that is because if you were able to get this diversity of clients in different industries, or different geolocations or something like that, that it becomes a lot less risky because, for example, when this pandemic hit, that was a big hit on my business, I was very scared about it.

However, I had some clients in certain industries that suddenly were flush with cash, more or less, and were able to say, “Hey, we've always wanted to have some of this stuff done. We now have the money to do it, can you help us out?” And so I'm able to survive throughout the pandemic because of this. And I recognize that I'm very lucky as are potentially many of your listeners that you work in the Cloud industry in some way, and this is a job that you can do remotely, that you can do working from home, which is the best possible situation under a pandemic situation like this. But I do think it's important that people realize that it really isn't quite as risky going out on your own and starting a consulting business like this as they may think otherwise.

Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.

Corey: Absolutely. I think that's also something people lose sight of massively, to their own detriment, where when I talk to people about, “Oh, become an independent consultant—” again, my business partner back before we were partners, we were friends, and we were each other's first clients. And when he set out on his own to originally focus on application performance monitoring, it was, “Well, Mike, that sounds super risky. What are you doing?” And he made the various stupid observation that, yeah, I was an employee at the time and my core competency was pissing people off.

How many people would I have to piss off to wind up having a surprise meeting with HR in which they don't offer you coffee—that's the tell by the way—and not having any income anymore, versus a diversified business where I have multiple consulting clients. We've long since passed a point where no one company is more than 20 percent of revenue is what we have to attest to on some of the forms. In practice, I think our largest customer is far less than that because we are diversified. It's like, at this point, who would I have to upset in order to not have a viable business anymore? Pretty much everyone. And I'm not saying I can't do that, but I have to work for it now. It is counter-intuitively less risky than traditional employment.

Scott: Exactly. Yep.

Corey: Now, there are things that I absolutely found changed once I started taking on, first a partner, and then staff, where I maintain the hardest part of all of it, bar none—at the beginning, it was hard, now it's worse—is managing my own psychology.

Scott: Yes, [laugh].

Corey: It's lonely, especially when you're dealing with NDA’d stuff, and you can't talk with other people about it. When you have staff, you also can't complain down to your staff, you can only really complain to your peers, and when you own the company, it's hard to find. But the thing that really sticks with me is it’s sort of a blow to your ego when you start hiring people like we did, to do sales and to do cloud economics, and every person I hired was better at the thing I hired them to do than I was. And it was incredibly humbling, and it's awesome. I mean, then there's also the getting past the old protestant work ethic approach of, “Oh, if I'm not busy and doing these things and suddenly I'm handing all of this to someone else, oh, no, that means I might get fired.” Yeah, that doesn't apply anymore. And in fact, in most reasonable companies, it doesn't apply. It's, “Oh, you've automated or delegated something else. Great. Now you can get promoted, or go work on something that adds more value.”

Scott: Yeah, and I have not expanded beyond myself yet, but the psychological aspect of having your own business is a very scary thing at times. And you constantly run into kind of an imposter syndrome as you're trying to define yourself as this expert in this niche. Because no matter what, there's going to be someone that has narrowly defined a niche that is smaller than yours that is within your niche, and they are much more of an expert in that narrowly defined niche than you are.

Corey: Oh yeah, I found experts who can go up one side and down the other on spot instance pricing way better than I can. Good for them. I mean, that is super valuable, and I tag them in from time to time. I talked to Alex DeBrie from time to time on DynamoDB specific stuff because he's amazing. And I have no problem reaching out to folks who are domain-specific experts. It turns out that there's plenty of pie to go around.

Scott: And I mean, you really realize, knowledge is fractal in the sense that if you imagine those fractal images, where you zoom in and becomes more and more complex, and you keep zooming in and just keeps becoming more complex. And you have that same situation, with these niches that we've defined. Even though I focus on AWS security, there are all these other branches and smaller niches within that, whether it is technical niches, for example, if you're focused on IAM policies, or you're focused on networking related things. But then there's also niches that end up being defined based on your use cases, and the industries people work in.

And so there's all these different ways in which that can play out such that you do get very scared sometimes, “Oh, I really don't know anything about this thing, and I'm talking to this person who's asking me these questions, and I can clearly tell by how they're asking them, they know way more than I do.” But at the end of the day, you hopefully have some expertise across the board in that niche such that even though they're an expert in an area of that niche, that you still have some value you can bring to the table in other areas of it.

Corey: Oh, absolutely. For me, another hard part of bringing staff on was the—again, if I wind up completely crashing and burning when I was starting out—and that was a very real possibility. I didn't know what I was doing; I still don’t, but I've convinced enough people that I do, so great. But my entire marketing stick was more or less aggressively shitposting about Cloud on Twitter. And that's fine when it's me, but if I get a wrong take and become, effectively, unemployable industry-wide, then suddenly it's not just me anymore.

I've impacted the livelihoods of people who were depending on me. And that's a very scary thing. And I do want to point out as well that you and I are talking about this, we are both the whitest of white guys, steeped in enormous piles of privilege. The things we're talking about, “Oh, claim, you're an expert and everyone will take you at face value.” Turns out, it doesn't work for people who don't look like our overrepresented selves. And that's a problem.

Scott: I will admit, there's a lot of luck involved in it as well. I feel very lucky, very privileged, that I have been able to be at the right place at the right time, release the right thing, and have the right conversations with the right people, and have been able to compound that interest into something that has become bigger and better. But yeah, it is a situation where potentially not everybody has these opportunities. However, there are some things that I do think people can do to try and set themselves up for success. One of them as we mentioned, is focusing on a narrowly defined niche not to broaden yourself too far.

There's a lot of benefit to being a general practitioner in different ways, but I think focusing on that niche. And I think what you'll find is, as you focus in on that niche, that one, even though you've narrowly defined and focused on one niche, you start touching into other areas; you start to understand and get better at some areas that are somewhat adjacent to what you're doing. But also, one thing that people don't recognize is that it becomes a flywheel of sorts. Is that as you start becoming better known for this thing, that people start reaching out to you and start contacting you about certain things. They start sending you private messages, “Hey, did you know about this certain thing?” “Hey, there's this security issue that I'm looking at on AWS.” I get those types of private messages from people.

So, I become aware of different, potentially, news that's going to come out before the general public does, and so I'm able to digest and better research that before it happens. And so that's an important flywheel that ends up being generated there. But I think also, some of the more well-defined things that people can do is, one, as you're starting out, I think it's very beneficial as you're trying to get your name out there, as you're trying to build your brand, one of the things you can do is to do what's called a survey article. So, not where you're surveying people asking them questions, but a survey in kind of the academic sense, in which you basically write an article that is going through kind of the history of your niche or going through what are the existing tools? What are the pros and cons of them?

Kind of doing a review of what are the current problems in your niche, and what are the best tools for accomplishing that. And so you can create, kind of, some blog post that I think becomes very powerful. But a lot of people start searching for that and it's going to feed into you. If you put that on your own blog, and you include some type of pitch for yourself on there, eventually, people are going to find it. And so doing something like that, and doing things that to you, in your mind, might be somewhat boring, or it's just, like, a normal day for you to do this type of thing.

Or maybe it's some advice you gave to a client and that advice is not restricted by some type of NDA, that you can generally give that advice to other people. To start including that in blog posts as well. Start doing those types of things and that starts leading more and more people to you when you're putting that public effort out there. And the way in which myself and you have done it is to put that information out there for free because there's a finite number of customers that I'm going to be able to work with. And there are only a limited subset of people that have interest in AWS security that are actually going to want to be one of my clients.

So, as a result, if I put this information out there for free, that is going to benefit people that would not be my clients anyways. But some of those people are going to have the ear of, potentially, some of my clients. They're going to be able to recommend me to them because they saw this blog post because I am putting out what I hope is some valuable work for other people to see.

Corey: It absolutely is, and you're right; it builds the reputation. Other things, too, are the unspoken dependencies on this. For example, for a consulting company, something that I took for granted and my business partner had to learn early in his career because we had different upbringing stories, and he's very open about this, is learning to speak to different levels of the organization at the same time without alienating any of those constituencies as you do it. It's a baseline consulting slash professionalism skill. And if you grew up surrounded by it like I tend to—my dad taught me to handle job interviews when I was 12 on a lark, and that's one of the best things he ever did for me.

But if you haven't had that exposure, it's like learning a new language. And it takes time to start sounding like your client in many respects. And there are ways to short circuit that, but we have it all the time. For example, but all the blog posts I do—I don't think I've ever talked about this publicly, but it shouldn't come as any surprise—every blog post that goes out with remarkably few very rapid response exceptions go through a technical editor. I mean, I'm not terrible at writing, but I will absolutely throw it all through an editor who makes it better just by virtue of being able to take that different perspective of being able to look at it differently.

Scott: Yeah, I think that that type of concept of having different types of conversations with people is also kind of eye-opening, is that previously, when I was an employee of a company and I talked with the head of security to another company, ultimately, they were trying to hire me. At the end of the day, if it was a tech company in the Bay Area, they're constantly hiring everybody all the time trying to do whatever they can. So, that conversation becomes very much them talking about their company, and how awesome the snacks are at their company and things like that. Whereas now, when I have a conversation with someone who's the head of security, or otherwise, at a company, it's a very different conversation, where it tends to be focused more on the problems that they're having, as opposed to the benefits of their company. Because the value that they're going to be getting out of the conversation with me is whether or not I can identify areas that I could potentially help them in some way, or give them some free advice on how to do things in a different way. So, you end up having these very different conversations with people as well.

Corey: Absolutely. And one thing that I, every once in a while, I like to do on this show, and I haven't done it for a while, so you get to be the person who sits around while I do it this time. If you're listening to this, and you want advice on something like this, be it setting out on your own, be it career advice, please reach out to me. The entire reason that I have a career at all is that people who didn't owe me a thing did me favors. And you can never repay that you can only ever pay it forward. So, if you're listening to this, and that resonates with you, please don't hesitate to reach out.

Scott: Yep. I do try to give people advice. I will say though, oftentimes, someone will ask me, wanting some mentoring advice and instead they pitch me on a startup idea that they have which, please don't do that. I am in no way able to fund your startup idea or give you, really, any advice on that. If you have a tech startup, I cannot help you. If you are considering doing consulting, I am in a much better position to try and give you some advice there.

Corey: Yeah, I forgot to clarify. Yeah, I'm not looking to cut checks for folks, as much fun as that is. I'm much more interested in being able to provide insight, things I learned. If I were to start this over again knowing what I know now, I could probably get to where I am now in roughly half the time.

Scott: Exactly, yeah.

Corey: There's just something to be said for having someone to talk to about these things. Every once in a while I say something like that, and someone will corner me. It happened at re:Invent a couple of years ago, and he asked for advice, said, “I heard you say ‘reach out,’ so I did.” He's now an AWS community builder, and he is just transforming as far as modernizing his entire career and skill set. It's really something to see when people take you seriously on stuff like that.

Scott: And I will say also, it's important that as people start finding some success in whatever they're doing, that you do try to raise up other people around you that are entering it as well. Even though I've defined this niche of AWS security, there are a number of other people that are doing amazing, fantastic things. And I try as hard as possible to raise them up, to point out who they are, to credit them. You know, if I ever mention any type of tool, or blog post, or anything like that, I try to make sure I also identify who the person is that wrote that tool or blog post. I think that that is really important as well, is that you don't step on other people in order to get to where you're trying to go.

If you raise other people up, for all sorts of reasons it becomes a better situation. One of them being that you create a better community within your niche. This is ultimately what I've decided to spend a lot of my life doing; a lot of my waking hours are focused on AWS security. I don't want the environment of AWS security to have a bunch of jerks within it. And within the security community, specifically, there, unfortunately, have been a number of situations where there have been jerks within the security community.

However, I tried very hard to make sure that that does not happen within the AWS security community. I have a limited ability, obviously, to impact that. But I do where I can, to try and make sure that it is a friendly community, it is a welcoming community. I try and do that through fwd:cloudsec, the conference, that is a nonprofit, and try to make that an opportunity for people to attend, to speak at, to be a part of. There's also the Cloud Security Forum Slack, which is invite-only, however, if you ask me or anybody else that's part of it, we'll invite you.

The only reason we've chosen not to have just an invite link for it is because we have found in some of the other Slacks that we've been a part of that if a Slack is completely open, it ends up getting a bunch of spammers in it, unfortunately. So, that Slack though is something very open and inclusive for people to become part of. And what’s been really great is fwd:cloudsec, the conference because we ended up being virtual this past year as opposed to being an in-person conference, it ended up being a lot less expensive. And we were lucky enough that almost all of our sponsors stuck with us. And they capped at the same price that they were paying us, and our costs were much reduced.

And so as a result, we were able to take the funds of fwd:cloudsec, the conference, and use that to pay for that Slack because once you reach a certain number of people in a Slack, it ends up costing money, but also because it's a nonprofit, we're able to have Slack’s kind of reduced pricing as a nonprofit. So, all these things in a blending in well together.

Corey: Oh, yeah. I run—well, I—one of the admins of the Open Guide to AWS Slack channel, and that has something like 13, 14,000 people in it. You can join it yourself if you’re listening to this at slackhatesthe.cloud. So, that is the URL: slackhatesthe.cloud. And you can wind up popping in there. It's just the direct invite link. Yeah, occasionally we have spammers, but you're right in that it's hard to run community well, and having vibrant communities out there for stuff like this is super important. So, if people want to learn more about who you are, what you do, or just want to pick your brain, where can they find you?

Scott: Going to my webpage, summitroute.com; that's going to be the easiest way to find me. You can try searching for me on Twitter. My handle unfortunately is written in hex speak, it's @0xdabbad00, but just try searching for Scott Piper on Twitter, and hopefully, I'll come up.

Corey: Excellent. I will make it a point to do that. And of course, it'll be in the [00:41:36 show notes]. Scott, thank you so much for joining me once again. It is always a pleasure to talk with you.

Scott: Thank you.

Corey: Scott Piper, AWS security consultant. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, and tell me which vendor I should not partner with next.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.