Brandon is speaking at DevRelCon San Francisco 2019. Join us on June 6th and 7th for the developer relations conference.
Prior to his talk, we caught up with him to learn more about his dev rel story.
Tell me about your role at AWS
Brandon: I lead the Developer Evangelism team for the Americas region. My job is to help define the strategy for the team, ensure we’ve got the right measurements and processes in place to capture the value of what we do, recruit and hire, coach and mentor teammates, and lead by example by working in the field directly with developers. At AWS, we focus on removing customer pain points. As a manager, my teammates are customers and I spend a lot of time thinking about how to make their lives easier.
What brought you to this point in your career?
Brandon: I spent ten or so years as a developer doing everything from graphic and UI design through to systems integrations with mainframes. I wanted to do something with a new set of challenges while still using my experience. That lead me to my first dev rel role in 2011, as SendGrid’s first evangelist. That team scaled up, I became Director, and we began to take ownership of the developer experience. At one point, everything from the documentation to the SDKs to stewardship and design of the API itself was part of our responsibilities. Then I spent a year or so at another email-focused startup called Kickbox, where I helped out with product validation and a few other things.
After working at agencies, being self-employed, and then working at startups, AWS gives me a chance to dig in and get experience at company that works at scale. Scale in terms of the size of the organization, market share, and size of the addressable market; but also in terms of how we can help developers. At SendGrid, we had a narrow problem set that we were very good at helping developers solve. At AWS, we’ve usually got dozens of interesting services for anyone building things. It’s a new challenge for me and an opportunity to help a lot more developers build amazing things, and that’s a big part of why I’m here.
How does dev rel work at AWS?
Brandon: We’re always learning and refining our approach based on what our customers tell us and what we see our customers needing.
We have three regional teams; Americas, EMEA, and APJC. Most of our team members are generalists, but we represent more than 165 different services. Due to this expanding product portfolio, we are adding specialists in areas such as serverless, AI/ML, .NET, and so on. We also have some roles that focus on specific channels, such as our online evangelists that spend a lot of time streaming technical content and livecoding on Twitch. And, of course, we are hiring.
When it comes to metrics, the global head of our team, Adam FitzGerald spoke on this topic at DevXCon 2016. One of our charters is to raise awareness at scale.
What’s your dev rel philosophy?
Brandon: The short answer is to always give first. Help developers solve problems, and do so without expectation of return. Be empathic, humble, reliable, and authentic. The long answer is in the very overdue book I launched on Kickstarter in 2017 and hope to finish this year. (Thank you to all the very patient backers out there.)
What do you see as the big challenges for dev rel right now?
Brandon: As the number of companies employing dev rel teams grows, I see a lot of repeated conversations that are what I would call bikeshedding. I don’t think it’s fruitful to spend time debating the difference between advocacy and evangelism or the right general definition of “technical.” As external observers, we should resist retroactively applying our own definitions to organizations into which we have no insight. Instead, the focus should be on the developer and business pain points that each company’s dev rel team can help solve. Programs and technical teams should be designed based on those needs. Then, of course, there’s always the challenge of figuring out which backpack to buy.
What are you hopeful about?
Brandon: As the number of people working as developers continues to grow, the average tenure in the profession continues to drop. The increase in the number of junior developers means more opportunity surface area for developer relations programs, but more importantly, I hope that it also means more diversity within the workforce and an influx of fresh perspectives. We have a number of big scary problems facing us at this point in history. I remain optimistic that tech will be the way we overcome many of these problems if we can get the right minds interested and included in the industry.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?