Brandon Satrom is the director of developer experience at Blues Wireless. As an experienced leader with a background in strategy, architecture, software development and developer advocacy, Brandon provides unique insight on all things DX and DevRel.
In this Hoss Hangout, we talk to Brandon about the exciting frontier of developer experience, community and the importance of prioritizing developer success in all that DX and DevRel teams do.
- Brandon talks about what excites him about developer experience [:30]
- Brandon discusses the KPIs that are important for DX teams to track and what vanity metrics to avoid [3:42]
- Brandon shares his thoughts on what a healthy internal DX culture looks like and how to win executive buy-in for DX initiatives [8:01]
- The early hires and characteristics Brandon looks for in a successful DX team [14:53]
- One of the biggest misconceptions about DX, according to Brandon? That it’s not marketing. [19:23]
- “Obviously 500,000 visits to your docs is better than 5,000 visits to your docs, right? So in one sense, with early growth, that’s an important thing to look at. But once you get past a certain point, you need to look at not just how often are people hitting your landing page, but how often are they actually making it to the next step?”
- “Getting a strong communicator to create a learning path, to create the quick starts, to create the first tutorials, your API docs, what have you, even if it’s a person that ultimately evolves into more of a devrel or project engineer sort of role, focusing exclusively on the docs early on is pretty important.”
- “it is a misconception to say that devrel and devex is not marketing. I understand that folks that come from a technical background like myself may not like that, but the reality is that because developers are the ultimate decision makers most of the time, devrel is the most effective marketing there is.”
Today, we’re hanging out with Brandon Satrom, the director of developer experience at Blues Wireless. Brandon is an experienced leader with a background in strategy, architecture, software development and developer advocacy. He’s also a speaker and author of two books.
Matt Hawkins: Brandon, it’s great to have you.
Brandon Satrom: Thank you man, it’s great to be here. Appreciate you asking me.
MH: Yeah, absolutely. Well, there's a lot to cover. I’m super excited about picking your brain today. So we'll dive right in. I guess my first question for you is, you know, you're in this world of developer experience, this is what you do everyday, this is what you’ve been doing for a long time. What excites you about developer experience?
BS: What excited me the most about developer experience is that it is now at the forefront of the way that most businesses think about reaching their community, their audience, what have you. In many ways, it has become the new marketing in many ways. And I say that in a very positive way. Marketing in the sense that it is targeted at making sure that developers are using products that they love, are finding products that they love. It’s really all about serving the needs of the developer as opposed to just trying to trick them into using a product. So, the fact that developer experience has become the engine for growth for a lot of companies, from a lot of go-to-market strategies and what have you, even if it’s a company that’s ultimately targeting quote unquote “enterprises,” there’s still a lot of focus on developer experience as your way of really growing your user base, especially at the top of the funnel, and finding your audience. So, I think that’s great and I’m really excited about that aspect of it.
MH: Yeah, absolutely. And we hear all the time from companies that, they’ve noticed that over time that even their documentation, which they didn’t think about as kind of a lead channel at the top of the funnel, starts ranking in SEO if they do it right and they have a lot of content there. They get a ton of leads that way. But there hasn’t been sort of the mindset like, oh wait a minute, this is, effectively, like if we’re getting sign-ups here, this is partially marketing and we need to think about it that way, too. Obviously not be salesy from kind of an annoying standpoint, but more of a let’s be intentional about this.
BS: Absolutely, yeah. Yeah. Absolutely.
MH: So, jumping over to, I’m curious your thoughts on as you’ve seen developer experience change and evolve, where do you think developer experience is going? What does it look like in five years compared to today?
BS: I think what we’ll end up seeing is a lot of the trends, a lot of the things that are already in flight, especially the last couple of years around really choosing metrics that matter will be stabilized. I think we’ll find some industry best practices around the kinds of things that developers, that developer experience teams really use to evaluate themselves and really prove their value. Developer experience and developer relations, as sort of conjoined groups, I think do still struggle, especially with early businesses, of proving their value and showing that they make a difference and how they impact the bottom line. And even though the impact in a lot of ways is indirect, there are things that successful dev ex and devrel teams are starting to do that really do point to downstream value. That can actually point to the success of the sales funnel, that can point to stickiness and engagement among a self-service SaaS product and things along those lines. And so, I think even though every company may choose a different set of metrics, I think what we’ll see is a lot of the old vanity metrics are starting to cycle out, and a lot of the things that really point towards early developer experience and success and then stickiness of the product over time will really start to stabilize and we’ll start to look at those as this is proof that our product has legs, that it has value, that it’s worth investing in a dev ex and devrel team.
MH: Yeah. And it certainly varies from team to team, but I’m curious if, just thinking about kind of a B2B SaaS company maybe that is starting this effort, what are some of those KPIs that you would recommend them think about? You know, not knowing anything, just kind of talking about a generic example.
BS: Yeah, absolutely. The first thing to really think about is what is your goal for the developer’s first five minutes using your product, or visiting your site even? But really what it comes down to is getting their hands on with the product. And I know this is going to be a challenge for some companies, my company in particular, where we are a hardware and software company, so there is a physical component to it as well. But even with that, or if it’s pure software, there is value in thinking about what do we want the first five minutes to look like? What’s something that we want the developer to be able to accomplish within that time frame that at the end of it they say, okay that was cool. That was way faster than I expected it to be and I got something out of it, so now I’m going to try the next thing. Once you have sort of that initial hook, the next thing that I think is important for teams to pay attention to is what your sort of stickiness metric is over time. You can look at it in terms of cohorts, but, you know, what are the activities, what is an activity or a set of activities that you can really point to and say, that’s a developer that’s not just kicking the tires, but they’re actually using it, they’re trying to solve a problem. Not just, you know, they’re not just toying around, they’re actually starting to do something meaningful with it. I think those two things really, any team can apply the specific nouns and verbs based on their own product, but those two things will take you a long way towards the docs you build, the experiences you structure early on and how you report out the success of the efforts.
MH: And so what are some of the vanity metrics that you would encourage teams to stay away from as their DX program matures?
BS: So, you know, some of those things that I’ve tended to see over time, things that aren’t indicative of success, is a vanity metric. And those are those things like raw visits, right? There’s obvious ones and then there’s ones that can be a little bit subversive. The obvious ones are definitely looking at traffic to your blog, traffic to your site, to your docs, et cetera. Those things are nice, and it is important. I mean, obviously 500,000 visits to your docs is better than 5,000 visits to your docs, right? So in one sense, with early growth, that’s an important thing to look at. But once you get past a certain point, you need to look at not just how often are people hitting your landing page, but how often are they actually making it to the next step? Are they trying your in-browser tool? Are they going through your quick start and completing, not just starting the quick start but are they completing the quick start? And so those are important metrics to avoid, those just simple growth, you know, we get users in the funnel, we don’t really care what they are or how they act. And then the other thing, the other types of metrics that can be a little bit trickier to identify, are those things that may on face seem like valuable metrics, but may be an indication of a problem with the product. Like the number of forum requests you get. You know, forum requests are good, there’s obviously an aspect of community, if you see certain types of behavior and community where people are collaborating, that’s useful, but if you’re reporting on just raw forum request, you may be missing the fact that people are actually struggling with your product, and that’s why there’s so much traffic actually inside the forum itself. So, it’s important to sort of look through not just those quantitative kind of numbers, but really to dig in and find out what’s actually behind those metrics.
MH: Yeah. Get to the root issue. And I think that’s an interesting segue to culture. Because again, a lot of companies that we chat with, DX is new, they maybe are just starting to build a program, when we think about sort of getting to the root of things and DX’s role in an organization, what does a healthy culture look like within a company for developer experience? And maybe sort of a follow-up to that would be, how can teams make sure that they get the right executive buy-in to be successful?
BS: So, yeah, that’s a great set of questions. I would start by saying that I would hope that any team would have, the value of DX would be something that is, that starts at the top, ideally. Especially with a younger company. I say that, I’m a bit biased, but I’ve been at companies that have had it and hadn’t, and where I am now, you know, our CEO and founder, it’s very important to him. And he’s been in the industry for 40 plus years and has sold six, seven different startups, and every single one of those, you can point a throughline to the value of the developer experience culture at the company and the ultimate successful outcome for those products. Not just the exit, but these are products that actually had long, healthy, successful lives and vibrant communities. And so, having a CEO that starts with the idea of, I need DX to be an early hire, I need devrel to be something that we really pay attention to from the beginning, embeds that culture a lot. Because, if your CEO says we need to think about the developer and prioritize the developer, then engineering will prioritize the developer, then marketing will prioritize the developer, and what have you. And that really drives the culture a lot of ways, because I think that what’s critical, even if you have a CEO that may be a little bit on the fence about it, is having somebody at the leadership level that really strongly advocate for the company’s growth path really being paired with the success of the developers. If you can start from the beginning obsessing over developer success, you have a higher likelihood of long-term success as a company than if you just say developers are just a lead gen source to enterprise deals and we just want the bigger contracts, we just want the bigger sales and what have you. Or you know, we ultimately want to talk to developers, but then talk to the decision-makers, et cetera, et cetera. And that old school way of thinking, in reality, doesn’t map with the fact that developers are the decision makers, by and large. And so as you embed that, you know, and have those conversations among the early hires in the leadership team, the thought has to be that your ultimate objective is to embed developer success into your product and into your content and in your decisions. And that really goes a long way because then the cultural impact is your conversations aren't about bikeshedding one engineer's perspective versus a feature, or the marketing lead’s desire for a certain thing that that may lead to the better SEO or sales or what have you, but how it actually ultimately benefits and impacts the developer in a positive way. And once you have that, it makes my job as a dev ex lead just simple because everybody’s already asking that question.
MH: Yeah, that’s a great point. Top-down buy-in will really solve a lot of these problems, it will set the tone for DX. Do you have any other tips or recommendations on how DX can kind of work with other parts of the organization, with sales and marketing, and certainly there’s always a natural tension between groups, right? Even between sales and marketing that should be aligned, but marketing says we got a thousand leads and sales is saying they’re not qualified enough, and there’s always that rub, right? So, I imagine with DX, too, there’s a little bit of that. But do you have any recommendations for how to kind of best work with these groups?
BS: I think it starts with if you’re in a place where the common goal of the team is to prioritize developer success, then the next level up becomes a bit easier. There may still be some natural friction between, a sales team may want to make sure that they’re getting well-qualified leads, and they want to make sure that your DX team is driving the content pipeline that feeds into that. The natural tendency of the devex or the devrel team might be to say well, look, we’re creating content for developers, you guys just take it and do what you need with it. But the reality is, I think you can step back and ask, okay, what can we do as a DX team that not only serves our developer audience, but helps that sales team actually engage with customers or engage with prospects further down on the pipeline. One example that I like to give of that is around content and projects. And so, you know, my company works in the internet of things space, and so there is a lot of developers in the IoT space, but there’s also a lot of medium and large companies that are trying to solve problems in the IoT space. And a sales team really looks at a lot of use cases around IoT. They may come to you and say, well, we need an example of content that does X kind of thing, whether it’s, silly example, asset tracking or monitoring a fleet of devices or what have you. It’s easy for the dev ex team to look at that and say well look, we just need to build the things that attract makers and we’ll get reshared on Twitter and really get us good, organic social engagement. But a dev ex team that’s successful can look at those use cases and look at sort of the enterprise customer, who, by the way, is still just a developer, right? At the end of the day, they’re still a developer. Oh okay, well we can actually build something that’s appealing to a mass audience here, to a larger audience that we’ll share on social, but that still creates a throughline to this enterprise sort of problem. Because a lot of times the tools and technologies that we’re building with, whether it’s software or hardware, or both, the tools that you use for building hobby projects, that you use for building things that you share on social media, are the same tools that developers and enterprises are using to build products that are solving their companies’ problems. And so, a lot of that give and take tends to be, in my mind, to go back to your original question, not about the dev ex team trying to twist the arm of the sales team and just deal with what they create, but to think about how to meet the needs of that team while still prioritizing what the developer needs and what they look for. Because the side benefit of that prioritization is that when a developer sees that social product, they will very easily create that mapping to the problem they’re trying to solve with their company. And that has the real ultimate benefit, because that engagement for the sales team down the funnel becomes easier for them to just talk through, to reference and what have you. So, that’s just one example, but a lot of it really comes down to thinking about how to meet the needs of those internal stakeholders, but still, again, if you have that common ground of prioritizing the developer, it’s really easy to get there.
MH: Yeah. For sure. So, for teams that are kind of just starting this initiative, or maybe rethinking it, maybe they’re making their first hires, they’re thinking about, alright, here’s what I think sales needs, here’s how I can partner with other parts of the organization like marketing as well. What are some of those early hires that you look for? I mean, you’re talking about building out content and a couple other things. Is that where you kind of first go? Let’s bring in technical writers, let’s build up some editorial, or what is, how do you think about that? And certainly, it could vary from company to company, but kind of generally speaking.
BS: Yeah, it absolutely does. But I typically tend to, especially, you know, smaller companies and startups, you have to get folks that are generalists and, as we like to say, can wear as many hats as they need to. But I definitely am a little biased towards early hires being folks that have that unique mix of being a strong communicator, if the product is quite technical, I don’t think that technical ability is absolutely critical for devrel and dev ex on the whole, but I think for first hires it helps if you’ve got somebody that has enough technical know-how that they can mess with the product and get dangerous and get in there and do things. But strong communication is a number one. Number two is somebody that actually has empathy. Even if they are an engineer, somebody that can actually see themselves as a developer. And even if they’re not, once they actually get embedded and they understand the products that they never forget what it’s like to have that beginner’s mind, to get in there using that thing for the first time. And so, those two things, strong communication and empathy are the qualities that I tend to go towards. And in terms of the specific roles, the first couple of hires that I like to make are content-focused. So, especially as you’re starting from zero, building out docs, building out API, so much of a developer’s first experience with a new product is going to be self-service. You may never hear from them. You may never know that they visited your site other than seeing them in the aggregate with a hundred thousand others or what have you. And so, providing, you know, getting a strong communicator to create a learning path, to create the quick starts, to create the first tutorials, your API docs, what have you, even if it’s a person that ultimately evolves into more of a devrel or project engineer sort of role, focusing exclusively on the docs early on is pretty important. And then from that point, I start to look at devrel and project creation. So, people that are building demo projects, building sample things, working across technology. So not just building with your stack, but working with other complementary stacks, working with cloud providers, working with front-end stacks, depending on the kinds of problems that you’re trying to solve, but a generalist engineer that can, in the case of my company, a hardware company that can go from hardware all the way to building a website that visualizes data on devices, is an important skill. Those two hires are really critical. The third, and I’ll end on that one, the third that I would add is a developer marketer. So somebody that can really help make sure that your SEO focuses in the right place, that you’re thinking critically about how you create content. I think one of the things, I’m an engineer by background, and I think a lot of things we as engineers don’t necessarily always think about UTM tracking and making sure that, you know, we post stuff and we just think, oh, we’ll just get it up on Twitter and it’ll be fine. But we don’t think holistically about no, we need to make sure that we’re intentional about everything that we share so that we can trace it, so that we can measure it. So having a technical marketer that helps drive the team’s content publication can be really valuable as well.
MH: Yeah, those are some great points. Related - alright, you’re building a team, you’re getting top-down buy-in, what are, I’m just thinking about the road bumps that teams and individuals might face, what are some of the common misconceptions about developer experience that you wish would be cleared up?
BS: There are two. One I kind of hinted on a little bit already, and that is that technical ability is the most important thing. I think especially as products get more embedded and as teams tend to grow, but even from the beginning, technical ability, regardless of how complex your product is, is not nearly as important as empathy. I would take a person with empathy and the ability to understand our developers and our audience over somebody that understands the product in and out, but cannot conceive how someone doesn't understand this particular API or something along those lines. There are so many times in my career that I’ve been floored by talking to a developer in the community who will say, oh, you guys really should have had this in your product. And I think your natural reaction needs to be why didn’t we think of that? As opposed to, well, why didn’t you do this? So, having that is probably the biggest misconception. And then the second thing that is a bit of a misconception, and I’ve been guilty of thinking this in the past, but it is a misconception to say that devrel and devex is not marketing. I understand that folks that come from a technical background like myself may not like that, but the reality is that because developers are the ultimate decision makers most of the time, devrel is the most effective marketing there is. Devex is the most effective marketing there is. Because it’s less about messaging and convincing someone, it’s not Mad Men style marketing. It is showing someone the value of your product, helping them solve a problem, and then of course they want to use your product. And if you give them something of value, developers have no problem paying for it. But devrel and devex are marketing in that sense because what they’re doing is they’re giving your company a vehicle to really grow its audience and grow its opportunity to be self-sustained. And to obtain revenue. So those are the two big misconceptions.
MH: Yeah, those are great. No, they need to realize that yes, the M word can be a little dirty sometimes, but we need to put that aside for a second and just look at the literal definition and that will kind of help…
BS: You’re right, yeah. The literal definition is literally just taking your product to market, right? Just being able to say like, this is here.
MH: Yeah. Precisely. And one follow-up comment on the first one around having empathy and being open to these changes and having that sort of “yes and” be your natural reaction, I’m a big fan of this idea that, I think some of the best teams and even sort of just generally group interactions like with customers mirror improv groups.
BS: Oh, yeah.
MH: Improv groups, like, what is there, two rules? One is you always start with “yes and,” and the other is it’s all about the group. So if you’re not starting with “yes and,” because it’s so easy to be resistant or shut down ideas or push back or whatever, everybody can do that all day long, but to get to the root of what a customer is talking about. Because they might be saying something and what they’re really saying is 10 layers deeper and you have to get to that, but if you’re not “yes and,” you’ll never get there.
BS: Absolutely, yeah. That’s so very true. I love that.
MH: So, jumping around a little bit here, I’d like to talk about community for a few minutes. How do you feel about community, what is community’s role in developer experience?
BS: I love the rise of community as part of how companies actually engage with their customers and find developers, partly because it solves, you know, developers are drawn to companies when they feel like the company cares about their problem and wants to help solve it. But they’re drawn even deeper and they’re more engaged with a company when they meet other developers like them. When they meet developers that are not part of that company that are trying to solve a similar problem. Someone that they can pick their brain, you can find them, you can talk to them, you can understand what it is that they care about. Find opportunities to collaborate, what have you. But it’s really about how developers find each other and exchange ideas in this case, you know, a good community built by a company is really, the company is just the facilitator. You’re just the arbiter. You set up the URL, you've put up the portal that allows them to be there, but you're ultimately giving them a place to drive what matters and what conversations are important. And I think that’s a powerful thing. It absolutely has been for years, but it definitely has been in 2020 as more and more communities have been online almost exclusively.
MH: Yeah absolutely. What are some, if folks what to go look at some best of breed examples, any communities come to mind that you would point people to?
BS: Yeah. As I was giving you the answer, one of the ones that I thought about that I really like is Auth0. Auth0 has a great developer community. Theirs is very much focused on a discourse server, so it’s a very forum asks sort of back and forth community, but it’s one that I really like. And it’s quite engaging around a purely software product. For anybody that’s listening that’s more in the hardware, maker side of the world, Adafruit is an amazing, they have built an amazing community. Their community is actually up on Discord, and they have thousands of people that are live all day, every day, sometimes using Adafruit products, sometimes just talking, chatting, you know, finding an opportunity to reach out and talk to other people in the maker world. So those are two examples that I really admire.
MH: Awesome. Beautiful. Well, we will definitely link to those in the post. So, Brandon, this has been fantastic. My last question for you, any parting thoughts, words of wisdom for our viewers? Also, where can they find you online?BS: Great. Parting thoughts, you know, developer experience, if you have an opportunity to really think about dev ex and be in the dev ex world, embrace it, enjoy it. It’s so much fun to eat, sleep and breathe solving developer problems. And if you ever have any struggle communicating that to the company, communicating that to your leadership, I would always, I’d just admonish anybody to just start with, laying out there to your leadership, to the folks you’re working with, do we care about prioritizing developer success? And if you can drive to a place in your company where the success of one developer matters, then your company will have a lot of success. Long-term. And so that's my only, my only parting thought there. In terms of where I am, I’m on Twitter at Brandon Satrom, all one word, no punctuation. And then my infrequently updated blog is at BreakingThings.io. So, feel free to reach out via Twitter if you have any follow-up questions and need any further advice, I’d love to hear from you.
MH: Beautiful. Thanks a lot, Brandon.
BS: Thanks, Matt.