· 22:02
Jack Bridger: Hi everyone. This is Jack and you're listening to Scaling DevTools. This show, that investigates how DevTools go from zero to one. I'm joined today by Sarah Jane Morris, who is the senior manager of developer community at HubSpot. Thank you for joining Sarah.
SJ Morris: thank you so much for having me on Jack. It's lovely to meet you and, uh, feel free to call me SJ.
Jack Bridger: SJ at the earliest stages of startups, how should they be thinking about community?
SJ Morris: I think when folks hear community. They have sort of a vague understanding of what it might imply, but it feels kind of large and potentially intimidating. But I think specifically when it comes to the developer developer companies and developer tooling, it's kind of important to get yourself into the head space of a developer.
That's trying to build something and then understanding where community might be able to benefit that developer. and so in the earliest stages, when you're really just getting started, I think, getting to that MVP. When you're trying to get to that, I think feedback becomes such a crucial thing to get from developers. , there's always gonna be a set of developers that are excited about providing feedback on a tool that may help them, , improve their workflow. And, Basically build more quickly and more effectively.
And so if you can get yourself in front of a group of developers, try to really nail down that developer experience in their earliest stages, you know, with a developer community, it's really only gonna be as. effective as your developer experience is in the early stages.
You'll always wanna be focusing on developer experience to make sure, developers onboarding with your product or tool is as frictionless as possible. But in the early days, as you're trying to build out that community and get that sort of like, those passionate users and that momentum going, leaning into that feedback is extremely important. And not only that, but if you really wanna build a product for the long term, ensuring that feedback is coming from as many different kinds of developers as possible is also crucial. And I know that's a little bit easier said than done when we're starting products, starting companies, we tend to lean on our networks and our friends. But some of the time that can kind of introduce bias into the, production, process and the development process. And so, you know, there's a couple of different ways of going about that. One is in the early stages. Make a concerted effort to, get a different, a variety of skill sets, looking at to your, your product developers at different stages in their career, developers with different levels of proficiency. I mean, of course it's fine to remain focused on, a broad developer category that will, you know, fit the profile of what product you're trying to. But at the end of the day, if you want your product to have staying power and kind of like that long term growth, starting early and building in those diverse voices from the get go is gonna be a massive, like, differentiator for you versus all of the other developer tools that we see popping up everywhere. And I would say also there are, a handful of, companies that I'm aware. That provide some more systematic and, productized developer feedback, opportunities. One company is called HAXOR so that's H a X, OR, and it's run by Ian Jennings and Ian is fantastic. He. It's very similar to user testing.com.
He records videos of developers onboarding with a product and he outputs, the developer experience on a scale that's, got all kinds of different, sort of signals to, ensure the developer experience is, is. On par with the industry for that specific category. Ian is good too with, recruiting various different kinds of developers.
So if you're finding it a challenge to kind of, diversify your developer group from your own networks, then, um, using a tool like HAXOR, can be really, really helpful in those early stages. And then I would also say, really building the solid relationships with these early stage developers that you're getting this feedback from. You wanna make sure if you're going to build a long term active, passionate community of developers that are excited to use your product and excited to talk about it with their fellow developers, you just really wanna ensure that you're providing as much value as you can to this developer group, before you start to sort of extract more than you're providing.
So. You know, making sure the tool that you're offering, if you're not going through kind of an official, program, like, like Ian's and like HAXOR like, if you're just kind of building out your own networks, making sure that, the PR tool you're providing is going to be as. You're responding to that feedback.
You're iterating based on that feedback, you're making it as effective as possible for those developers and then, you know, giving them access to things like, you know, if they're also entrepreneurs potentially giving them time, like coaching sessions with, your founders or investors. Also providing them with, you know, it's always nice developers, I think still have some love for swag. I think we all have tons of t-shirts and stickers in our, uh, apartments, although maybe less so after the last couple of years, when we haven't been meeting in person, but, anything, that's sort of a distinct unique thing without overly, you know, you don't wanna overly incentivize a relationship cuz then that starts to take away some of the value of the quality of the feedback you get, but just reminders and tokens that you really appreciate the time that they're providing you. And that they are the early stage developers that are gonna make or break your product. And for them to know that is, , gonna keep them for the long term. Yeah, so that those are sort of the areas that I would say to consider in those early stages. And, and when I'm talking about early stages, those are the days before you have any kind of like formal community space.
I have some experience in this, working with a group of like 10 beta developers at my first, API startup back in Montreal in 2011. And. Eventually using those tactics to grow that group to, a thousand beta developers within a year. And so there was a kind of, a tipping point where we needed to look at, tooling and, how to, capture that feedback and relationship building in a more systematic way.
Jack Bridger: So once things start to get going, maybe you just mentioned you went from 10 to a thousand developers being in the community.
What kind of things would you be focusing on at that point?
SJ Morris: Yeah. So those days of, you know, us having 10 folks that were, you know, testing the product and giving us feedback, those are, you know, the days of honestly, like this is how this. Saul also shows you how long ago. This was like the days of Skype calls and phone calls. I'm like, , we weren't using zoom at the time. But once we got to sort of, um, basically what happened was once we started getting a little press, we were lucky to, um, it was a, a little startup called context IO and we were an email API and essentially we were. Simplifying the development, process of working with IMAP. So IMAP was an extremely sort of complex technology for developers to try to work around and, you're sort of like simplifying the process of. Pulling in all that metadata from, from email to the, our, our strongest or our most obvious use case at the time was, CRM integration. And so there was a moment we were fit, fitting, uh, luckily fitting quite a specific niche and a need, we got a bit of press, we, you know, got rid up in tech crunch.
, we, you know, had that tech crunch sort of like traffic spike. And so, it was, that was our opportunity, honestly, to take some of. that burst of interest and try to, turn that into a few more, , with every sort of press hit and every sort of mention that we would get on Twitter at the time. And you know, theoretically, Twitter's still a great place for that. But that would be, an opportunity for us to get some small percentage of that traffic burst and, get those folks into our, our smaller community and, and maybe at around hundred at that point. At the time we [00:08:00] didn't have as much. Access to, um, the kinds of community tools that exist today. But at that time we rolled out a forum. At this point, I would say, I would look at something a little bit more developer friendly. I think developers, and, you know, most of us these days are not that forum friendly forums feel a little outdated.
Forums are also quite a-sync and I think developers, especially when they're trying to get involved in a community in the first, the, first time they express interest in it's a com in a community it's usually when they're hitting some sort of development roadblock,
some sort of challenge. , exactly. And so they're like, I need answers now. , where do I go to find these answers? Like I've looked through all the documentation I'm stuck. I can't find this anywhere. I've Googled, I've looked through stack overflow. I'm not finding. , you know, a lot of times it may end at stack overflow with the question kind of jumping there, but if you have an active or even a beginnings of an active, [00:09:00] vibrant community space, a developer will join at that point and seek assistance, , from whomever may be there. and I can talk about that a little bit more in a moment. And I would say today, , leaning into a combination of. Really connecting those community tools with your documentation. So, for example, hub SW has a developer slack. I personally would not like going back in time. I wasn't the one who created that slack at the time.
It completely met the needs of our community and it made total sense for the, the awesome folks that set up that slack in the first place. But it has since grown to a point where it's just not sustainable. To keep up as a community space. I would look at places like discord. Discord is a much more community, centric tool.
Yes, it's coming off the gaming community, but I'm seeing more and more development, , communities being built on top of discord. It has a lot of moderation tools built in that are just gonna be so helpful for [00:10:00] you in the long term. And even the short term, as folks discover your community and you kind of wanna have a little bit more control on which channels they can access, who they can connect to and who they, you know, probably shouldn't have access to like. In theory, anyone who's in our HubSpot developer slack can be DMed by anyone right now. And like, that's a lot of power for folks and it's not always used responsibly and we have no visibility over that. And so, , that's just one of the reasons we could do a whole other episode on why, slack is not an ideal community tool.
It's a fantastic workplace coordination or a collaboration tool. , but a tool like discord, but then also being very mindful. , a more instant response and less AYQ tool is going to come at the cost of not having that knowledge sharing be, you know, search engine optimized, like it is in a forum. And that's one of the huge pluses for a forum. So as long as you're sort of building in that, like awareness that if you see the same kinds of questions being asked frequently, you add that to your knowledge base, learning from what the conversations are in those channels. but also kind of like ensuring that you're, in the early days it makes a lot of sense.
I think for you as a company, to be more involved in those conversations, you want that direct feedback. You're trying to probe for direct feedback developers that are eager to give that feedback. But in the long term, there's a slight, like a balance you have to strike. it, if you do that, if you build on that too much, then becomes this dependency where developers feel like, oh, I can ask the company a question in this space and if you stop, it just becomes another support tool and not a community.
And so that's why in the early stages, as much as you can facilitate conversations between develop. And have developers answer each other's questions and try to navigate through those tough situations together. Of course not every situation is going to be conducive to that because, sometimes you have to share your API keys.
Sometimes there's things that are just really private. But a lot of the times like developers that have gone through the same thing can really provide a quick fix for you. Investing in that, discord, I would say is probably the. The most kind of up and coming, tool that meets that need as long as you're really tightly linked with, , the kind of concepts and themes that are coming up, over and over and getting that back into your documentation as much as possible.
So you're really getting in getting that, SEO benefit.
Jack Bridger: Yeah, that's, that's amazing. And how. in terms of tangibly measuring how well you're doing, what kind of things do you care about?
SJ Morris: Yeah, that's a really tough one. and I know that any community professional or even a devel professional will agree that, , trying to identify the right sort of KPI. For the work that you're doing is really challenging because honestly, this is really long term work. It's work. That's hard to put direct numbers around, but it's work that, is essential.
If you wanna build a business that's successful in the long term and you wanna grow that kind of word of mouth advocacy, that is absolutely essential for developer based companies, even more. So I would say. Then, you know, your more typical kind of B to C type of company, , a developer company without solid word of mouth is, probably not gonna make it marketing strategies typically are just to me, developer marketing and developer community, there's like a real, it's a real blur. Um, and so that is one of the areas where we, we look at really closely is that word of mouth. how much can we measure that? It's a little trickier to measure because. You know, it's not like, Facebook is like, or Twitter are like the main places where Twitter is a place where you can measure some, some great word of mouth and some sentiment at the end of the day, I think for me.
And when it comes to community specifically, if we're just talking about that community [00:14:00] health metric, the one metric that I find most sort of. Indicative of, , how healthy my community is going to be in the long run is community responsiveness. And so when I say that that's really about peer to peer developer response. And so if we have developers who are going in and supporting their fellow developers, answering questions, And, getting the developers to resolution or even just continuing conversations, then we have an engaged community. We have a community that is like, you wanna see that number go up, but it all depends on other goals too.
I do think that one is a pretty sort of like, widely applicable. size of community and things like that. Those all gonna widely depend on your goals as the type of company that you are, how niche you are, what the expectations are like. I don't think, it's quality versus quantity at the end of the day when it comes to community. , and so. the way we do that currently. Like there's a lot of, there's so many community measurement tools popping up these days. I don't know if you've had other folks on talking about the orbit model. That is one way to measure kind of like how developers are engaging with communities.
We use something that's quite similar. It's called common. And common room is this really fantastic tool that provides really robust reporting around like overall sentiment across, different sources. So today I think we have stack overflow, GitHub, , Twitter, our own developer forums, our developer slack, and possibly some other sources that I'm forgetting. , they offer, you know, anything from kind of a roll up sentiment. Measurement for all of those, I find that a little less valuable because it's really hard to measure, compare like Twitter sentiment versus like GitHub sentiment, very different platforms, but you can really hone into the different, like overall external community spaces, and get a sense for the types of conversations that are going on and then really dig into what those are.
And then the coolest thing I think about common room is. you start to identify those folks that are out there talking about you and you can build relationships with them. And it really surfaces folks that you might not otherwise ever find in your own sort of anecdotal or ad hoc, community research, it does that in a really systematic way, and it does also measure community responsiveness really well. Again, that gets really tricky because for something like slack, for example, that is measured by. Posts that have like an actual reply thread. So there's a very specific way of measuring that, and that gets tricky.
So we say things like in our slack, like please reply to any question directly in a thread. Just to keep things, you know, a measurement friendly for us. That's not the most important thing. The most important thing is a good community experience, but it does keep things cleaner.
You're always gonna run into those sort of like technical, asterisks when you're trying to measure community success. So I also rely heavily on surveys and especially in the early days too, just to go back to, what those initial approaches are approaches are to a community. If. You're you know, in a position where you're inheriting a community or you're, you've got a group of folks that is maybe beyond just 10 maybe you're like at 50 or a hundred. That's a great opportunity to start to understand, where do they live? What community spaces they rely on. Are they on stack overflow all day? Are they looking for something else? Do they Google for their answers? What technologies are they most interested in? Are they like, primarily, depending on the tool that you have, like, I dunno, just arbitrarily, I'll say like, are they, react native developers?
Are they, like what, what do they Excel in? You can learn a lot about like what client libraries to prioritize, like, expectations around if, you know, if you have extensive APIs, like how to, structure those. And then also. there's ways to carefully do this, but start to get a sense of the demographics, if you're a community a little bit too. So you can make sure that, that, your, your checks and balances for diversity are there. And that can be again, a little tricky, but, there are lots of experts in this space who can advise. And one of the places I like to look for advice on that is project. It's um, an HR focused group of folks who have come together to try to make sure diversity is better at companies in the employment setting, but there's a ton of learnings in that project that you can extract to community surveys and, codes of conduct.
Those are absolutely crucial for community spaces. And I can't believe I didn't mention them till now. SJ, one more bonus question. When you started to answer the question about, metrics you mentioned at the beginning that.
Jack Bridger: Community is such a long term investment that it, it can be challenging with metrics and. I see this kind of challenge of startups where it's like they have the short term objectives they have to meet, maybe it's their accelerator telling 'em or the VCs that they've gotta meet a sudden growth week and week.
And a lot of the time, anything that isn't providing that is. Put on the back burner, but at the same time you see so many of the most successful dev startups invested in community really early on. And I wondered if you see a kind of a pattern or any advice you have for startups that are at that stage.
SJ Morris: Yeah, that is, I guess, kind of the eternal question, right? , when to invest in community versus not. And I think if I think about, , my experience and, you know, I guess these sort of like household name in, , dev tools that have community success, the company Twilio, I think of, the common denominator being we saw. At context, IO and Twilio clearly saw a really broad developer use case for both of those products. , and so, you know, interacting with email was a big problem, continues to be, you know, there's a lot more tooling around it now, but continues to be a challenge. Messaging and communication APIs.
That was a huge gap at the time. It had such broad applications. So if you look at, those two as examples, like Twilio clearly being the big winner in that equation, much loved to context IO, but, Twilio really, uh, has really taken, developer relations and developer community to the next level, I would say, yeah, that's the common denominator. And if you're a more niche product, if you're a dev tool, that's, only. Working on it with a very specific slice of developers, men, maybe doing it right at the beginning is not the most important thing. And you also have to consider long term, like you can only grow a community that's engaged when you have like a reasonable amount of volume in there.
And that doesn't need to mean a humongous community by any stretch of the imagination. But the goal of a community really is to kind of provide this like [00:21:00] moat for. Company in the long term, your community will kind of support you. It will provide that word of mouth. It will give you that source of feedback. But if you're doing something hyper niche, it may not be the biggest priority right away.
Jack Bridger: That's a really good answer. Thanks so much for joining us. Where can people hear more about you and your work?
SJ Morris: Thank you so, so much for inviting me once again, this was a really fun conversation. I love talking about these things that I could rabbit hole on lots of them. So anytime anyone wants to have a, rabbit hole conversation on any of these topics with me, hit me up on Twitter.
I'm at Sarah Jane Morris. I also tweet about all kinds of other silly things that have nothing to do with developer community. So you can enjoy those tweets. While you're at it. Anyone who wants to hit me up on LinkedIn, too, just search for me and I'll be there.
Thank you so much
Jack Bridger: Thanks for joining SJ and see you all next week.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.