Encouraging Developer to Developer
Collaboration & Support: Transcript of April 17th Workshop
This is a transcript of an online workshop hosted by Vanilla Forums on April 17th, 2019. You can view the recording here. The transcript has been lightly edited for readability. I’ve highlighted important takeaways throughout the transcript, and added links where appropriate.
Adrian: Welcome to Encouraging Developer to Developer Collaboration And Support in Your Community. First off, I'd like to introduce myself. I'm Adrian. Some of you may know me, some of you may not. I'm the voice you've been hearing up to now. I'm the head of community at Vanilla Forums, and if you don't know, Vanilla is a hosted forum platform used by many companies to connect with their communities. It's also used by lots of developer communities. Just a small taste of the customers using our platform include the Linux Foundation, Xamarin, Oculus, and many more companies looking to build a space with their developers.
We also like to focus on educating and supporting the community of those building those spaces. So, with that in mind, we're so happy to introduce our guest speaker, Sarah-Jane Morris, or as many know her, SJ. Now, before we jump into today's topic, let me tell you more about my friend Sarah-Jane. SJ is the founder and principle consultant at Listen Community Consulting. She spent six years in San Francisco building inclusive developer communities at companies like Mashery, Intel, Keen IO, and most recently, Shopify.
Prior to working in San Francisco, SJ spent nine years in Montreal, my lovely hometown, working on marketing, community, SEO and branding at both B2B and developer-facing companies. She's driven by an audacious vision of diverse and welcoming tech industry, and believes the most inclusive communities take the time to listen and learn from each other. We know this is a very popular topic for anyone in the space, so we're very glad SJ is here today to share her wisdom and the wisdom she has from her friends that she's gotten.
So, without further ado, it's time for you to take it away, SJ. Thank you for being here.
Sarah-Jane: Great, fantastic. All right. Again, thank you so much, Adrian. I'm super excited to be here today. As Adrian mentioned, I'm going to be talking to you about how to encourage developers in your community to collaborate. I'll talk a little bit about the benefits of this kind of collaboration, the opportunities to encourage collaboration within your community, when to step in to support collaboration in external communities, and how to set the stage for an inclusive, collaborative developer community from day one. All right, cool. I'll just extend a little bit of the awesome, lovely introduction that Adrian did. Again, I'm Sarah-Jane Morris, and please feel welcome to call me SJ. I've been developing communities for companies of all sizes since 2004, but I've been exclusively focused on developer communities since 2011. Again, I developed communities for companies like Mashery and Intel. I worked with an amazing team at Keen IO, and most recently I was really privileged to be able to lead Shopify's developer community efforts.
I left Shopify in January of this year to kind of take the plunge and become my own boss. I'm driven by the desire I have to see developer communities that I work with not only grow, but become more welcoming and diverse. I want them to be more inclusive, and ultimately more active and sustainable in the long term.
I'm especially eager to see developers communities diversify, because developers are our builders. They're building the tools of the future, and by building welcoming developer communities one community at a time, my wild hope is that the products that these developers build will be accessible and built with all kinds of different humans in mind. (Click to tweet)
So, I'm committed. This leads me to today's topic, helping all kinds of developers to feel welcome and safe to collaborate in your community.
All right, so, as Adrian kind of teased, I was really lucky to speak with a bunch of my developer facing friends, folks that I really admire, all about how they encourage collaboration in their communities. They all gave me some amazing tips and shared some really practical and fun stories.
And so, with all of that, here's what we're going to cover. We'll talk about the benefits of collaborative developers. Why do we care so much about having our developers support each other and work together in our communities anyways, and what can that look like?
We'll talk about when to participate in developer conversations, and when to lay low. It can be tricky to determine when you as a devrel, technical community manager, or any kind of company representative should jump into your community and participate, and when you should let your developers hash out and collaborate amongst themselves. I'll walk through the different approaches that companies like Shopify, Slack, Atlassian, and Stoplight use.
We'll talk about engaging in external communities. How much should you pay attention to communities that you don't lead. Developers are found on communities like Reddit and Stack Overflow, but does that mean that you and your team should be monitoring and jumping into those communities, as well?
Finally, we'll spend some time talking about how you can encourage developer collaboration in a brand new community, what frameworks need to be in place, and how you can actually get the conversation started.
Here is the panel experts that I consulted for today's workshop. I spoke to Neil Mansilla, Head of Developer Experience at Atlassian. I spoke to Taylor Barnett, Lead Community Engineer at Stoplight. I spoke with Elizabeth Kinsey, Developer Marketing Manager at Slack, and finally, Liz Couto, Developer Product Marketing Manager at Shopify. Again, they gave me some great tips and fun stories, and a huge thanks to each of them.
All right, so, before we get started, the word collaboration can be a little vague, so let's get our heads around this word in the context of today's workshop before we dive in. Collaboration generally refers to folks coming together in some way to do a thing. Typically, this thing has a positive outcome. So, what can that actually look like in the context of developer communities?
Some of the types of collaboration that came up in my interviews, and also in my experience building communities, include developer activity on your proprietary online community or forum, troubleshooting together and answering questions, code fixes, and providing general inspiration and support.
In-person events are also an extremely important outlet for developer collaboration. They typically set the wheels in motion for further developer projects they can inspire after a good old fashioned chat or a good old fashioned demo, and so we'll get into some of those examples.
In-person events are also an extremely important outlet for developer collaboration. They typically set the wheels in motion for further developer projects they can inspire after a good old fashioned chat or a good old fashioned demo. (Click to tweet)
Finally, community mentorship and sponsorship… when developers are eager to share their skills with up and coming developers, or they actually actively seek out and connect new developers to opportunities for them to shine and grow, and we have some great stories to share with those, as well.
All right, so, with all of this talk of collaboration, why do we actually want to encourage it?
Community member interaction and collaboration is a strong health indicator for any community, but it's an especially strong one for developer communities. If you think about what the essence of a community really is, folks gathering around a common idea of interest, and the essence of what developers do, which is to build, it makes sense that developers coming together to support each other building will have a ton of great outcomes. (Click to tweet)
Some of the great outcomes that came out of my conversations with the panel of experts include a healthier overall ecosystem of apps and integrations within platforms. A decrease in devrel support debt. An increase in developer resources, so things like plugins, and even more pull requests, and contributions to your open source projects.
Neil Mansilla, Atlassian's Head of Developer Experience, shared a story with me of spontaneous collaboration that happened during a recent Atlassian App Week, a yearly offline community event for Atlassian's top app developers. So, without prompting, these Atlassian developers came together at App Week and started doing integration tests with each other's apps. The apps already worked great on their own, but problems were starting to emerge with Atlassian customers using multiple apps at once, so Atlassian's developers took it upon themselves to gather at App Week, not only test multi-app integrations, but they also started releasing testing frameworks for the rest of the developer community to leverage. And this is all in the name of a faster and healthier platform for Atlassian.
Neil had a great little quote around this. He said,
"These devs are all about having a healthy ecosystem, because it takes just a handful of bad app experiences to spoil it for a whole bunch of other people. I think that is the ethos here. Let's give back and make sure that this comes along smoothly for everyone." - Neil Mansilla (Click to tweet)
A sure sign that your developers are collaborating is when they take it upon themselves to create their own dedicated community space to work through their own discussions and help each other solve problems, resulting in less support questions for your devrel team. This was the case with marketplace vendor developers at Atlassian. They created their own Slack community as a place to hash out relevant topics away from the watchful eye of the company.
This community-led Slack group is so exclusive that even Atlassian employees are not invited. And to quote Neil again, "We are not invited to it because they want to feel like they can speak openly without reprisals. I haven't asked to be part of it, because from what I understand, it's healthy."
This external community actually allows developers to work through problems together, with zero expectation of Atlassian's involvement. That takes a significant load off of Atlassian's devrel support function. (Click to tweet)
As mentioned, I spoke to Taylor Barnett, the Lead Community Engineer at Stoplight, which is a platform that helps developers build, test, and improve their web APIs. As opposed to Atlassian, Stoplight is an early stage startup, building out a blossoming developer community.
So, a developer collaboration win happened for Taylor when a member of the Stoplight developer community built a Jenkins plugin for the rest of the community to leverage. This developer in question actually holds a day job as a software architect, so the fact that they chose to give back to an early-stage tool, this implies a really commitment to Stoplight and its future.
The more you create a supportive environment for your developers, the more likely it is that they're going to want to give back to it. If your community fosters, showcases, and support problem solving, developers will feel more inclined to collaborate with their fellow developers by sharing their own solutions. (Click to tweet)
Finally, just because a developer community collaboration doesn't directly impact the overall speed and scalability of a platform, or turn into a developer tool, doesn't mean it actually doesn't have tremendous value.
When I spoke to Liz from Shopify, she shared a great example of a Shopify dev that builds custom store experiences mainly, but also loves building apps, but hasn't had a chance to be as involved with them lately. Those custom store developers actually ended up finding, through Facebook groups, some wonderful recent university graduates within the community who were just getting started to build with apps, and they actually chose to mentor them.
Shopify often sees developers that have the skills and interest in one part of the platform, but no bandwidth to execute on them, actually helping out developers in other parts of the platform. They kind of want to live vicariously through other developers by supporting them as they grow.
All right, so, now that we have a better grip on what developer collaboration can actually look like and how it can benefit your community, let's jump into when you should step back and try to let it happen in your community, and when you should jump in to ensure developers aren't blocked and have what they need to keep building.
No community can rely on its members alone to constantly collaborate to support each other. There's a time and a place to let conversations and interactions run their course, and a time to jump in and help out. Everyone's going to have a little bit of a different approach to that, depending on their company, but there are definitely some best practices to share.
The first thing that absolutely must be established within your developer communities are your product channels. Where are developers going to hear announcements? Where can they discover new APIs, new libraries, new SDKs? Where do they learn about deprecations? Where is that mission critical information that they need to build?
It's essential to make this information easy to access and consistently available. Don't move your change log around your website too much. Send your developer newsletters with things like consistent subject lines at similar times of the month or week, whatever your cadence may be.
Creating consistency will minimize ambiguity within your developer community. Giving your developers space to collaborate on how they can improve the performance of their app, or to get feedback about their integration ideas, for example, instead of asking each other where a doc is, or what the status is of a specific endpoint. (Click to tweet)
It's also important to make it crystal clear where your team actually answers questions, versus where they don't. Atlassian and Slack's devrel teams are actively monitoring Stack Overflow, for example, whereas Shopify and Stoplight have more of a look but don't touch policy around Stack Overflow. We'll talk about those external communities a bit more in a bit, but no matter which community channel your team prioritizes, make sure you stick to it.
Now, once your team knows where they should be seeking to participate and answer developer questions or engage with the developer community, program it. Atlassian's devrel team have forum participation as a daily to-do on their Trello boards. Atlassian's team will give fellow devs an opportunity to answer first, but if a question isn't responded to within 24 hours, they'll jump in, according to Neil.
Liz from Shopify told me all about their brand new Distance to the Frontline program. All members of Shopify's Platform product line, which my team was when I left Shopify. The Platform product line is a group in the hundreds. It consists of developers, product managers, partnership folks, biz dev, all kinds of folks, and everyone is required to spend at least a couple of hours with a Shopify platform developer each month, whether that be at a community event, shadowing support, or any other kind… whether that be at a community event, shadowing support or any other kind of community connection touch point.
Elizabeth Kinsey explained to me that in Slack's case, developer channels like Stack Overflow are managed through an internal integration. Perhaps unsurprisingly this internal integration is a Slack channel called “Slack Overflow”, so it consists of the of the channel being populated by Slack's DevRel team. So they all live there all day. And whenever a stack overflow question is tagged with Slack, the team has the ability to see it quickly and respond quickly.
All of these different company mechanisms set up expectations throughout developer communities of when they'll hear back from a company representative versus when they should try to collaborate to work out amongst themselves.
All right. The touch points that we've mentioned thus far; online communities and forums, Slack, in person events… these are all par for the course when it comes to community outlets, but I do have a few examples from some less likely community touch points. Neil at Atlassian stressed the importance of developer community sentiment measurements through docs. Although docs can be seen as more of a one way channel, most docs do have some light feedback mechanism, whether it be smiley faces or a quick feedback mechanism tool. And developer frustration and community sentiment can actually be reflected in this touch point.
Shopify and Slack mentioned the importance of email, specifically mentioning their developer newsletters in our conversations. They talked about how newsletters may be a one-to-many channel with a one-to-one response model, but these newsletters and their information and topics can inspire developer chatter and collaboration in other community outlets, such as forums and events.
Finally, Taylor from Stoplight which as I mentioned is a little early on than Atlassian, Shopify or Slack, talked about her transitional community experience of trying to move developers from their Intercom support channel. (And for those who don't know, Intercom is an onsite messaging support tool that is really fantastic but decidedly one-to-one.) So Taylor was talking about moving folks over from getting support through intercom to getting it within the forum so that others can benefit from seeing the questions and answers.
Intercom's data showcased the kinds of questions that developers wanted answers to. So Taylor considers it that data to be a really important community collaborations signal that she's working on transitioning over to a more public space, the forums, as Stoplight grows.
All right. We've talked about them already a little bit, but let's dive deeper into best practices around external communities like Reddit, Stack overflow and even GitHub. So how do companies like Atlassian, Shopify, Slack and Stoplight approach these communities?
First of all, Atlassian and Slack both stress the importance of setting up basic alerts. Neil from Atlassian uses a combination of Google alerts and alerts he set up directly from Stack Exchange, the parent site of Stack Overflow, and I've already touched upon Slack's integration channel for Stack Overflow.
These basic alerts save teams from needing to parse through endless forum chats and quickly identify the questions that they could help support versus the ones they'll leave to the community to tackle together.
Elizabeth from Slack mentioned to me that they don't have a hard and fast rule about when they'll jump into Stack Overflow, but they'll follow general trends around developer interactions with their questions.The trends that they've noticed lately with community questions that are tagged to Slack include a lot less beginner questions than previous years and more specific questions and perhaps in Slack's case, this is a reflection of their consistent developer product information channels as well as their maturing platform. They've also seen questions being answered by community developers much more quickly, so they've learned to ease off answering the questions too quickly themselves. Basically a lesson in monitoring trends.
And all of the companies I spoke to monitor Stack Overflow in some way as an indicator of developers sentiment, but Slack was actually the only one who uses it actively as a support channel.
All right, so we'll talk about some of those other outlets now. So Liz from Shopify told me that her team monitors the main external dev communities like Stack Overflow and Reddit. And in Shopify's case there are a number of Facebook groups that are developer run that are fairly active. But she also proceeds with a high level of caution when deciding whether or not to participate.
Says Liz, participation creates expectation, which I think is a really important point to notice. So once you've dabbled in responses in a specific community, but then you suddenly drop off, you'll really impact developer trust and dilute the importance of your sanctioned communities where developers can expect to get an official company answer.
Also, Stack Overflow and Reddit don't honestly have the best track records for always being inclusive and welcoming. So making either of them a solely relied upon community channel comes with a little bit of chance of taking on some of that negative sentiment. Also, generally speaking, it's always worth noting that with developers, no news is good news. If they aren't hitting any roadblocks, you probably won't hear about it.
All right, so let's continue on that theme a little bit. I hope that I've reiterated enough times now about how crucial it is to be consistent with your official developer community channels and response flows. If your developers don't feel that they're getting the help they need from within the community, that's when you'll hear from them outside the community.
Developers will absolutely take it to Twitter, to company support channels outside of DevRel, to Reddit and to Stack Overflow when they're frustrated. This can give developers considering building on your platform pause and deplete your community trust battery. That being said, every developer community is on a journey, navigating its own highs and lows. And Liz from Shopify shared a great story to reflect that.
So one feature that Shopify developers have been asking for for years literally has been the ability to respond to merchant reviews within the app store of their apps. Shopify developers had been up in arms about this for so long, but there was a years old and still active Reddit thread all about it. So Shopify monitors but typically stays off of Reddit. So they were aware of the thread and a couple of months ago Shopify's platform team, to the excitement of many, finally released the ability for developers to actually reply to merchant app reviews and the community actually took upon themselves to update this contentious Reddit thread. A happy ending and a demonstration of community commitment through thick and through thin.
All right, so we've covered some of the approaches to handling communication and collaboration in more active developer communities. So what are some of the best practices to spark collaboration in new developer communities?
When I asked Neil, Liz, Taylor and Elizabeth for their top tips for new developer communities just starting out to try to put the building blocks in place to foster collaboration, they all agreed that spending time talking to any remotely engaged devs at an early stage is crucial. It sets the stage for trust building, a crucial factor in ensuring your developers will want to grow with your platform and help other developers grow within it as well.
Everyone I spoke with not only spoke to early stage developers often, they also connected them to other early stage developers to encourage collaboration a little more intentionally from the start. They also kept these early stage developers in the loop with any and all product iterations, including full pivots, and several of these core developers are still active leaders in the respective communities as a result of this early stage relationship strengthening.
Now talking to your devs is so crucial, but you really can take it to the next level by asking them targeted and specific questions. That can result in getting the direction that you need to build out your product and create a set of tools or APIs that developers will want to collaborate on.
Again, this act of asking questions, be it through one to one conversation or surveys, will help to fill that early stage community trust battery that will not only ensure your developers feel safe to build and create in your community, but they'll feel better about their fellow developers within the community, which will increase the chances of collaboration.
In these early stages (and always) it's also crucial to ensure that you're speaking to as diverse a subset of developers as you can, both from a demographic and technical skill perspective.
In order to gather the kind of feedback you need to grow a safe and inclusive community with really truly a community with staying power, intentionally connecting diverse developers with your wider community in the early stages will also enrich your collaborations to potentially build powerful integrations and relationships in the long run. (Click to tweet)
Now, if you're lucky, some folks that are just naturally helpful will be early and enthusiastic members of your community. If you want to increase the odds of that happening, make sure that you create and widely share a solid code of conduct with enforcement planning from the get go. This will ensure that the kinds of developers that emerge in the early stages of your community know that in order to share their knowledge, they must do so respectfully. Far too often in my experience, communities that did not launch with strong codes of conduct grapple the challenge of the quote unquote knowledgeable troll, a community member that knows your API or your platform or your tools inside and out, and is extremely active on the forums, answering questions. The only problem is they can be dismissive and rude. They sure do answer a lot of questions though, but at what cost? Stating your desire for a safe place to collaborate from day one can avoid such challenges.
Okay, great. So now that your developers have a safe place for helpers to grow, help them do it. Showcase these helper developers in your blogs, at your meetups. Give them lots of opportunities to be recognized and rewarded for being awesome. This will hopefully inspire the rest of your community to do the same.
So I'm going to wrap up a little bit and walk through some of the takeaways from today's workshop. So we talked about some of the benefits of collaboration within your developer community. We talked about how the outcomes can include healthier platform ecosystems and app collaboration. We talked about how collaboration can really decrease support debt across the company, but more specifically within DevRel. We talked about how developer community collaboration can result in increased developer resources and we talked about developer to developer inspiration and mentorship.
All right. We talked a little bit about how to actually set the stage for that collaboration. How and when and where. I stressed, I hope, the importance of consistent product update channels, really hammering home where the information can be found and where to expect answers. We talked about Shopify's distance to the frontline initiative as well as how other companies approach spending time with their developers to get necessary feedback and build that community trust.
We talked about making sure you consider more unexpected developer touch points and we talked about the simple act of setting up alerts for Stack Overflow, Reddit and other communities to save time so you can monitor and be aware of sentiment but not necessarily have to participate in those external communities.
And when it comes to external communities, we reiterated that it's important to proceed with caution in external communities like Reddit and Stack Overflow that tend to be less inclusive and can they really impact the trust battery of your developer community. We talked about how when you're hearing a lot from external communities, this can signal that there's frustration spilling over from inconsistencies within your sanction to product update channels.
All right, some tips for getting collaboration rolling. We talked about how a new developer community is talking to early stage developers and building strong relationships with them is crucial. Not only that, but to actually ask guided questions, whether that's through a structured survey or through one to one conversations where you're gathering the same feedback from different developers. And making sure that you can respond where appropriate. And then we talked about nurturing the natural helpers, putting the framework in place for responsible help and for a safe community, getting the knowledge sharing that they need.
All right, so that's basically it for today. I want to thank everyone so much for joining us and for listening in to the recording. If you're listening a little later, these are some ways that you can contact me. Various points of contact on Twitter or email. I won't read through the blurb about my consultancy, but I do hope you all take a look when you have a chance. If there's any interest in getting the ball rolling with some inclusive developer community building for your company. Thank you so much everyone, I'll hand it back to Adrian.
End of workshop
Information about Vanilla Forums
Adrian: Hey. Okay, thanks SJ. That was marvelous. It's a lot of good stuff there to think about. Here, let me just grab the screen back. Here we go. Hopefully you can see my screen. So I'm just going to give everyone here just some information about Vanilla for those that don't know about us, and also give you an opportunity to ask your questions using the Q&A panel. So we'll get to that right after this. And I promise I won't take too much time, but like I said, always worth giving you just some information about our company.
So for those of you that don't know, and I think you kind of covered about the importance of community, so we offer obviously a community that you can have as your own, which you can use to engage customers or developers and you can empower advocates, reduce costs with support or drive loyalty. And the great thing, of course, it being on your own platform, you kind of have a bit of more control over the rules and functionality that go with that as well.
Speaking of that, we also have a seamless integration aspect to our product, which is really great in terms of, this is an example of Microsoft Hololens. We power their community. And you can see on the far left is one of the Hololens. And we brought those design elements into the form, which is in the middle, using SSO, of course, as well, so that they don't need to create a separate login into the community. It makes it a seamless experience. And then finally, if they have an opportunity or something they need to pull into Sales Force, they can do that with one click. We have a lot of integrations. We have integrations with GitHub, we have an integration with Zendesk. So we make it really easy that if your community has a discussion that you feel should go to GitHub, let's say it's an issue, or if there's something that needs to be created as a ticket, it's very easy to do as well.
Next, and I think something as well that also stands out, or has something as a difference for ourself, is our SuccessTeam. So our SuccessTeam is more than just support, like, "Oh, this is broken," or, "I can't figure out how to do this." This is more about making sure that you're successful. Certainly it makes sense, right, the team, and the term SuccessTeam. It comes with three components: Training, launching and growing.
The training aspect of course is that we'll do a special training tailored to you, on-boarding you, teaching you all about the software and best practices for community management. Launch, we'll take care of any migration, and we'll work with you on a smooth launch plan no matter what platform you come from, we have pretty much done them all. Even including homemade custom ones, Lithium, Discourse. You name it, we're able to do those migrations for you. Finally, your CSM (your Customer Success Manager) is there with you for regular checkpoints. They'll work with you to measure, and prove, and scale your efforts. They're there to provide guidance and best practices as your community grows, so we're really there with you from start to finish.
Now in terms of sizes of community, hey, we can handle it. We handle over three billion discussions yearly, and we're growing very rapidly. So certainly no matter the size of your business, we can certainly handle that. As I mentioned earlier, we have tons of beloved brands that use us; Linux, Oculus, tons of others. So if you'd like to learn more about Vanilla, you can click Contact Sales on our website, or fill in the form, and you can get a free trial with no credit card required. So hopefully you'll take us up on that and jump on in.
So let's now jump to the questions. I'm going to just put up this slide as well that SJ had before for you guys. So if we don't get to your answer, or rather if we don't get to your question and you want to reach out to SJ afterwards, her information is on the screen. So maybe you're shy, maybe you don't want to ask the question. Although I have to say, Zoom's really cool because there's an anonymous question feature, so certainly you can use that.
Adrian: Well, it's handy. Sometimes you get nervous, right? You don't want to ask that question, and-
Sarah-Jane: That's true.
Adrian: ... you're like, "Well I don't want them to know that I'm asking this." But certainly, please, anyone that has a question, come on in, ask the question away. Oh, we've got a couple of questions in here, SJ. So I'll start with Emily's first question here, which is,
Question: "How important do you think it is to highlight the top helpers or contributors on the site, and what's some of the best examples you've seen?"
Sarah-Jane: Yeah, that's a really good question, Emily. This is something that I can probably talk about for a really long time. I think the importance, especially in the early stages, of showcasing developers that are doing cool things, it really goes a long way in building that inspiration within your community.
Some of the best examples I've seen actually ... When I was chatting with Elizabeth Kinsey at Slack, she was telling me how literally the day after we interviewed her ... Well, we being me. But in any case, literally the day after I interviewed her, she was launching Slack's official offline community as a direct result of an abundance of opportunities of developers that were building interesting Slack integrations, wanting to share it with the community through demos.
So I believe the URL is https://slackcommunity.com. If you go there, they've just launched a worldwide tour of events that are going to be hosting, where they're showcasing developers that are eager to showcase some of their integrations, so I would say check them out.
Then Shopify has also done a fantastic job with this, both in our blog and ... I say our blog because we're very fresh. I'm very fresh too. Not being on their team officially anymore, I think I'll be considered an extended family member for a while. That being said, Shopify's web design and development blog features Shopify developers regularly. Talks about some of their great integration tips, and the things that they've built with their APIs, as well as then speaking this year at ... For the first time, I believe some Shopify developers are going to be speaking at Unite, Shopify's official developer conference happening in Toronto this year, I believe in June. So those are two examples that are top of mind, but there's just tons more.
Adrian: Perfect. Hopefully that answers Emily's first question. Seems that she has another question here, so let me read it out. SJ, gives you a chance to read it because it's lengthy. I'll do my best to read it out here. So Emily asks:
Question: "I think the point about participation creating expectation is gold. I see our product manager is hesitant to share road-mapping information, rightfully so, on community, even though it's something everyone wants. Do you have any tips on small places to start from what community can do outside of infiltrating the PDM process?"
Sarah-Jane: Yeah, that one's really tricky. I've seen different approaches within different companies for this. One company I will reference one again, that I think does a fantastic job with this, is Slack. They do have a Trello of their developer roadmap. I've spoken to them before about how they decide what to publicize and what to keep undercover, because as we all know, I think, working in product-driven companies, product roadmaps are subject to frequent change. What Slack has done is to keep the, I guess, "teasers" fairly high level, and manage the expectation within the community that they are subject to change.
Also, one thing that I've seen them do that's just really quite cool is to actually have a physical manifestation of their roadmap at events, Slack-led events. So developers attending can actually go and up-vote their favorite features using ... I think it was cute little post-it notes, or stickers or something. So that was just something really fun that I saw integrating those roadmap expectations with IRL events.
So that being said, if there's not the ability to actually release a roadmap, one thing that I've personally been more of a fan of is, especially for things like new APIs or new developer-facing functionality, is really to avoid teasing it until it's actually out there, market-ready. Typically speaking, most developer-facing products will have some sort of beta phase, and so monitoring that beta phase and being transparent with your community about how that beta phase is going is one way to let them know that something new is coming, but it's still being worked on. So consider being a bit more transparent about your beta products in places like your online forums, or your newsletters. So hopefully those ideas spark some inspiration there.
Adrian: Oh, yeah, hopefully it did. You know, I wish there was a way in Zoom to know that it answered the question, but I'll assume Emily's okay. Jose has a good question. I think it's a good question as well. So essentially it looks like Jose is brand new, or he's having challenges in terms of ... Well, I'll just read his question.
Question: "Our developer community is quite unknown to us, so my new role is to find them and teach them the new APIs that we have to offer. So besides StackOverflow on Reddit, where else can I start?
Sarah-Jane: Yeah, for sure. So I think that I would definitely have some followup questions there. I'd be a little curious to know what stage your developer community is in, and if you have backend access to literally looking at who has API keys, and who their identities are, and being careful with that because that's obviously a privacy and trust issue. But you can get a sense of who your early-stage developers are, and just start asking them directly questions through literally who's pulled API keys.
So that's one idea, but if you're further along and you're lacking that visibility into data, StackOverflow and Reddit are fine, but there's other places that you can look. Again, this really is dependent on your developer product, but perhaps there's been some open source activity on GitHub that you're missing. I'm assuming that you're aware of all the repos where your products are being used, if that's something relevant to your developer tool.
But yeah, I mean, this is something that can start from the very basics of just literally asking the folks that ask API keys what are they doing. If they're not building right now, what's stopping them? If they are happy, what can you keep doing more of? Just really start with the folks that are already there. That would be my suggestion.
Adrian: I think, yeah, that's a good point as well. It's tough, I think, for anyone when you're starting out. As well, without the information to know how far along or what kind of technology, because there's also chances of an adjacent technology that could be of interest sometimes, or certain events that might be in that scope, right?
Sarah-Jane: Yeah, completely. Yeah. Tricky one, for sure. Getting started is not always easy, but there are ... Just really identifying those early-stage folks that even have the smallest glimmer of interest, and just not overwhelming them with your attention, but treating them like gold. It really goes a long way.
Adrian: So Karen has a question here, interesting question I think that we all struggle with sometimes. So Karen asks:
Question: "How do you encourage and incentivize internal teams outside the overall community to participate in the developer community spaces?"
Sarah-Jane: That's a really good question, and definitely one that I have struggled with in various roles. I think one of the more silly and helpful ways to get folks from throughout the company to want to join developer community activity a bit more is, if you happen to be hosting events, have some good food. Have some good food, some tasty drinks to suit everybody. Doesn't necessarily have to be alcoholic. There's actually a tremendous amount of delicious non-alcoholic services out there that I keep saying, that serve various delicious shrubs and things like that. All these cool hipster drinks. So just having a great experience. Lock in that budget for a good experience. I am so against the days of pizza and Red Bull being associated with developer meetups. Treat developers with the respect that you'd reserve for the rest of your customers. Use that budget, if you can secure it. I know that's hard in some startup settings to secure budget for things like food and events, sort of splashiness, but I think that we're long overdue to treat developers as folks who enjoy delightful experiences as much as our customers. So that would be one really obvious thing for an offline event.
In terms of getting the internal teams to recognize developer community in other ways, I think really showcasing the integrations, and also how they impact end users. So for example, I'll think of Shopify apps that are doing tremendous things to really help Shopify merchants make more sales. So if you can showcase the real impact on consumers to the rest of the company, and get them interested in the mechanisms behind how those customer-impacting tools get built, that can go a long way.
Adrian: Awesome. Well, anyone else? This is your last change to get some really good, amazing advice and support from SJ.
Sarah-Jane: Not your last change. You can email me any time.
Adrian: Oh, that's true.
Sarah-Jane: It's your last chance today.
Adrian: Last chance live, right now. Your pressing questions, you have your chance to ask.
Adrian: Well, I'll give everyone just a moment here. You know, they might be typing furiously. You never know. Okay everyone, well that seems to be all that she wrote. So thank you all, everyone. Thank you, SJ, for some amazing things to think about, some knowledge and some insights, and certainly appreciate you sharing those with us today and our audience. Everyone, thank you so much for joining us. Check out any future webinars that we have lined up at library.vanillaforums.com. Once again, thank you SJ for joining us, and I'll see you all on the next webinar. Be well everyone.
Sarah-Jane: Thank you everyone. Thanks, Adrian.
Adrian: Thank you.