a16z Podcast - Measuring & Managing Community Orgs, Developer Relations and Beyond

Episode Date: August 30, 2020

Okay, so we know community is important -- whether for developer relations for your product or other types of communities -- but how do we measure the success of community initiatives and even artifacts (like events or schwag), given how indirect and long-cycle so much of it is? How do we know we're even measuring the right things, and is there one key metric or KPI for measuring the health of a community? Where do "meta communities" or where does engaging key community leaders come in?And when it comes to developer relations specifically, where should devrel sit in an organization (product, sales, engineering)? Who should you hire first? How do you reconcile developer as customer vs. developer as community member? And what's the difference between evangelism and advocacy?Amir Shevat -- former VP of Product and Developer Experience at Twitch and former Director of Developer Relations at Slack who also previously worked at Google and Microsoft -- drew on his experiences to share insights and answers to these questions, as well as provides an overview of key concepts, followed by a Q&A with Mikeal Rogers, who works on Community Operations at Protocol Labs, and was formerly Community Manager of the Node.js foundation (and has shared insights on the changing culture and community of open source on a previous episode of the a16z Podcast).This episode is based on a conversation that took place at a portfolio workshop event from a couple years ago organized by former a16z 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. You can find the latest on company building best practices for crypto at a16z Crypto Startup School and see other pieces in our ongoing community series at a16z.com/community.

Hi everyone. Welcome to the Sixth and Z 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 dev rel 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 swag 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 A6 and Z 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 that took place at a workshop organized for our portfolio by then A6NZ 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 A6NCi.com slash crypto school. and to find all our episodes so far on the theme of community, please visit A6NZ.com slash community. Okay, so why Devrel? I'm going to be quite controversial here. Don't do it.

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 in develop relations and an engineer. That is a hard trait, 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, 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 a developer 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, 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. 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 measure that team by meantime to hello world. 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. Developer relations, this is what you do.

You inspire developers. You tell them what you've built and why this is important. 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. 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 it 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.

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 market

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. 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, but Google, we call it developers touched.

But the problem is that it was an internal metric and also 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 spend 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 100,000 developers who have registered for a token. That is bullshit. Who cares? 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. 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. 250,000 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, um, correlation versus causation, but it is a strong leading indicator that your platform is useful. On the tokens, was that the developer API access or was that the developers' apps, utilization, access? That's a great question. It was tokens that customers generated. So whenever you install an app, 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

sheet. Just make your platform hard and then people 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. 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 breath 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? 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 wins. You're going to 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 $100,000 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 going to do is going to be evangelists. They're not going to bring feedback. It's all going to be sales and we have to convince and it's going to 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. 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,

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. All right. 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 kind of the big do's and don'ts for that crowd of people? 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 like 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? So choose a few things and do them really, really well, that's the tip. That's do's and don'ts together. In the crypto space we have a unique capability to incentivize people. Like, you can't really

give away equity in Slack, for example. Yeah. We can give away tokens. How do you think about that with developers? There's an article by Professor Danerile 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-transactual 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 backfire really hard we paid 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 it doesn't guarantee the right incentive it doesn't yeah yeah 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 showing 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 like extrinsic motivations to pick up your kids on time. We studied this a lot like in open source incentives as well because a lot of, 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 about it. more about sort of building up a dev rel team. How do you think about, you know, who to hire first,

how to hire, how to staff it up? You talked a lot about like what the different components of it on, but how do you like actually build that? So the first thing I would do is figure out whether I'm going for a breath strategy or a death strategy. If I'm going for a breath 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 because for both top partners and for breath engagement, you need the docks. So that's table stakes. Get someone who's awesome that will write the docs for you. Hiring is actually really on my mind a lot. When you're evaluating candidates, how do you think about evaluating their prior work? If you are going for a debt 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. 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've 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. 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. That's great. So you talked a bit about the right things to measure.

I used to run Deverell 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 centers.

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? 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. 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 going to devrail 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 keys, like, in every type of partnership relationship, you have strength 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. One thing I've been pressing is just this end for a penny, end for a pound thing. Like,

think more about the opportunity cost, right? Like, if you're already sending somebody to a conference. I just pay some extra money to take people out to dinner and send them a bunch of shirts to give out. 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 slocks, was incredible. But they stayed. 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, why are you wearing my socks? You remember, we talked about the belonging, it creates a belonging. Yeah.

So what's something that, like, you really wish that you knew when you started doing Devrel? Did you learn today? It is, 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. So I would Like, making sure that the feedback flows back is the most important thing that I didn't know. 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. Exactly.

What I did at Slack is, like, every week, both support and Devrell 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. So if you had to pick one metric or KPI to describe sort of the health of a community, what would it be? 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 learn 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, to take someone who's very young and very energized and to have a second in command. 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 got to go. It's too much, and new blood has to take it on. And I think, like, the community is a lot better for that. 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. Wow, that's brilliant. I think we can open us for more questions.

People have them. So you work at big companies, you work at small companies. I'm curious to see what kind of different. strategies you might have applied for long-tailed developers versus the big partners and what is effective because it requires different kinds of investment? Personal preference is that I really like the big partners initially. 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. And I brought these entrepreneurs, and we asked them to go through the website.

And the most common word was, I'm confused. I felt like barring myself just right there. Give me a 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. Yeah, we created a tutorial for Dweb Summit last year and just the process of creating the tutorial showed us how some of these APIs 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.

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 OAuth because it's not. 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? 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 dev sites. Go. Show me growth of 20% week over a 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. A lot of you probably use open-source projects that are on GitHub as well. There's a fair amount of metrics. Stars. 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 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 how long it takes. takes to get that kind of stuff resolved. 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 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. 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 application developers. And it may be that you have not much to say about this. Let's do this. Yeah. So I'm a developer somewhere, let's say Google, it's a great example. I was there. What you want for me is to contribute to the code base, 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? 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?

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.

It's not even the external recognition. It's like internal recognition. Like, I actually conquered this goal and learned this piece of code. I think recognition is extremely, extremely strong. We didn't 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. 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 going to stick around. Just tiny little things like that have a huge, huge impact.

Yeah, I think it's a totally different profession develop 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. Governance is a whole other type of collection. And, of course, you have decentralized governance. Cool. I have time for one last question. 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 sources, there's a lot of overlap or sort of some blending. And so what sales does versus Devrel in that world? 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 there, you need sales people. 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 talked 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. 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. 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 a 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 thank you