Pod Insights a16z Podcast Measuring & Managing Community Orgs, Developer Relations and Beyond About this episode We know community is important -- whether for developer relations for your platform or just other types of communities -- but how do we measure the success of community initiatives and even artifacts (like events or schwag)? How do we know we're even measuring the right things? And when it comes to developer relations specifically, where should devrel sit in an organization (product, sales, engineering)? Who should you hire first? And how do you reconcile developer as customer vs. developer as community member?
Transcript Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
0:00 Sonal? Hi, everyone. Welcome to the A6andZ Podcast. I'm Sonal. Today's episode continues our Community Practices series by covering all things developer relations, but it actually applies to almost any company with a community. The discussion covers how to measure the success of community initiatives, including is there one key metric or KPI for healthy communities, and how do you even know you're measuring the right thing, to how to organize DevRel within a community, from who to hire first, where it fits in an organization, how to align incentives, and more. The conversation also touches on the difference between evangelism and advocacy, the role of meta-communities or community leaders and how to involve them, and where schwag
0:44 Sonal? does and doesn't come in. Our guest is Amir Shavat, who was VP of Product and Developer Experience at Twitch at the time this event took place, was formerly Director of Developer Relations at Slack, and also previously worked at Google and Microsoft. He begins with a short overview of key concepts, followed by a Q&A with Michael Rogers, who works on community operations at Protocol Labs and was formerly Community Manager of the Node.js Foundation. He's also actually been on a previous episode of the A6andZ Podcast on the changing culture of open source with Nadia Igbal, who I also recently had back on on another episode all about community. But this episode is actually based on a conversation
1:27 Sonal? that took place at a workshop organized for our portfolio by then A6andZ crypto partner Jesse Walden, because crypto gives developers the ability to build on top of and extend any protocol or application in the space, and developer relations and community building is an important part of that being realized. For more on crypto community building, be sure to check out a6andz.com/cryptoschool. And to find all our episodes so far on the theme of community, please visit a6andz.com/community.
1:59 Speaker 01 Okay, so why DevRel? I'm gonna be quite controversial here. Don't do it.
2:06 Speaker 01 We are engineers that talk to other engineers and convince them and help them to do stuff. Right? So if you're a startup, you need to choose between someone who can develop relations and an engineer. That is a hard trade, right? That is not easy and you only need to do it if you have to. So if you don't have to, if this is a nice to have, yes, and we'll have a set of APIs or maybe developers will help us, then I really strongly recommend not doing any developer relations. Developer relations is expensive, it creates a lot of maintenance, it's a one-way door. It's a decision that you can't go back from. So if you open an API and then close it,
2:47 Speaker 01 developers will never, ever trust you again. So remember, it is a hard decision, but it's very empowering if it really drives your business. So I would stipulate that more than 90% of startups do not require developer relations. It is required when you are building a platform, when developers actually are the creators of the value of your startup, when they're your users. At Slack, we started without the developer relations and then we started building and developing relations. And the key here is that we found out that the platform is the number one NPS net promoter score for using Slack. People were always super happy about the integrations. When we asked them, what is the most important thing?
3:30 Speaker 01 They said the integrations. When it wasn't number one, it was in the top three all the time. So the developers were driving a lot of value to our core audience, which are paying customers. So how to DevRel? You have advocacy, which is the one-to-many. These are the people like me who speak on stages and say, praise the Lord, here's our API or here's our token in your case, and here's the use case and here's the value. These are people who create scalable content, they create the articles and all these other things that are super important to inspire developers. Then you have partnership engineering, that's the people who work with one-to-one relationship.
4:12 Speaker 01 These are the people that you send to the top clients, to the top developers. In the first year, I actually invested most of my money in partnership engineering. I invested most of my time in people who know how to do these type of relationship with top developers. Then you have enterprise architects. This is if you're doing an enterprise use case. These are people who go and do post-sales support and make the usage wider. And then content writers, super important. These are people who write the docs for your developers. It is super critical to write the right docs. I measured that team by mean time to hello world.
4:54 Speaker 01 How fast is it for a developer landing on the developer's site to reach success? Right? So that's, I think, the most important part of that team's job. They also are the voice of the developers. At developer relations, this is what you do. You inspire developers, you tell them what you've built and why this is important for them. So now they are inspired. Then you educate them. This is the one-on-one or five minutes to hello world. This is where they actually are educated about, and they become proficient in using your technology. And then you enable them. These are the tools and services. This is the SDK, the API, the debugging tools, all the things that your developers will need in order to be successful.
5:39 Speaker 01 And this is the most important thing, feedback. Most people don't do this and fail. Because the most important thing is for developer advocates not to be called evangelists. At Microsoft, I was an evangelist, unfortunately, and who was like, hey, praise the Lord, SharePoint. And that wasn't very good because when developers told me, hey, this part sucks, I used to say, yeah, that's by design, it's awesome. It was bad for my soul and bad for my relationship. But I would never hire an evangelism org. I would build an advocacy org because an advocate will say, hey, here's our API or token in your case. If it sucks, tell me and I'll go back and fix it.
6:23 Speaker 01 So it's a bidirectional role where they take the voice of the developers and the audience and brings it back to the product organization and makes the product better. Okay, super important. You need to look at your developer engagement in the same way you look at your marketing funnel. And for each of those steps of the funnel, you need to have a certain metric. How do I measure that people have moved through this funnel? And on the other side of this funnel, you need to put the levers. What are the activities that I can do to move my developers through the funnel? The key is to understand there's multiple levers here. And then this is most important, measuring the right thing.
7:06 Speaker 01 But there's a problem with developer relations because people choose to measure the wrong things many times. Let's start with the bad and then move to the good. Developers engaged. At Google, we called it developers touched. But the problem is that it was an internal metric and also a who cares metric. Who cares how many people you actually engage with? If it doesn't move anything in your funnel, it is an empty metric. So for a year, we spent time reaching and touching as many developers as we can, right? We didn't move any needle. Developer registered. I've seen a lot of people say, yes, we have a hundred thousand developers who have registered for a token. That is bullshit. Who cares?
7:51 Speaker 01 You can really, really hack that with one Facebook campaign or one social video, you can get people to register and then they do nothing, right? That's really easily hackable. Why is this a problem? Several of you are probably CEOs. Why is this a problem? This is a problem because you turn developer relations into sales and you create misalignments. Developers don't want to talk to salespeople.
8:16 Speaker 01 They don't want even to talk to developer relations. They want to talk to the actual developers who are building the shit. At the end of the day, I cared about one metric. Two hundred and fifty thousand developers with weekly active tokens. That was measuring the usefulness of my platform. And paying customers that the percentage of customers were using the platform. This is a correlation versus causation, but it is a strong leading indicator that your platform is useful.
8:45 Speaker 02 On the tokens, was that the developer API access? Or was that the developers' app utilization access?
8:50 Speaker 01 That's a great question. It was tokens that customers generated. So whenever you install an app.
8:56 Speaker 02 Utilization.
8:57 Speaker 01 Exactly. The utilization of the apps themselves, yes. Like developers actually using test tokens, we didn't like use at all. We discounted those. Test tokens are like an easy way to cheat. Just make your platform hard and then people will use more test tokens. Yes, you need to understand that if you had a single developer creating a very popular app, then amount of tokens used is still not a healthy metrics, right? So you want distribution. Let's say we had only Salesforce and everybody used Salesforce integration. It would be a high number in that metric, but it wouldn't be a good health metric for my platform. Because I wanted diversification.
9:41 Speaker 01 I wanted to integrate into all of the tools and services out there. That's why I chose distinct developers with active tokens. It shows that there's a lot of them and they're all useful. So you need to work your breadth versus depth strategy. You need to choose whether you have a few strong developers or a lot of small developers. And sometimes you have both. Focus on high value developers and partners. The way to do it is the first year you open a platform and you say, hey, developers, come, this is so awesome. And nobody comes, right? I don't know if it happens to you. It happened to me a few times. You say, hey, this is the value proposition. And they're like, yeah, who cares?
10:25 Speaker 01 Find partners who are interested enough to show your developers why this is important. It's called king or queen making in several companies. I don't like that term, but choose the partners who can be your lighthouse winds. You're gonna work with them really strongly, build a beta program with them. And when you launch, you launch with all these partners. And then they tell the story. They say, hey, we just made a hundred thousand dollars on that platform. That is the strongest message developers will ever hear. And then advocacy versus evangelism, always think about the feedback. So if you tie your developer relations into revenue, all the things that your developer relations are gonna do is gonna be evangelists.
11:10 Speaker 01 They're not gonna bring feedback. It's all gonna be sales and we have to convince. And it's gonna be a very, very hard conversation between the DevRel person and the developers. Like, yes, you should use this, but this is broken. But you should use this and pay for it, right? So you create a misalignment between your customers and the audience that you're trying to reach. Where you're in the org matters. This is important. I don't know if you're a small or a big startup, but it's very important to put developer relations in the right org. Because then you always need to think about what is the incentives? I found from my experience that putting developer relations under product is the best fit. Because of that feedback loop, they make the product better.
11:53 Speaker 01 If you put it under engineering, they will be much more technical, but they will compete against engineers. If you put them under sales, you make them sad and lonely and go away. Where the money comes from matters. This is more of a big organization. If you're in developer relations and all your money comes from marketing, most of the stuff that you'll do is marketing activities. So having a budget for developer relations is important. And always think about with him, what's in it for me? So think about, as a developer, what do I get from the platform? I see a lot of startups coming into developers and say, hey, look at all these awesome things. But they take the perception of themselves. What I really like is like, hey, you have these problems
12:36 Speaker 01 and this is how we can solve your problems with developer relations, with our tools. Okay, what I'm seeing right now is that a lot of developer relations is done on streaming platforms. Developers want to be engaged, they want to see another developer actually developing over the platform. So there might be a future where your developer relations is going to be online, engaging in a live experience of coding or using your tokens on a streaming platform. Thank you, you're awesome.
13:09 Speaker 03 Alright, so I think for everybody in this room probably, they're at the earliest stages of developer adoption, right? Like very, very early on. So what do you say are the big do's and don'ts for that crowd of people?
13:19 Speaker 01 I think the key here is to focus on a few things and do them well. Do you know the difference between one-way door and a two-way door? There's an article by Jeff Bezos where he talks about decisions and there's two types of decisions. The one-way door and the two-way door. The one-way door is a decision that is really hard to come back from. And a two-way door is a decision that you can always revert. Every developer channel that you open is basically a one-way door. So if you open a Twitter channel and you stop using it, people think that your product is dead. So the minute you choose a channel to go out to developers, maintain it and keep it. So be very thoughtful and how do you engage, what are the channels that you engage with?
14:02 Speaker 01 So choose a few things and do them really, really well, that's a tip. That's do's and don'ts together.
14:10 Speaker 04 In the crypto space, we have a unique capability to incentivize people. Like you can't really give away equity on Slack, for example, but we can give away tokens. How do you think about that with developers?
14:20 Speaker 01 There's an article by Professor Dan Ariely, who talks about the easiest way to ruin your relationship with your spouse is by paying for sex. Because there's two types of interactions. Transactional interactions and non-transactional interactions. A lot of the developer interactions with you are going to be non-transactionals. They want to do things for you because they love you, because the platform is awesome, because they have belonging and fun and growth. If you turn it into transactional, that's all you'll get. It is like, what's in it for me? I haven't made enough money on this. I look at the loss and revenue that I'm getting from this. So incentivizing just by giving money, that backfired really hard.
15:04 Speaker 01 We pay developers to build apps for mobile. They created the lowest quality of app for the amount of money. So don't do it unless it's really tied into the entire value proposition of what you're doing.
15:17 Speaker 03 It doesn't guarantee the right incentive.
15:19 Speaker 01 It doesn't, yeah.
15:20 Speaker 03 There's a really famous study on this, behavioral economics, where they studied a preschool that just started charging people for showing up late to pick up their kids. And everybody showed up late to pick up their kids. And it increased it because it turned it into a transactional relationship. And it removed a lot of the extrinsic motivations to pick up your kids on time. We've studied this a lot in open source incentives as well. Because there's been a long history of trying to pay people to do open source. And almost all of it has turned out very poorly, actually. So, yeah. So, talking more about building up a DevRel team. How do you think about who to hire first, how to hire, how to staff it up? You talked a lot about what the different components of it are. But how do you actually build that?
16:01 Speaker 01 So the first thing I would do is figure out whether I'm going for a breadth strategy or a depth strategy. If I'm going for a breadth strategy, I would hire an advocate. The first person I would hire is two people for scalable content, a content writer and advocates. These are people who their mission is to get as many people through the funnel. At Slack, we didn't start like that. We started with the top. So I hired the partner engineers, who are people who really want to go to the top partners and convince them to build with us and make sure that their integration is valuable. The content writers are always given, so my first hire was a content writer.
16:41 Speaker 01 Because for both top partners and for breadth engagement, you need the docs. So that's table stakes. Get someone who's awesome that will write the docs for you.
16:53 Speaker 03 Hiring is actually really on my mind a lot. When you're evaluating candidates, how do you think about evaluating their prior work? Like, if you are going for a depth strategy, are you more worried about, okay, they have really specific stuff in this area? Or you just go, you know what, they're a great writer, they'll pick it up?
17:06 Speaker 01 I'm radical. It might not be the right way for you. I make sure that they are developers. I don't hire anyone in my developer advocacy who's not a developer. Then the interview is about building on our platform. So they need to show that they actually know how to build on the platform. And the questions are on how it sucks. Right? What were their pains? What were the challenges? What is missing? When I came to Slack, I came with a list. It was a very dangerous move, but I came with a list of things that I think are broken. And April Underwood looked at it and said, yeah, that makes sense. Yeah, we know about that. But like, that makes you think that that person actually has the empathy
17:50 Speaker 01 and is willing to admit that things are not as perfect as they are. We had someone build a bot for Slack that was so awesome that I wanted to hire her before she leaves the building. Because she was so proficient and so awesome in that.
18:06 Speaker 03 That's great. So you talked a bit about the right things to measure. I used to run DevRel and what people tended to love were like going to a big hackathon and handing out coupons because a bunch of people would sign up. And you could tie directly that impact to that revenue. Of course, broke college kids at a college campus are not like the greatest customers, actually. And so that was definitely like the wrong thing. And a lot of the really high-touch things that we were doing were effectively impossible to measure. Like, we would build really strong relationships with framework engineers and they would give talks, you know, talking about our tech and we would see a huge amount of signups. We couldn't directly tie them. So how do you think about like these really, really high-value things that you know that you can do, but don't have a very easy way to measure them? And how do you rank them against things that are easier to measure but are the right thing?
18:47 Speaker 01 I would rather do the right things that are not able to measure. Doing things because I can measure them is bad. That's like developers touched. I can easily measure how many developers I've touched, but nobody cares. I think that if you have a lot of money, you can measure most things. So for Twitch, every person that lands on the dev site is immediately through APIs connected into Salesforce. And then we measure if they attended an event or not. And did they do this 101 or that 101? And did they watch this Twitch stream? So we have everything connected and measured. But for you as a startup, I would experiment. And understand that sometimes you talk to developers and it takes another six months until they do something.
19:28 Speaker 01 I can tell that I went into many of the big developers in the first year. And I told them, we want you to build for Slack. And they told us, Slack what? You want us to build what? We have our API. We're gonna DevRel you. Here's our API. You should build stuff for our platform. And then, a year later, they came and said, "Oh, a lot of our customers are asking for integration. Why don't we collaborate?" But that's what happens. And the key is like, in every type of partnership relationship, you have strengths and weaknesses. And sometimes, you need to build some of the stuff in order to show. And if you're successful, the balance goes to you.
20:06 Speaker 03 Yeah. One thing I've been pressing is just this "in for a penny, in for a pound" thing. Like, think more about the opportunity cost, right? Like, if you're already sending somebody to a conference, like, just pay some extra money to take people out to dinner and to send them a bunch of shirts to give out.
20:18 Speaker 01 Swag works really well. That's a sad statement about humanity, but swag works really, really well. The amount of people who came because of the socks, the slox, was incredible. But they stayed. And it's a symbol sometimes, right? And then they went to the second event or the third event and always showed me, "Hey, I'm wearing your socks." And I'm like, "Oh, why are you wearing my socks?" You remember, we talked about the belonging? It creates a belonging.
20:47 Speaker 03 Yeah. So what's something that, like, you really wished that you knew when you started doing DevRel? That you learned today?
20:55 Speaker 01 It is, um, I think one of the biggest challenges I had through my career, and now I solved it by, like, owning product and engineering as well, is how the negotiation between DevRel and the product, how hard is that in many organizations? Developer relations are the people who really know what the pain of the developers are. They really know that the messaging from marketing doesn't work, right? Developers say, "I don't care." Or they come with their product and the developer says it's broken. They have the most amount of empathy out there. If you don't build this loop of, like, developer relations bringing back the feedback, the product, and product reprioritizing their roadmap based on that, you create a lot of frustration and you break the value chain.
21:40 Speaker 01 So I would, like, making sure that the feedback flows back is the most important thing that I didn't know.
21:47 Speaker 03 Yeah. Early on in my career, I definitely spent a lot of, all of my time really thinking about my external relationships with the community and not enough with the people inside of the company. Because you need those relationships to actually, like, do anything about what the community wants.
21:59 Speaker 01 Exactly. What I did at Slack is, like, every week... Both support and DevRel could bring three things that are painful for our customers and product had to triage them. Every week, what are the top support tickets for the platform? What are the top feedbacks from our partners? Every week, there was a PM accountable for making sure that these are addressed.
22:23 Speaker 03 So if you had to pick one metric or KPI to describe sort of the health of a community, what would it be?
22:29 Speaker 01 That is, I don't know how to answer that. For every generic use case, I would say that one of the healthiest metrics is that if this community leader leaves, how likely is the community to disperse? It's hard to measure, but it's very important because what I learned from communities is that a community leader comes in, they work, and they get the growth, and then they become tired. If they don't create a healthy community, the community is centered around their motivation rather than like its own value. So it's very important for every community lead to have an apprentice, take someone who's very young and very energized, and to have a second in command.
23:09 Speaker 03 In the Node.js community, which I've been very, very involved in, early on, the creator of the project left and it created this, like it really kind of formalized that leaders can step down and leave. And now it's almost like, you know, there's like a ticking clock, like you can't go more than three years. Like I was a leader of the project for a while and eventually you just gotta go. It gets too much and new blood has to take it on. But I think like the community is a lot better for that.
23:29 Speaker 01 Yeah. Also, think about what is the meta-community? What is the community of your community leaders? If you run one community, it should be of your community leaders. They're the most important, spend the most amount of time, winding and dining them. In Japan, we actually had dinner with our community leaders every month to show respect to them. We brought Googlers and we had dinner and they talked about things and provided feedback.
23:55 Speaker 03 Wow, that's brilliant. Okay. I think we can open it up for some more questions, people have them. So you've worked at big companies, you've worked at small companies. I'm curious to see what kind of different strategies you might have applied for long-tail developers versus the big partners and what is effective because it requires different kinds of investment.
24:13 Speaker 01 Personal preference is that I really like the big partners initially.
24:19 Speaker 01 The key with the big partners is that you get a lot of feedback and quality feedback. So if I would start without a lot of budget, I would just do a beta program. Which is before I launch, I get a set of developers to come and try the API or the token and use it and give me feedback before I even launch it. I think that's the most high-value, low-costs that I would do. Bringing developers to the office to actually do the stuff that you're asking them is the most humbling and soul-crushing experience that you'll ever have. But it's the most effective way to grow your company. I built the site for entrepreneurs for Google. And I thought that I was a good designer of websites.
25:03 Speaker 01 And I brought these entrepreneurs and we asked them to go through the website. And the most common word was "I'm confused."
25:12 Speaker 01 I felt like burying myself just right there. Give me the shovel and I'll do that. And then we did a design sprint and we improved it. And the most common word was "I get it." So it is hard and it creates empathy. And it costs $50 of Amazon vouchers if you really want to incentivize someone to come. But that's the most important thing, to see if there's value.
25:36 Speaker 03 Yeah, we created a tutorial for D-Web Summit last year. And just the process of creating the tutorial showed us like how some of these APIs like aren't great to use. And then watching people try to use them and seeing how they get confused just in that direct feedback loop was so valuable. It led to so many changes.
25:51 Speaker 01 You need to remember that you're Silicon Valley startups and companies. You're the best of the world in terms of like this type of innovation. You're the best at your technology, right? Most developers out there don't really care. And you need to take yourself out of your head and into the developer's mindset. They're much more proficient in what they do and what they care about. So it's not that we're the best, we're just the best in what we're building. They're best in creating their own things. You need to remove yourself from this mindset of like, of course it's easy to do all off because it's not.
26:26 Speaker 05 How do you trust your team? Or how do you know who's doing great, who's not? And vice versa, how does the CEO know you're doing great or not?
26:32 Speaker 01 What you do is you tie their activities to a single metric. If it's advocates, I would say, hey, Twitter reactions to your tweets, follows to your Medium posts, and landing on our Devsites. Go. Show me growth of 20% week over week, and I'll be great with you. If it's not that, we're not great. At Amazon, we are very obsessive about numbers, and we do a weekly business review. Not a monthly business review, not a quarterly business review, a weekly business review. It is insane, but it's very, very effective. I want to see metrics.
27:07 Speaker 03 A lot of you probably use open source projects that are on GitHub as well. There's a fair amount of metrics.
27:11 Speaker 06 Stars.
27:11 Speaker 03 Yeah, stars are not the best. I mean, there's a project that the CNCF, the Kubernetes folks, just did recently that you can set up called DevStats that pulls a lot of data and does new visualizations around it and GitHub data. But a couple of key ones are the amount of time that it took for somebody to get a response in a new issue or something. Not to just get resolved, but just to see a response. And then also you track like how long it takes to get that kind of stuff resolved.
27:33 Speaker 01 That's a great point. Another hack is to provide an online service that if you connect your open source into that online service, you get some value. Let's say there's a dashboard or something like that that you can only access from the web. And then you get all these data. So like, connecting open source is really hard because I can take your open source and not tell you about it and like use it a lot, right? But if you connect it into a value that is online, you can actually measure that.
28:01 Speaker 06 It strikes me that there's developer relations, which I'm interpreting as like application developer relations. And most of our focus is on core developer stuff. I think in legacy terms, it would be like the engineering organization. But because we're working on open source projects, there's not sort of strict difference between the engineering organization and the application developers. And it may be that you have not much to say about this.
28:25 Speaker 01 Let's do this.
28:26 Speaker 06 Yeah.
28:27 Speaker 01 So I'm a developer somewhere. Let's say Google is a great example. I was there. What you want from me is to contribute to the codebase, right? What's in it for me? So I would say that now my incentive is probably recognition. I would check that, but that will be my strongest assumption. And I want to be a member of this community. I want my contribution to be noticed. Maybe get some financial recognition in terms of the promise of the platform. It's more like you're trying to join a virtual startup, right? So I would look at me in the same way as an employee in terms of incentives. I want to be successful, I want to join the right... Is this the right startup for me? And will I get the recognition?
29:10 Speaker 01 Can I tell my friends that I'm contributing to Ethereum? And that will be an awesome thing. The key here is like, who is my audience? And what do I really want? And what's in it for them? If you can figure these things out, you can get a lot of developers to contribute. But again, think about what is my incentives? Why am I doing this?
29:27 Speaker 03 So I used to run the Node.js Foundation and worked a lot on the Node project. And we took that project from having one developer, who was burned out and never releasing, to hundreds within a few years. And a big part of that was building a funnel that looks very similar to this funnel, where like, don't assume that people are going to show up with all of the skills that they need to develop. Like, they may be users first, they may have other itches that they want to scratch. And then you need to build the pipeline from that place to where they are. Like, one thing that we did was we made documentation very easy to contribute to. We made the website very easy to contribute to. Because people would show up and get over the social part of it. And then they would start to learn the more core technology. And a lot of the times, like, most people show up to fix one thing, but they stick around because they like the people and the technology. And there's a sense of personal development. That's a lot of it.
30:12 Speaker 03 It's not even the external recognition, it's like internal recognition. Like, I actually conquered this goal and learned this piece of code.
30:18 Speaker 01 I think recognition is extremely, extremely strong. We did an experiment for viewers on Twitch of buying things. And what we've seen is that we weren't able to sell things to viewers until their name popped on the video. Once we added that into the interaction, it created a loop that made it extremely successful to sell things. Recognition, badges. I contribute to Google Maps like crazy because they give me a blue badge. It's not red, it's not yellow, it's blue. It started with red, and I really didn't want it to be red. So badging is super important.
30:57 Speaker 03 I know three core open source maintainers of major projects, who ended up becoming the core maintainer because they fixed one bug. And then in a blog post or an email, like, somebody put their name there. And they were like, "Oh, that's really cool, I'm gonna stick around." Just tiny little things like that have a huge, huge impact.
31:15 Speaker 01 Yeah, I think it's a totally different profession developer relations. It's more of a community of developers. If you bring developers to contribute, you need to make sure that you're open. These are like very, very big one-way doors. Who owns the IP of the contribution? Very, very big one-way door. How do you make decisions in the open source projects? A very big one-way door. All of these are like DNA-defining type of decisions.
31:40 Speaker 03 Governance is a whole other topic.
31:41 Speaker 01 Yes, and of course you have decentralized governance. Cool, I have time for one last question.
31:48 Speaker 07 Yeah, I guess I'm just wondering, how do you reconcile developer as customer versus developer as community member? Is there a framework that you use to think about that? Obviously, there are some obvious differences, but in a lot of open source spaces, there's a lot of overlap or sort of some blending. And so what sales does versus DevRel?
32:06 Speaker 01 Developer as customers, it's all about value exchange. What do I get from this? What do I pay? You don't need developer relations people. You need them to educate, but at the end of the day, you need salespeople. That's a Stripe playbook. Twilio did a good job there. And if you look at their advocates, their advocates were growth hackers. So Twilio hired people who actually were members of other people community, right? So their developer relations were amazing in Ruby and talk about how to use Twilio and Ruby, right? So it was more of a growth hacking tactic. Developers as community contributors, you need to look at them as mini-employees, right? They're actually working for you. And then you need to come back to the fun, growth, and belonging.
32:51 Speaker 01 How do they see themselves? Why is this something that is useful for them? And how is this radically fun to be part of your platform? Create release notes that are really funny. That's what we did at Slack. That was like, it would cost us really, really nothing. And the amount of tweets that people say, "Oh, I saw the release notes and it's so awesome." It creates the feeling that you're not managing the community. You're a member of the community, right? My core learning from a community is that you can manage it from the outside. You need to be a member of the community. And if something sucks, you can't say, "No, this is by design." You say, "It sucks, let's fix it together." Awesome. Great. Thank you. Of course, thank you.
Previous Reining in Complexity: Data Science & Future of AI/ML Businesses Next From Unknown Title to Viral Game: 12 Growth Lessons From Spellbreak Page updated September 30, 2026 · transcript and summary are machine-generated
