Early Stage DevRel with Brandon West

Hey, everybody. This is Jack from Bitreach, and you're listening to Scaling Dev Tools, the show that investigates how dev tools go from 0 to 1. If you're anything like me, you probably spend a lot of time wondering, how can I become more popular with developers? Today's guest, Brandon West, may be among the most qualified people on the planet to tell you how. Brandon joined SendGrid in 2,011 as their first developer evangelist and helped them become the default email API.

Brandon was also a leader in DevRel at the biggest developer tool of them all, AWS. Brandon has also worked with 2 other developer focused startups, including Co Screen, which just got acquired by Datadog. Brandon, thanks for joining us today.

Hey, Jack. Thanks very much for having me. I'm glad to be here and, excited to talk about the dev tools and DevRel.

Brandon, what does DevRel look like at start ups at the earlier stages?

DevRel looks like a lot of different responsibilities at an early stage company. I I think that's true of of any role at an early stage company when you've got 7 or 8 people. Everyone's doing a little bit of everything. But especially for developer relations early on at startups, you are going to have an outsized impact on the road map and the trajectory of the product. And that's very important because you are out there in the field connecting directly with the people that are going to be deciding whether or not your tool is useful and worth spending money on.

The thing that I think a lot of early stage startups get wrong if they're going to invest in DevRel is they try and polish up the product and make it really ready for prime time before they get out in the field and demo it. And I think that is a huge mistake. If you're early stage startup at DevRel, you have to be comfortable with representing a product that's not quite done yet because you are a startup. You're running experiments. You're iterating.

You're trying to have those conversations with your customers to figure out what you should be building, what's working, and what's not. So early on at DevRel, spending a lot of time with the product team is very important.

A quote I love from you. These are your words. Playing in a shitty metal band helps prepare you for demoing products which aren't ready for prime time yet.

And and to be fair, the the band got got less shitty over time. We were new when we started. Good group of guys. It just took some practice and iteration experimentation. But if you don't get up on stage and play the songs that you've been writing in the basement, you never know which ones make the audience get up out of their seat and react and have emotion.

And it's the same sort of thing with the product that you're building. If you don't take it out into the field and see how people react to it, you won't know if you're on the right path. So I you have to have a thick skin to do this early on. It's a much easier job to do when you're standing on top of a brick of gold and everyone loves the product that you're doing, but it takes years of hard work to get to that point.

I love selling bricks of gold. It's a great way to put it.

Everyone wants to have that job, and it's great when you get to that point. But like I said, it it takes a lot of time and effort. And I think that's one thing if you're looking at a a DevRel job, you're considering what size company to join and whether you wanna be on the product or the marketing or the engineering side of a company because DevRel can work in all of those departments. How much of the product you wanna have your hands on is going to have an important part of that decision. If you wanna have your hands on the product a lot more, a start up is gonna work a lot better than something where there's big efficient machinery to make sure all the products are ready to go to market, and then you're there to be the spokesperson.

One of the things that you've mentioned previously to me is about content and what content looks like at that earlier stages, and you mentioned was building engineering credibility.

I think when your audience is developers, they know when your product is well developed or or they should to certain extent depending on their level of sophistication and the type of work that they do on a day to day basis. And so one of your jobs is to make sure that they see that you are doing things the way they would want them to be done or that you're using best practices that you are caring about security from the very beginning of building your software, that you're gonna do things in a a scalable, highly available way in a way that makes sense for the stage of your startup or or your business. You don't need to build things for a massive scale right away. And if you do, you'll get it wrong. But that's part of engineering credibility too.

I think a good developer knows that. And if they see you over engineering things, they're gonna wonder why you're doing that. Content early on, you're trying to do a lot of things. You're trying to demonstrate that you have smart people on your team that are building really cool things. That's one to show your expertise, but also to hopefully get some of those smart people to want to come build those things with you.

They'll be like, wow. That that team's working on really awesome stuff. So that's a great recruiting lever. And then the other thing is just for ongoing brand trust and awareness. You want to have the people that are ultimately deciding whether to use your dev tool associating you with doing tough things and working on interesting engineering problems.

The nice thing about that is it leaves the door open for all kinds of content. No matter what you're building, you have stories to tell that can help you achieve these goals.

How do you balance doing the right things and building credibility with the fact that you're also being willing to push things and demo things which aren't perfect yet?

From a content perspective, especially early stage, there are some foundational things you need to be doing, which is laying the groundwork with SEO kind of focused content, stuff that's going to bring eyeballs to your brand just so people know your logo and that you exist even if they weren't actually looking for your product. You have to do those sorts of things while you're also going out and doing the more specific focus things that are about your product and your personas that you're trying to connect with. And one thing that worked really well for us at SendGrid was we were able to connect to those things. We would go to hackathons, tell people about this transactional email delivery solution that we had, help them build things with it, and then see all the problems they would run into. And then that would become one feedback for the product team, but then also content.

If we had to explain over and over again what a webhook was, well, that was fertile ground for awesome content. And so, I think right now, if you search what is a webhook, you'll probably still get SendGrid's blog at top of that results page because our dev advocate, Nick, did an awesome job explaining it. And it was a great mixture of need from the field and timing and just really well executed content. Wasn't directly related to SendGrid, but part of that art article is in, like, okay. Here's how you can implement these concepts using SendGrid's inbound email webhook.

It's share the knowledge first, educate people, make them better at what they do, and then demonstrate how to implement those things through the thing that you're trying to sell.

You mentioned content there. A couple of years ago, I was building an app that needed some emails, and I started searching around on how do I implement emails, transactional emails. And every piece of content Stack Overflow answer seemed to point me back to SendGrid. It's a bit of a juggernaut now, does 100 of 1,000,000 of dollars every year. But you were one of SendGrid's earliest employees.

What was it like when you were at SendGrid?

That's certainly true. You know, I think we had a lot of challenges, and I think every startup has several days where their startup might have ceased to exist if some things had gone slightly different, and and we certainly had those those moments at at SendGrid. Just to give an example of how rough some of these edges were when we were out demoing this in the field, you could send an email via unauthenticated HTTP request that had credentials in the query string, just in plain text in the parameters in in the URL, and and that would make an email get sent at the very early days of the API, which is clearly a huge, huge problem for spam and those sorts of things. But those are the types of things where the pain point that we solved for developers was so strong that those were the sorts of things where we launched and then just moved quickly to clear those up. But I'll I'll give an example of how you have to have a strong relationship with the product team early on and how they have to be receptive to the things you're experiencing in the field.

And that's because, you know, spam to a company like SendGrid is a existential threat. If spammers compromise your network, they can destroy the reputation of all of your email sending IP addresses, and then the legitimate email doesn't get delivered. And then everything that you promise to your customers is a lie. We had this process early on of vetting customers basically manually. So any new account would sign up, and then we would have support people go do a background check, really, and make sure the business was legitimate, that there was no funny business about IP versus where they said they were based or any of that kind of thing.

But as we started getting more customers, this started taking a long time, like several days at one point. And when we're out in the field at a hackathon where you have 24 hours to build something awesome and we're telling developers, hey. You gotta use SendGrid, and they do, and they're building all night, and they run into a problem at 2 AM where they're waiting for their SendGrid account to be provisioned because it's a manual process. Well, there's no one awake at 2 AM that's reviewing these things. There's no one to escalate it to.

So we had to have a conversation with the compliance team, with the product team, with the support team and figure out, okay. How do we either, you know, give us a way to to turn these accounts on when we're sitting there with them or ultimately automate this process. Because if it's bad for these people at the hackathon, it's bad for all of our developers who want to immediately swipe that credit card and see those emails go out. We got that problem solved very quickly, but it was very, very painful early on.

It reminds me of my bank. They blocked all my payments recently and said that they had to do the, you know, regulatory kind of processing. And I like what you said last time we spoke where you said, well, that's it's not the customer's problem that you have to go through this.

It it's absolutely true. If those are the types of things where some people would call that shipping your org chart maybe, right, where, oh, that we have we have this set of people who do this thing as their job, and then they work from these hours, and all of a sudden the customer can only get their results during those hours from those specific people. It's never a good idea to be shipping your org chart. Anytime you see something like that where you're taking something that's a pain point for you and putting it in front of the customer, it's time to reflect and say, okay. What what can we do better here?

And sometimes the customers will very much let you know. I remember I was at my 1st hackathon demo in in Portland, Oregon, 2011 or maybe early 2012, and I was a couple minutes into my pitch on what SendGrid is, why you should use it, giving a quick demo, and a hand shoots up from the audience. I'm like, well, I didn't ask for questions. I'm kind of the middle of a flow here, but, you know, what? You do what you gotta do.

I I I said, okay. What's what's your question? And this guy just kinda roasted me. He was, like, kind of an important tech person. His Twitter handle was 1 character long, kind of an early adopter type person.

He starts telling me about this project that his friends had built, which was called, Foursquare in 7 years ago, and the idea was that it would look at where you checked in on Foursquare, what you posted on Twitter, what you posted on Facebook, you know, a year ago, 2 years ago, 5 years ago, and surface it to you in your inbox. You could say, wow. This is cool. And this eventually became TimeHop. But they were early on, they'd used SendGrid, and they got blocked for spam or the the IP that they were sharing with someone got blocked for spam.

And this guy just wanted to know how I was gonna fix it and make sure this didn't happen again ever in the middle of my first product demo. And I'll tell you what, that definitely motivated me to go build those relationships with the product team to make sure that we got those things solved because, you know, I wanted to have that job where I was selling the shiny bricks of gold to developers and not having to deal with the hecklers in the audience during my API demos.

Could you actually touch a little bit more on what that relationship looked like with the product team?

It's a little bit difficult because early on, there wasn't a product team. We had DevRel before we had product managers by a decent number of months. So part of that was working closely with with the engineering org, with the founders. We had 3 developer founders that had their hands pretty deeply connected to the product or on the early days. So a lot of that was just taking what we're hearing in the field and advocating for those developers internally.

And that's one thing I think people have to understand about developer advocate is that you're advocating to developers, but you're also advocating for them. Similarly, you can use the developer part of that title as a descriptor of yourself if you are developers who are advocates and also for your audience. So you have to kinda understand how you think about the world, and that's why when people talk about titles, especially in DevRel, the conversation usually goes off the rails. But there's so many different ways to think about what those words mean even when you just have 2 of them that it's important that you take the time to be thoughtful about it. A lot of that is just saying, okay.

Here's actual customer anecdote, and anecdote in aggregate becomes data. And then you take that data back to the decision makers. You say, here's what we're hearing. Even better is if you can say, okay. We're getting all of this data, all these complaints about our API.

If you can somehow say, and here's the downstream impact that has on customer retention or ultimately dollars that you're making, you'll have a very, very strong case. And I I did that at some point at SendGrid where I was very scary, but I became the product owner of the entire API for a 6 month period while we were trying to figure out how to make it from version 2 of the API into a new version that would incorporate all of the years of feedback we've been hearing in the field. It took a long time to get to that point where you have that trust, and people say, okay. You as a developer relations team can go own these things and actually run these products. At the start up, though, it's super important.

And it obviously didn't put you off working at start ups because you're now one of the first or the first developer evangelist, Co Screen?

I joined Co Screen last year. I think I I was the 8th person on the team when I joined, so very early stage. Co screen is a collaboration tool, so it's simultaneous screen sharing across multiple users and platforms. If you have 3 people joining a Co screen session, one's on Mac, one's on Windows, Everyone can share a window at the same time. They're all interactive.

I could be sharing my IDE. Someone else could be sharing their terminal window. Someone else could be sharing a a dashboard from Datadog or whatever it might be to help debug a problem. That was really cool. It was definitely a different challenge because I'm used to representing things that developers get their hands on directly, API platforms.

Co screen, you can use it for anything. We've had people use it for music production that they're collaborating with people on. People use it for teaching in classrooms and that kind of thing. But, really, we've found the most success with pair programming and technical onboarding and kind of this remote incident response use case from technical users. I joined to to do developer relations, but it's a little bit of a different flavor where I'm not demonstrating how to connect to a platform and install an SDK and that sort of thing.

It's more about optimizing the way you work and thinking about the way you choose your tools and that sort of thing. A bit of a different job, which is part of why I wanted it, a new challenge, and really kind of a more of a a go to market challenge. The cool thing about that is that the product had been built started as a side project, but had been built really formally full time over the course of a year by a completely remote team, which is really cool. So you have a a completely remote team building a remote working tool. But we actually ended up getting acquired at the the beginning of the year by Datadog, which was really exciting.

But, of course, that means my role has shifted again now. We have a bunch more resources. We have other folks on the team that are capable of doing a lot of the go to market type of stuff that I was responsible for. It's great now. We're working on integrating into the Datadog platform, kind of figuring out what those best use cases are going to be, and we'll be able to open things back up for kind of an another public beta very soon here, which we're really excited about.

That's very, very exciting. You've had such a varied career. It's quite incredible.

Yeah. I I've been very, very fortunate. I was a software developer for 10 or 11 years, and I was writing code for coal mines and gold mines and power plants and doing a lot of stuff that I really don't feel good about these days. I was just a little bit too young to really understand the ethical implications of the tech that I was putting into the world. And since I found developer relations in 2011 after writing code for 10, 11 years, it's really been refreshing and awesome to to spend time talking to passionate people that are solving real problems and showing them how they can be better at that, how they can use some of these new things.

It's really fulfilling to me in a way that writing code for code for gold mines wasn't, which I guess is a low bar. I've been blessed to work for early stage startups that have IPOed, early stage startups that have gotten acquired, giant enterprise corporations. I've been very, very fortunate to work with awesome, extremely smart, talented people at every step of the way and excited to keep doing that throughout the rest of my career.

Brandon, where can people learn more about Brandon if they enjoyed hearing your words of wisdom?

I'd love to continue the conversation with anyone that's interested. I'm most active on Twitter. You can find me there at bwest, and you can also get in touch with me at brandon.west@datadoghq.com. I will be hiring for a few DevRel folks on the Datadog team soon. So if you're interested in that, definitely get in touch.

Brandon, it's really an incredible conversation. Thank you everyone for listening to Scaling Dev Tools. We'll be back very soon.