Screaming in the Cloud - Developer Advocacy, Empathy, and Imposter Syndrome with Brandon West

Episode Date: July 19, 2022

About BrandonBrandon West was raised in part by video games and BBSes and has been working on web applications since 1999. He entered the world of Developer Relations in 2011 as an evangelist for a small startup called SendGrid and has since held leadership roles at companies like AWS. At Datadog, Brandon is focused on helping developers improve the performance and developer experience of the things they build. He lives in Seattle where enjoys paddle-boarding, fishing, and playing music.Links Referenced:Datadog: https://www.datadoghq.com/Twitter: https://twitter.com/bwest

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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. This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate.

Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other. Which one is up to you? Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business, production.

With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaming in the cloud. Observability, it's more than just years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS Reinforce to see the latest trends in cybersecurity on July 25th to 26th at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone I've been trying to get on the show for years, but I'm very bad at,

you know, following up and sending the messages and all the rest because we all struggle with our internal demons. My guest instead struggles with external demons. He is the team lead for developer experience and tools advocacy at what I can only assume is a Tinder for pets style company, Date A Dog. Brandon West, thank you for joining me today. Hey, Corey, thanks for having me. I'm excited to be here. Finally, like you said, it's been a couple years, but glad that it's happening. And yeah, I'm on the DevRel team at Date A Dog. Yes, I'm getting a note here in the headset of, whoop, breaking news coming in. Yes, you're not apparently a dog dating company. You are a monitoring slash observability slash whatever the cool kids are calling it today,

telemetry outputter dingus nonsense. Anyone who has ever been to a community or corporate event has no doubt been tackled by one of the badge scanners that you folks have orbiting your booth, but what is it that you folks do? Well, the observability, the monitoring, the distributed trace, and all that stuff that you mentioned. And then a lot of other interesting things that are happening. Security is a big focus, InfoSec, so we're adding some products around that. Automated security monitoring, very cool. And then the sort of stuff that I'm representing is stuff that helps developers provide a better experience to their end users. So things like front-end monitoring, real-time user monitoring, synthetic testing of your APIs, whatever it might be.

Your path has been somewhat interesting. Well, everyone's path has been somewhat interesting. Yours has been really interesting. Because back in 2011, you entered the world of developer relations, or being a dev reliper, as I insist on calling it. And you call it a small startup called SendGrid, which is on some level hilarious from my point of view. I've been working with you folks, you folks being SendGrid, for many years now. I cared a lot about email once upon a time, and now I send an email newsletter every week that,

deep under the hood, through a couple vendor abstraction layers, is still SendGrid. And I don't care about email because that's something that I can pay someone else to worry about. You went on as well to build out DevRel teams at AWS. You decided, okay, you're going to take some time off after that. You went to a

small scrappy startup and, ah, nice. You could really do things right and you have a glorious half of a year and then surprise, you got acquired by Datadog. Congratulances on that, because now you're right back in the thick of things at big company style approaches. Have I generally nailed the trajectory of the past decade for you? Yeah, I think the broad strokes are all correct there.

SendGrid was a small company when I joined. You know, there were 30 of us or so, so got to see that grow into what it is today, which was super, super awesome. But other than that, yeah, I think that's the correct path. It's interesting to me in that you were more or less doing developer relations before that was really a thing in the ecosystem. And I understand the challenge that you would have in a place like SendGrid, because that is large-scale email sending, transactional or otherwise. And that is something that by and large has slipped below the surface level of awareness for an awful lot of folks in your target market.

It's, oh, okay, and then we'll just have the thing send an email, they say, hand-waving over what is an incredibly deep and murky pool. And understanding that that is a hard thing requires a certain level of technical sophistication. So you started doing developer relations for something that very clearly needed some storytelling chops. How did you fall into it originally? Well, I wanted to do something that let me use those storytelling chops, honestly. I had been writing code at an agency for coal mines and gold mines and really

actively inserting evil into the world power plants and that sort of thing and You know, I went to school for English literature. I love writing I played in thrash metal bands when I was a kid So I've been up on stage being cussed at and told that I suck So I'm oh I get that at conference talks all the time. Yeah, right So that's why when people ask me to speak I'm like absolutely There's no way I can bomb harder, I get that at conference talks all the time. Yeah, right? So that's why when people ask me to speak, I'm like, absolutely. There's no way I can bomb harder than I've bombed before. No fear, right? So yeah, I wanted to use those skills. I wanted to do something different.

And one of my buddies had a company that he had co-founded that was going through Techstars in Boulder. SendGrid was the first accelerator-backed company to IPO, which is pretty cool, but they had gone through tech stars in 2009. They were looking for a developer evangelist. So SendGrid was looking for a developer evangelist, and my friend introduced me and said, I think you'd be good at this. You should have a conversation. My immediate thought was, what the hell is a developer evangelist? And what might a SendGrid be and all the rest? Yes, it's that whole, oh, how do I learn to swim? Someone throws you off the end of the dock. And in retrospect, it's, I don't think they were trying to teach me how to swim. Yeah.

Yeah, it worked out great. I will say, though, that I think DevRel's been around for a long time. You know, the title's been around since the original Macintosh at Apple in 1980-ish. There's a whole large part of the tech world that would like you to think that it's new because of all the terrible things that their dev rel team did at microsoft in the late 90s and you can go read all about this there were trials about it these documents were released to the public uh james plamondon is the lead architect of all this nastiness but i think there was then a concerted effort to memory hole that and say, no, DevRel is new and shiny. And then Google came along and said, well, it's not evangelism anymore. It's advocacy.

It's not sysadmin work anymore. It's SRE. It's not on-prem. It's sparkling Kubernetes, et cetera, et cetera. Yeah. So there's this sense in a lot of places that DevRel is new, but it's actually been around a long time and you can learn a lot from reading about that history and understanding it. Something I've given a talk on and written a bit about. My philosophy around developer relations for a while has been that in many cases, its biggest obstacle is the way that it is great at telling stories about fantastically complex, deeply technical things. It can tell stories about almost anything except itself. And I keep seeing similar expressions of the same problem again and again and again. I mean, AWS, where you worked as an example, they love to talk about their

developer advocates. And you read the job descriptions, and these are high-level roles with sweeping responsibilities, broad basis of experience, being able to handle things at a borderline executive level. And then they almost neuter the entire thing by slapping a developer advocate title on top of those people, which means that some of the people that would be most effectively served by talking to them will dismiss them as, well, I'm a director or a VP. What am I going to do talking to a developer advocate? It feels like there's a swing and a miss as far as encapsulating the value that the function provides. I want to be clear. I am not sitting here shitting on DevRel or its practitioners. I see a problem with how it is being expressed. Now, feel free to argue with me and just scream at me for the next 20 minutes, and this becomes a real short show, but it'll be great. Hit me. No, you're correct in many ways, which makes me sad because these are the same conversations that I've been having for the 11, 12 years that I've been in DevRel now. And I thought we would have moved past this at some point. But the problem is that we are bad at advocating for advocacy.

We do a bad job of relating to people about DevRel because we spend so much time worried about stuff that doesn't really matter. And we get very loud voices in the echo chamber screaming about titles and evangelism versus advocate versus community manager and which department you should report up to and all of these things that ultimately don't matter. And it just seems like bickering from the outside. I think that the core of what we do is super awesome. And I don't think it's very hard to articulate. It's just that we don't spend the time to do that. It's always odd to me when I talk to someone like,

oh, you're in DevRel. What does that mean? And their immediate response is, well, it's not marketing. I'll tell you that. It feels like there might be some trauma that is being expressed in some strange ways. I do view it as marketing personally, and people who take umbrage at that don't generally

tend to understand what marketing is. Yeah, you could look at any area of business or any function and judge it by some of the worst examples that we've all seen. But when someone tells me they work in sales, I don't automatically assume that they are sending me horrifyingly passive-aggressive drip campaigns or trying to hassle me at a car lot. No, there's a broad spectrum of people. Just like I don't assume that you're an engineer and I immediately think, oh, you can't solve fizzbuzz on a whiteboard. No, there's always going to be a broad spectrum of experience. Marketing is one of those awesome areas of business that's dramatically misunderstood a lot. Similarly to the fact that, you know,

DevRel can't tell stories. You think marketing could tell stories about itself, but it still struggles too in a bunch of ways. But I do believe that even if they're not the one and the same, developer relations and marketing are aligned around an awful lot of things, like being able to articulate value

that is hard to quantify. I completely agree with that. And if I meet someone in DevRel that starts off the conversation by saying that they're not in marketing, then I know they're probably not that great at their job. I mean, I think there's a place of tech hubris where we want to disrespect anything that's not a hard skill, where it's not putting zeros and ones into a chip.

And spoiler, they are all very hard skills. Yeah. And so first off, stop disrespecting marketing. It's important. Your business probably wouldn't survive if you didn't have it. And second of all, you're not immune to it, right? Like Heartbleed had a logo and a name for vulnerability

because tech people are so susceptible to it, right? People don't just wake up and wait in line for three days for a new iPhone because tech marketing doesn't work, right? Oh, tech marketing doesn't work on me, says someone who's devoted the last five years of their life to working on Kubernetes. Yeah, sure it doesn't. Yeah, exactly.

So that whole perspective is silly. I think part of the problem is that they don't want to invest in learning how to communicate what they do to a marketing org. They don't want to spend in learning how to communicate what they do to a marketing org. They don't want to spend the time to say, here's how the marketing world thinks, and here's how we can fit into that perspective. They want to come in and say, well, you don't understand DevRel. Let me define DevRel for you and tell you what we do, and all of those sorts of things. It's too prescriptive and less collaborative.

Anytime you start getting into the idea of metrics around how do you measure someone in a developer advocacy role, the answer is, well, your metrics that you're using are wrong and any metrics you use are wrong and there's no good way to do it. And I am sympathetic to that. When I started this place, I knew that if I went to a bunch of events

and did my thing, good things would happen for the business. And how did I articulate that? Gut feel. But when you own the place, you can do that. Whereas when you are a function inside of another org, inside of another org, and you start looking at it from the executive leadership position at these things, it's, okay, so let me get this straight. You cost as much as an engineer. You cost as much as that, again, in your expenses, because you're traveling all the time, you write zero production code. Whenever people ask you what it is you do here, you have a very

strange answer. And from what we can tell, it looks like you hang out with your friends in exotic locations, give a 15-minute talk from time to time that mentions our name at the beginning and nothing else relevant to our business. And then you go around and the entire story is just, trust me, I'm adding value. Yeah, when it's time to tighten belts and start cutting back, is it any wonder that the developer advocacy is often one of the first departments hit from that perspective? It doesn't surprise me. I mean, I've been a part of DevRel teams where we had some large number of events that we had attended for the year, I think 450 something. And the director of the team was very excited to show that off, right?

You should have seen the CFO's face when he heard that, right? Because all he sees is outgoing dollar signs, like how much expense? What's the ROI on 450 events? 450 events, that's more than one a day. Okay, great. That's a big number. And I already know what we're spending. Great.

How much business came out of that? And that's when the hemming and hawing starts. Well, sort of. And yeah, it doesn't present well in the language that they are prepared to speak. Now, marketing can tell those stories because they have for ages. Like, okay, how much business came from our Super Bowl ad? I don't know. The point is, is that there's a brand awareness play. There's the chance to remain top of the mental stack when people think about this space. And over the next few months, we can definitely see there's been a dramatic uptick in our business. Now, how do we attribute that back? I don't know. I mean, there's a saying in marketing

that half of your marketing budget is wasted. Now, figuring out which half will spend the rest of your career, you'll never get even close because people don't know the journey that customers go through. Not really. Even customers don't often see it. Take this podcast, for example. I have sponsors that I do love and appreciate who say things from time to time on this show. And people will hear it and occasionally will become customers of those sponsors. But very often it's, oh, I heard about that on the podcast.

I'll Google it when I get to work. And then I'll have a conversation with my team and we'll agree to investigate that. Any UTM tracking has long since fallen by the wayside. You might get to that from discussions with users in their interview process, but very often they won't remember where it came up. And it's one of those impossible to quantify things. Now I sound like one of those folks

where I'm trying to sit here and, oh, buy sponsorships that you can never prove add value. But that is functionally how advertising tends to work back in the days before it spied on you. Yeah, absolutely. We've added a bunch of instrumentation to allow us to try and put that multi-touch attribution model together after the fact,

but I'm still not sure that that's worth the squeeze, right? You don't get much juice out. One of the problems with metrics in DevRel is that the things that you can measure are very production focused. It's how many talks did you give? How many audience members did you reach? Some developer relations folks do actually write production code. So it might be how many of the official SDK that you support got downloaded. That can be more directly attributed to business impact. Those sorts of things are fantastic. But a lot of it is kind of fuzzy.

And because it's production-focused, it can lead to burnout because it's disconnected from business impact. It's how many widgets did your line produce today? Well, we gave all these talks and we had 150,000 engaged developer hours. Well, cool. What was the business outcome? And if you can't answer that for your own team and for your own self and your role, that leads pretty quickly to burnout. But if you start measuring something and grading people based on it, they're going to optimize for what you measure. For example, I send an email newsletter out at time of this recording to 31,000 people every week, and that's awesome. I also periodically do webinars about the joys of AWS bill optimization, and you know,

50 people might show up to one of those things. Okay, well, from a raw numbers perspective, yeah, I'd much rather go and send something out to those 31,000 folks until you realize that the kind of person that's going to devote half an hour or 45 minutes to having a discussion with you about AWS bill optimization is far likelier to care about this to the point where they become a customer than someone who just happens to be in an audience for something that is orthogonally related. And that is the trick, because otherwise we would just all be optimizing for the single biggest platforms out there. Oh, I'm going to go talk at this conference and that conference, not because they're that germane to what we do,

but because they have more people showing up. And that doesn't work. When you see that even in the podcast world, you have Joe Rogan as the largest podcast in the world. Let's not make too many comparisons in different ways, because I don't want to be associated with that kind of tomfoolery. But there's a reason that his advertisers, by and large, are targeting a mass market audience, whereas mine are targeting B2B SaaS, by and large. I'm not here shilling for various mattress companies. I'm instead talking much more about things that solve the kind of problem that listeners to this show are likely to have. It's the old school thought of advertising where this is a problem that is germane to a certain type of audience and that certain type of audience listens to shows like this. That was my whole school of thought.

Absolutely. I mean, the core value that you need to do, DevRel, in my opinion, is empathy. It's all about what Maya Angelou said, right? People may not remember what you said, but they'll definitely remember how you made them feel. And I found that to be incredibly true. The moments that I regret the most in DevRel are the times when someone that I've met and spent time with before comes up to have a conversation and I don't remember them because I met 200 people that night. And then I feel terrible, right? So those are the metrics that I use internally. It's hearts and minds. It's how do people feel? Am I making them feel empowered and better at their craft through the work that I do? That's why I love DevRel. If I didn't get

that fulfillment, I'd go write code again. But I don't get that sense of satisfaction. And wow, I made an impact on this person's trajectory through their career that I do from DevRel. So I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines.

Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and more, as well as things you're likely to actually be using. Deploy on AWS, secure with Snyk, learn more at Snyk.co slash scream. That's S-N-Y-K dot C-O slash scream. That's s-n-y-k dot c-o slash scream. The way that I tend to see it, too, is that there's almost a bit of a broadening of DevRel. And let's be clear, it's a varied field with a lot of different ways to handle that approach. I have a terrible public speaker, so I'm not going to ever succeed in DevRel. Well, that's certainly not true. People need to write blog posts. People need to wind up writing some of the example code in some cases.

People need to talk to customers in a small group environment as opposed to in front of 3,000 people and talk about the things that they're seeing and the rest. There's a broad field and different ways that it applies. But I also see that there are different breeds of developer advocate as well. There are folks like you, for example. You and I have roughly the same amount of time in the industry working on different things. Whereas there's also folks who it seems like they graduate from a boot camp and a year later they're working in a developer advocacy role. Does that mean that they're bad developer advocates?

I don't think so. But I think that if they try and present things the same way that you or I do from years spent in the trenches working on these things, they don't have that basis of experience to fall back on. So they need to take a different narrative path. And the successful ones absolutely do. Yeah. I think it's a nuanced and broad field. I wish that there was more acceptance and awareness of that. That's absolutely true. And part of the reason people criticize DevRel and don't take it seriously is they say, well, it's inconsistent. This org reports to product and this org reports up to marketing. This other place is part of engineering.

You know, it's poorly defined. But I think that's true of a lot of roles in tech. Like engineering is usually done a different way, very differently at some orgs compared to others. Product teams can have completely different methodologies for how they track and manage and estimate their time and all of those things. So I would like to see people stop using that as a cudgel against the whole profession. It just doesn't make any sense. At the same time, two of the best evangelists I ever hired were right out of university. So you're completely correct. The key thing to keep in mind there is like, who's the audience, right? Because ultimately, it's about building trust with the audience. There's a lot of rooms where if you and I

walk into the room, if it's like a college hackathon, we're going to have a... Yeah, we have some real hello fellow kids energy going on when we do that. Yeah. Which is also why I think it's incredibly important for developer relations teams to be aware of the makeup of their team. How diverse is your team and how diverse are the audiences you're speaking to? And if you don't have someone who can connect, whether it's because of age or lived experience or background, then you're going to fail because, like I said, the number one thing you need to be successful at this role is empathy, in my opinion. I think that a lot of the efforts around a lot of this, trying to clarify what it is, in some cases gone, and I guess I'm going to call it the wrong direction. And I know that sounds judgy, and I'm going to have to live with that, I suppose. But talk to me a bit about the, I guess, rebranding that we've seen in some recent years around developer advocates. Specifically, like, I like calling folks dev relippers because it's cutesy, it's a bit of a portmanteau, great, but it's also not something I seriously suggest most people put on business cards.

But there are people who are starting to, I think, take a similar joke and actually identify with it where they call themselves developer avocados, which I don't fully understand. I have opinions on it, but again, having opinions that are not based in data is something I try not to start shouting from the rooftops wherever I can. You live in that world a lot more closely than I do. Where do you stand? So I think it was well-intentioned, and it was an attempt to do some of the awareness and brand building for DevRel broadly that we had lacked. But I see lots of problems with it. One, we already struggle to be taken seriously in many instances, as we've been discussing. And I don't think we do ourselves any favors by giving ourselves cutesy nicknames that sort of infantilize the role.

Like, I can't think of any other job that has a pet name for the work that they do. Yeah, the uwu accounting. I sort of don't see that happening very often in most business orgs. Yeah, it's strange to me. At the same time, a lot of the people who came up with it and popularized it are people that I consider friends and good colleagues. So hopefully they won't be too offended, but I really think that it's kind of set us back in many ways. I don't want to represent the work that I do with an emoji. Funny you bring that up. As we record this, you're the first recording I have on my new ridiculous desktop computer thing from Apple, which is I have named after a, you know,

the same naming convention that you would expect from an AWS region. It's us-shitpost-1. Instead of the word shit, it has the poop emoji, and you'd be amazed at the number of things that just melt when you start trying to incorporate that. GitHub has a problem with that being the name of an SSH key, for example. I don't know if I'll keep it or I'll just fall back to just spelling words out, but right now, at least, it really is causing all kinds of strange computer problems. Similarly, it causes strange cultural problems

when you start having that dissonance and seeing something new and different like that in a business context. Because in some cases, yeah, it helps you interact with your audience and build rapport. In many others, it erodes trust and confidence that you know what you're talking about

because people expect things to be cast a certain way. I'm not saying they're right. There's a shitload of bias that bakes into that. But at the same time, I like to at least bias for choosing when and where I'm going to break those expectations. There's a reason that increasingly my duckbillgroup.com website speaks in business terms rather than in platypus metaphors. Whereas last week in AWS.com very much leans into the platypus.

And that is the way that the branding is breaking down just because people expect different things in different places. Yeah. And, you know, this framing matters. And I've gone through two exercises now where I've helped rename an evangelism team to an advocacy team. Not because I think it's important. To me, it's a bunch of bike shedding. But it has external implications, right? Especially evangelism in certain parts of the world has connotations. It's just easier to avoid those. And how we present ourselves, the titles that we choose are important. I wish we would spend way less time arguing about them. You know, advocacy has one evangelism, don't use it. DevRel,

if you don't want to pick one, great. DevRel is a broader umbrella. If you've got community managers, people who can't write code that do things involving your events or whatever, program managers, if they're on your team, DevRel, great description. I wish we could just settle that. Lots of wasted air discussing that one. Constantly. And it feels like this is a giant distraction that detracts from the value of DevRel. Because I don't know about you, but when I

pick what I want to do next in my career, the things I want to explain to people and spend that energy on are never, I want to explain what it is that I do. I've never liked those approaches where you have to first educate someone before they're going to be in a position where they want to become your customer. I think, honestly, that's one of the things that Datadog has gotten very right. One of the early criticisms lobbed against Datadog when it first came out was, oh, this is basically monitoring by Fisher Price. This isn't the deep dive stuff. Well, yeah, but it turns out a lot of your buying audience are fundamentally toddlers with no visibility into what's going on. For an awful lot of what I do, I want it to be click, click, done. I am a Datadog customer for a reason. It's not because I don't

have loud and angry opinions about observability. It's because I just want there to be a dashboard that I can look at and see what's working, what's not, and do I need to care about things today. And it solves that job admirably because if I have those kinds of opinions about every aspect, I'm never going to be your customer anyway or anyone's customer. I'm going to go build my own and either launch a competitor or realize this is what I truly love doing and go work at a company in this space, possibly yours. There's something to be said for understanding the customer journey that those customers do not look like you. And I think that's what's going on with a lot of the articulation around what developer relations

is or isn't. The people on stage who go to watch someone in DevRel give a talk do not care, by and large, what DevRel is. They care about the content that they're about to hear about. And when the first half of it is explaining what that person's job is or isn't, people lose interest. I don't even like intros at the beginning of a talk. Give me a hook. Talk for 45 seconds. Give me a story about why I should care before you tell me who you are, what your credentials are, what your job title is, who you work for. Hit me with something big up front, and then we'll figure it out from there. Yeah, I agree with you. I give this speaking advice to people constantly. Do not get up on stage and introduce yourself. You're not a carnival hawker. You're not trying to get people to roll up and see the show.

They're already sitting in the seat. You've established your credibility. If they had questions about it, they read your abstract and then they went and checked you out on LinkedIn, right? So get to the point, make it engaging and entertaining. I have a pet theory about what's going on in some cases where I think on some level, it's an outgrowth of an imposter syndrome like behavior where people don't believe that they deserve to be on stage talking about a thing. So they start backing up their bona fides to almost reassure themselves because they don't believe that they should be up there. And if they don't believe it, why would anyone else? It's the wrong approach by holding the microphone. You inherently deserve to hold the microphone.

And go ahead and tell your story. If people care enough to dig into you and who you are and, well, what is this person's background really? Rest assured, the internet is pretty easy to use these days. People will find out. So let them do that research if they care. If they don't, then there's an entire line of people in this world who are going to dislike you or say you're not qualified for what it is you do or you don't deserve it. Don't be in that line, let alone at the front of it. So you mentioned imposter syndrome, and it got me thinking a little bit, and hopefully this doesn't offend anyone, but I kind of am starting to think that imposter syndrome is in many ways invented by people to put the blame on you for something that's their fault. It's like a carbon footprint to the oil and gas industry, right? These companies can't provide you psychological safety, and now they've gone and convinced you that it's your fault and that you're suffering from this syndrome, rather than the fact that they're not actually making you feel prepared and confident and ready to get up on that stage, even if it's your first time giving a talk,

right? I hadn't considered it like that before. And again, I do tend to avoid straying into mental health territory on this show because I'm not an expert. I'm a loud, confident white guy in tech. My failure mode's a board seat and a book deal, but I am not board certified, let's be clear. But I think you're onto something here because early on in my career, I was very often faced with a whole lot of nebulous job description style stuff, and I was never sure if I was working on the right thing. Now that I'm at this stage of my career, and as you become more senior, you inherently find yourselves in roles most of the time that are themselves mired in uncertainty. That is on some level what seniority

leads to. And that's fine. But early on in your career, not knowing if you're succeeding or failing, I got surprise fired a number of times when I thought I was doing great. There are also times that I thought I was about to be fired on the spot and come on in, shut the door. And yeah, here's a raise because you're just killing it. And it took me a few years after that point

to realize, wait a minute, they were underpaying me. That's what that was. And they hoped I didn't know. But it's that whole approach of just trying to understand your place in the world. Do I rock? Do I suck? And it's that constant uncertainty and unknowing. And I think companies do a terrible job, by and large, of letting people know that they're okay, they're safe, and they belong. I completely agree. And this is why I would strongly encourage people, if you have the privilege, please do not work at a company that does not want you to bring your whole self to work or that bans politics or however they want to describe it.

Because that's just a code word for we won't provide you psychological safety. Or if they're going to, it ends at a very hard border somewhere between work and life. And I just don't think anyone can be successful in those environments. I'm sure it's possible, but it does bias for folks who, frankly, have a tremendous amount of privilege in many respects. Where I mentioned about, like, I'm a white dude in tech, you are too, and when we say things, we are presumed competent and people don't argue with us by default. And that is a very easy to forget thing. Not everyone who looks like us is going to have very similar experiences. I have gotten it hilariously wrong before when I've given talks on how to wind up negotiating for salaries, for example, because I, well, it worked for me. What's the problem? Yeah, I basically burned that talk with fire, redid the entire thing, and wound up giving it with a friend of mine who was basically

everything that I am not. She was an attorney. She was a woman of color, etc., etc. And suddenly, it was a much stronger talk because it wasn't just how to succeed for white guys. There's value in that, but you also have to be open to hearing that and acknowledging that you were born on third, you didn't hit a triple. There's a difference. And please forgive the sports metaphor, they do not sound natural coming from me. I don't think I have anything more interesting to add on that topic. So I really want to thank you for taking the time to speak with me today. If people want to learn more about what you're up to and how you view the world, what's the best place to find you? So I'm most active on Twitter at B West, but you know, it's a mix of things. So you may, may not just get tech. Most recently,

I've been posting about heaven forbid you bring your whole self to school, right? I think most recently I've been posting about a drill press that I'm restoring. So all kinds of fun stuff on there. I don't know. It sounds kind of wait for it. Boring to me, but that's it. I can't believe I missed that one. You're welcome. Well done. And then I also will be hiring for a couple of developer relations folks at Datadog soon. So if that's interesting and you like the words I say about how to do DevRel, then reach out. And you can find all of that in the show notes, of course.

I want to thank you for being so generous with your time. I really appreciate it. Hey, thank you, Corey. I'm glad that we got to catch up after all this time and hopefully get to chat with you again sometime soon. Brandon West, team lead for developer experience and tools advocacy at Datadog. 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. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry and insulting comment that is talking about how I completely misunderstand

the role of developer advocacy, and somehow that rebuttal features no fewer than 400 emojis shoved into it. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business

and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble. this has been a humble pod production stay humble