Early Stage DevRel with Brandon West
Brandon West once got heckled mid-demo at his first-ever hackathon pitch by an early Foursquare-adjacent developer whose project had just been blocked for spam on a shared SendGrid IP. He says the experience is exactly what motivated him to go build a real relationship with SendGrid's product team.
Brandon West joined SendGrid in 2011 as its first developer evangelist, later led DevRel at AWS, and most recently did developer relations at CoScreen, a real-time collaboration tool acquired by Datadog.
We get into why representing an unfinished, rough-edged product is simply part of the job at an early-stage startup, how a SendGrid support bottleneck at 2am during a hackathon forced a rethink of manual account vetting, what it means to be a developer advocate who advocates both to developers and for them internally, and how a career writing software for coal mines and power plants led him into a job he finds far more fulfilling.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does DevRel actually look like at a startup in its earliest stages?
It looks like a lot of different responsibilities, which is true of any role at an early-stage company — when you've got seven or eight people, everyone's doing a bit of everything. But developer relations specifically has an outsized impact on the roadmap and trajectory of the product early on, because you're the one out in the field connecting directly with the people deciding whether your tool is worth paying for. A mistake a lot of early-stage startups make is trying to polish the product up before getting out in the field to demo it. If you're doing DevRel at an early-stage startup, you have to be comfortable representing something that isn't quite done yet, because you're running experiments and iterating, and those field conversations are exactly how you figure out what to build next. Spending a lot of time with the product team early on matters a lot.
You've said that playing in a mediocre metal band helped prepare you for demoing products that aren't ready for prime time. What did you mean?
To be fair, the band got less mediocre over time — we were new when we started, a good group of guys, it just took practice and iteration. But if you don't get up on stage and play the songs you've been writing in the basement, you never know which ones actually make the audience get up and react. It's the same with a product — if you don't take it into the field and see how people respond, you don't know if you're on the right path. You have to have thick skin to do this early on. It's a much easier job once you're standing on a brick of gold everyone already loves, but it takes years of hard work to get there.
How does that trade-off factor into deciding what size company to join for a DevRel role?
It comes down to how much of the product you actually want your hands on. If you want to be close to the product itself, a much earlier-stage startup works better than a company with big, efficient machinery already making sure everything's ready to go to market, where you're mainly there as the spokesperson.
You've talked about content early on being about building engineering credibility. What does that look like?
When your audience is developers, they know, to some extent, whether your product is well built. Part of your job is making sure they see you're following best practices, caring about security from the start, and building in a scalable way appropriate to your stage — you don't need to build for massive scale immediately, and if you try, you'll get it wrong, which a good developer will also notice. Early content is trying to demonstrate you have smart people building cool things — that's both a credibility signal and a recruiting lever, since people see that and want to come build with you. It's also about ongoing brand trust: you want the people deciding whether to use your dev tool to associate you with tackling hard, interesting engineering problems. The nice thing is that no matter what you're building, you have stories to tell that serve those goals.
How do you balance building that credibility with the willingness to demo things that aren't perfect yet?
From a content perspective, especially early on, you need foundational SEO-focused content that brings eyeballs to your brand so people know your logo exists, even if they weren't specifically looking for your product, alongside more specific content aimed at your actual personas. Something that worked really well for us at SendGrid was connecting the two: we'd go to hackathons, tell people about our transactional email API, help them build with it, and watch what problems they ran into. That became both product feedback and content. If we had to explain what a webhook was over and over, that was fertile ground for great content — if you search 'what is a webhook' today, SendGrid's blog is probably still near the top, because our developer advocate Nick did a great job explaining it. The content wasn't directly about SendGrid, but part of the article showed how to implement the concept using our inbound email webhook — share the knowledge first, educate people, then show how to apply it through the thing you're selling.
You were one of SendGrid's earliest employees, and it's now a huge business. What was it actually like in the early days?
We had a lot of challenges — every startup has days where things could've ended if something had gone slightly differently, and SendGrid certainly had those. To give a sense of how rough the edges were: early on, you could send an email via an unauthenticated HTTP request with credentials sitting in plain text in the URL's query string, which is obviously a massive spam risk. But the pain point we solved for developers was strong enough that we launched anyway and moved quickly to clean things up. Spam is an existential threat to a company like SendGrid — if spammers compromise your network, they destroy the sending reputation of all your IP addresses, and then legitimate email stops getting delivered. We had a manual account-vetting process early on, where support would background-check every new signup. As we grew, that started taking days. When you're at a hackathon with 24 hours to build something and developers are stuck waiting at 2am for their account to be provisioned, and there's no one awake to review it or escalate to, that's a real problem. We had to work with compliance, product, and support to either give ourselves a way to activate accounts on the spot or automate the process entirely — we solved it quickly, but it was genuinely painful getting there.
That sounds a bit like a bank forcing customers through regulatory processing that's really an internal problem, not theirs.
Exactly — some people would call that shipping your org chart, where you have a team that only works certain hours and suddenly the customer can only get results during those hours. Whenever you see something like that, where your internal pain point becomes the customer's problem, it's time to reflect on what you can do better. Sometimes customers make that very clear to you. At my first hackathon demo, in Portland around 2011 or early 2012, a couple minutes into my pitch, someone with a one-character Twitter handle put his hand up and basically roasted me — his friends had built a project, which eventually became Timehop, that used SendGrid, and it had gotten blocked for spam on a shared IP. He wanted to know, mid-demo, how I was going to guarantee that never happened again. That moment definitely motivated me to go build a real relationship with the product team, because I wanted the job of selling shiny bricks of gold, not dealing with hecklers during API demos.
What did that relationship with the product team actually look like in practice?
It was tricky early on because there wasn't really a product team yet — DevRel existed before product managers did, by a decent number of months. So a lot of it was working closely with engineering and our three developer-founders, who were deeply hands-on with the product early on, and advocating internally for what we were hearing in the field. That's the thing people should understand about the term 'developer advocate' — you're advocating to developers, but also for them, and the 'developer' part can describe you as well. A lot of it comes down to taking real customer anecdotes, which in aggregate become data, and bringing that back to decision-makers — even better if you can tie it to downstream impact on retention or revenue. At one point I became the de facto product owner of SendGrid's entire API for about six months, while we worked out how to move from v2 to a new version incorporating years of field feedback. It took a long time to build that trust, but it's important that a DevRel team can eventually own and run parts of the product at a startup.
That clearly didn't put you off startups, since you later became the first developer evangelist at CoScreen.
I joined CoScreen last year — I think I was the eighth person on the team, very early stage. CoScreen is a collaboration tool for simultaneous screen sharing across multiple users and platforms — three people on a call, one on Mac, one on Windows, everyone sharing an interactive window at once, whether that's my IDE, someone's terminal, or a Datadog dashboard for debugging. It was a different challenge, since I'm used to representing things developers get their hands on directly, like an API platform, whereas CoScreen can be used for almost anything — we've seen people use it for music production, classroom teaching, and remote incident response, though pair programming and technical onboarding turned out to be where we found the most traction. It's less about showing someone how to install an SDK and more about optimizing how people work together and choose their tools — more of a go-to-market challenge, which is part of why I wanted it. The product had actually been built by a fully remote team, which is fitting for a remote-working tool. We got acquired by Datadog at the start of this year, which shifted my role again — now we have a lot more resources and other people who can take on go-to-market work, and we're integrating into the Datadog platform and figuring out the best use cases before reopening a public beta soon.
You've had a genuinely varied career. How did you end up in DevRel in the first place?
I was a software developer for 10 or 11 years, writing code for coal mines, gold mines, and power plants — a lot of stuff I don't feel great about in hindsight, partly because I was too young at the time to fully grasp the ethical implications of the tech I was putting into the world. Since finding developer relations in 2011, it's been refreshing to spend my time talking to passionate people solving real problems and helping them get better at that — which is fulfilling in a way that writing code for gold mines wasn't, admittedly a low bar. I've been fortunate to work at early-stage startups that IPO'd, ones that got acquired, and giant enterprise corporations, and to work with extremely smart, talented people at every step.